| Summary: | lircd init script misses correct device option | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Till Maas <opensource> |
| Component: | Current packages | Assignee: | Heinrich Wendel (RETIRED) <lanius> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | minor | CC: | gentoo-bugs, hasse-gentoobug, lanius, mholzer, novell, radek |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Till Maas
2003-01-31 11:38:53 UTC
*** Bug 15139 has been marked as a duplicate of this bug. *** *** Bug 12209 has been marked as a duplicate of this bug. *** The initial post is what's causing all of these bugs. Lirc is not using the correct device to accept IR signals. It's attempting to use /dev/lirc, when it should be using /dev/lirc/0. Once that is fixed (the fix to /etc/init.d/lircd mentioned above) there won't be an issue with xmms-lirc. The second problem, dealing with missplaces PID and log files, is a different issue but in the same vain. Lirc is a difficult installation to automate. There are _many_ different kinds of remotes and IR receivers and currently our ebuild attempts to be compatible with as many as possible. It's possible to declare which driver you want build through the use of the LIRC_OPTS= env variable, which is the best way to go (read the ebuild at /usr/portage/app-misc/lirc-0.6.6.ebuild for how to do this). Another issue is the parallel port driver. It's known not to work on SMP machines, but it seems it doesn't even like if you have an SMP kernel on a single proc machine. I've update the lirc ebuild to lirc-0.6.6-r1. This should fix issues with the PID and logs files looking for /var/lib/run and /var/lib/log. I've looked a bit more at the initscript and I'm not quite sure how that should be dealt with. I've got a Hauppauge WinTV card with a remote that requires kernel modules to opperate. When the kernel modules get loaded, devfs creates the fifo at /dev/lirc/0. However, if you're using a Miro PCTV card, that remote uses a serial IR dongle and does not require kernel modules to work. Since it on a serial interface, your devices are allready created (/dev/ttyS0 and /dev/ttyS1). In this case, lirc looks for /dev/lirc for the fifo, which you would need to symlink to either ttyS0 or ttyS1 depending on which serial port you have it attatched to. This makes things hard, as with a Hauppauge remote you can't symlink /dev/lirc/0 because /dev/lirc exists (even though it's a directory). If you have a serial type, there's no way to detect which tty you have your dongle attatched to. Even creating a conf file to live in /etc/conf.d/ wouldn't work, as it would only pass what device to use to lircd, helpful for Hauppauge people, but worthless for PCTV people. Homework for everyone is to go get loaded. I'm off to do mine. The fix does not work for me (syslog output follows). Mar 13 18:57:01 metal kernel: lirc_dev: IR Remote Control driver registered, at major 61 Mar 13 18:57:01 metal kernel: i2c-core.o: driver i2c ir driver registered. Mar 13 18:57:01 metal kernel: lirc_i2c: chip found @ 0x1a (Hauppauge IR) Mar 13 18:57:01 metal kernel: bttv0: i2c attach [client=Hauppauge IR,ok] Mar 13 18:57:01 metal kernel: i2c-core.o: client [Hauppauge IR] registered to adapter [bt848 #0](pos. 2). Mar 13 18:57:06 metal modprobe: modprobe: Can't locate module /dev/lircd I am using: start-stop-daemon --start --quiet --exec /usr/sbin/lircd -- --device=/dev/lirc/0 in /etc/init.d/lircd 57 $ lsmod Module Size Used by Not tainted lirc_i2c 3360 0 (unused) lirc_dev 8400 1 [lirc_i2c] btaudio 10924 1 tvmixer 3728 1 tuner 10112 1 (autoclean) tvaudio 12860 0 (autoclean) (unused) msp3400 16972 1 (autoclean) bttv 69888 3 i2c-algo-bit 7560 1 [bttv] i2c-core 13860 0 [lirc_i2c tvmixer tuner tvaudio msp3400 bttv i2c-algo-bit] 42 $ ll -R /dev/lirc* srw-rw-rw- 1 root root 0 2003-03-13 18:57 /dev/lircd= /dev/lirc: total 0 drwxr-xr-x 1 root root 0 1970-01-01 01:00 ./ drwxr-xr-x 1 root root 0 1970-01-01 01:00 ../ crw-rw-rw- 1 root root 61, 0 1970-01-01 01:00 0 53 $ grep lirc /etc/modules.conf ### modules-update: start processing /etc/modules.d/lirc alias char-major-61 lirc_i2c ### modules-update: end processing /etc/modules.d/lirc Ian's error is fixed with this /etc/modules.d/lirc # /etc/modules.d/lirc alias char-major-61 lirc_i2c alias /dev/lirc* lirc_i2c an runnig etc-update after editing the file. *** Bug 17167 has been marked as a duplicate of this bug. *** *** Bug 13688 has been marked as a duplicate of this bug. *** just grouping all the lirc bugs together. i have a clear idea on what needs to be done with lirc, i'm just not sure of the best way to deal with it. i'm aware of issues with init scripts existing or not existing, when they do exist they don't always reference the right device, and other problems. OK, why don't you use the depend/block features of the whole bugzilla system? The "duplicity hack" makes it a real mess... :-( is this fixed ? Me personally, I don't have any problems anymore since I've corrected all "bugs" by myself (to fit my needs). Anyway, it was a long time ago, so I can't help now... I think you can close this bug (it's many bugs really) and people will start submitting new bugs when they encounter problems. The first one will be (at least for me) that the LIRC ebuild does not work under the 2.6 kernels. I would very appreciate if you looked at the 2.6 patches and created an ebuild for them. Until then, I can't do any further testing... :-( Radek you can patch your 2.6-test7 kernel with a patch found on http://warderx.ath.cx:81/projects/projects.shtml. then compile lirc-0.7_pre2 with a 2.4 kernel. Not-a-kernel-bug, resending to wranglers... since i can't reproduce this error, i'll close it, please reopen if the problem still exists |
