[Pkg-lirc-maint] Bug#740490: Bug#740490: Change hardware.conf defaults

[Stefan Lippers-Hollmann]

Hi

On Sunday 02 March 2014, Marc MAURICE wrote:
[...]
> I suggest the following patch for hardware.conf:

This has already changed significantly in the packaging Vcs, to the 
extent that the next uploaded won't have a hardware.conf (in favour of
/etc/default/grub[1], pending automated migration support) anymore.

> --- /tmp/hardware.conf	2014-03-02 10:52:28.229878749 +0000
> +++ /etc/lirc/hardware.conf	2014-03-02 10:55:30.005150849 +0000
> @@ -12,10 +12,12 @@
>   #Try to load appropriate kernel modules
>   LOAD_MODULES=true
>   
> +# You can set a driver here if your device is not supported by the lirc kernel modules
>   # Run "lircd --driver=help" for a list of supported drivers.
> -DRIVER="UNCONFIGURED"
> +#DRIVER="UNCONFIGURED"
> +

According to the current package in the archive, changing this would 
introduce a bug, as UNCONFIGURED has a special meaning to the 
initscript and the maintainer scripts. Even if you would rely on it
falling back to the "default" driver, using 

	#DRIVER="UNCONFIGURED"

however would document a wrong default.

>   # usually /dev/lirc0 is the correct setting for systems using udev
> -DEVICE=""
> +DEVICE="/dev/lirc0"
>   MODULES=""

This can be done (and actually has been rectified in the packaging Vcs
already), but it's not necessary as /dev/lirc0 is only one of several
possible options - in the light of modern RC_CORE based drivers not 
even necessarily the most common one.

>   # Default configuration files for your hardware if any
> 
> 
> This way:
>   * We document the fact that setting the DRIVER is not mandatory.

DRIVER is mandatory, there are 'default' == 'devinput' vs. several 
userspace drivers, falling back to 'default' however does make sense
(and is already done in the packaging Vcs).

Supported drivers:
        accent
        alsa_usb
        asusdh
        atilibusb
        atwf83
        audio_alsa
        awlibusb
        bte
        bw6130
        commandir
        creative
        creative_infracd
        default
        devinput
        dfclibusb
        dsp
        dvico
        ea65
        ftdi
        i2cuser
        irlink
        livedrive_midi
        livedrive_seq
        logitech
        macmini
        mp3anywhere
        mplay
        mplay2
        mouseremote
        mouseremote_ps2
        null
        pcmak
        pinsys
        pixelview
        samsung
        sb0540
        silitek
        srm7500libusb
        tira
        tira_raw
        udp
        uirt2
        uirt2_raw
        usb_uirt_raw
        usbx

>   * lircd will work by default for all devices supported by kernel drivers

It still needs a valid /etc/lirc/lircd.conf and the dæmon won't start
without it being present (falling back to 
/usr/share/lirc/remotes/devinput/lircd.conf.devinput is not impossible,
but might be harder to implement with systemd).

>   * to my knowledge /dev/lirc0 is the right device name used by kernel drivers. Otherwise lircd default /dev/lirc is used.

This depends, /dev/lirc0 is only default for the lirc protocol, however
not for the various IR protocols (e.g. rc-5, nec, rc-6, etc.) which are
the default setting for the various RC_CORE based kernel drivers (the
lirc protocol needs to be chosen explicitly).

> I also filed an lircd issue upstream to ask to change the default /dev/lirc to /dev/lirc0:
> https://sourceforge.net/apps/mantisbt/lirc/view.php?id=2
[...]

This has been changed upstream, unreleased/ after 0.9.0, as well

commit d0175df5cd2ac4a261332ea21a67179f2c85072c
Author: Jarod Wilson <jarod at redhat.com>
Date:   Fri Dec 2 14:10:21 2011 -0500

    userspace: use /dev/lirc0 as default device
    
    The lirc_dev kernel driver results in a first lirc chardev of
    /dev/lirc0, not /dev/lirc, so lets default to that now. The old way is
    from pre-udev days or something, I think... While we're at it, update
    the adjacent comment about the daemon socket locations to reflect
    current reality too.
    
    Signed-off-by: Jarod Wilson <jarod at redhat.com>

At the moment, I haven't decided yet between leaving this bug open 
(and closing it with the next package upload) or closing it now, as 
your (mostly valid) suggestions don't apply (at least not as explained 
here) to the current package in the archive.

Regards
	Stefan Lippers-Hollmann

[1]	http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.default?view=markup
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20140302/b8ef021d/attachment.sig>