[Pkg-lirc-maint] Bug#740490: Bug#740490: Change hardware.conf defaults
Stefan Lippers-Hollmann
s.L-H at gmx.de
Sun Mar 2 12:59:56 UTC 2014
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>
More information about the Pkg-lirc-maint
mailing list