From the changelog it looks like the way lirc interacts with udev has changed a bit. I have tried unmerging lirc, re-emerging, and downgrading. I upgraded to lirc-0.8.0-r4 and 2.6.17-r4 at the same time so I am thinking it is something to do with 2.6.17 kernel or changes to udev interaction with lirc. Long story short the /dev/lirc/0 device is never created. Modules load just fine. Do I need to manually run mknod in the new version of lirc or should udev do this for me? I have tried compiling with and without the udev USE flag, but it doesn't seem to change. Note I am using the hauppauge driver (and modprobing lirc_i2c).
Works fine here... udev version you are using?
(In reply to comment #1) > Works fine here... udev version you are using? > portage says udev-087-r1
Since lirc-0.8.0-r1 there was no big change, only a few small things. 1. Support for usbirboy -> Only a new depend. 2. Changed Parameter when no device-type is set 3. By default set device the daemon uses to /dev/lirc/0 - when not using usbirboy 4. Removing a define garanteeing usage of /dev/lirc/0 before 3 was realized (forcing define LIRC_HAVE_DEVFS). 5. Installing udev-rules-file conditional by udev-ude-flag. 6. Adding an commented out /etc/modules.d/lirc 7. Adding a patch for lirc to work also with kernel-2.6.18(rc). I suspect your problem is either with point 7 or point 4. The only change to udev-file is that in the first comparison the "=" was replaced by "==". First try to comment the line "epatch ${FILESDIR}/${P}-kernel-2.6.18.diff". Perhaps this patch is a little bit to invasive.
(In reply to comment #3) Tried commenting out 2.6.18.diff as well as udev-904.diff. Neither seemed to have the desired effect. What should actually create the /dev/lirc/ devices? Do they get created when you modprobe lirc_dev? Also, what effect does the udev use flag have? Should most people have it enabled if they are using udev?
The udev use-flag does only control weather /etc/udev/rules.d/10-lirc.rules gets installed. What you also can control is if there are entries under /sys/class/lirc/ existing. Can you eventually try to use your older Kernel (if you have not deleted it) in combination with lirc-2.6.17-r4? I personally use lirc-0.8.0-r4 with Kernels 2.6.16.20, and 2.6.17-gentoo-r1 with the lirc_serial driver.
(In reply to comment #5) OK, using kernel 2.6.16-r13 works. Note that I also had to step my ivtv driver back to 0.6.3 as 0.7.0 require 2.6.17 kernel... the tv tuner and the remote are on the same device so it's hard to tell whether this stops working because of the new kernel or the new ivtv version. However, since it sounds like you have the serial lirc module working, perhaps I need to talk to the ivtv folks.
Aha... see below. From: Sander Sweers <sander.sweers@gmail.com> Reply-To: User discussion about IVTV <ivtv-users@ivtvdriver.org> To: User discussion about IVTV <ivtv-users@ivtvdriver.org> Date: Jul 27, 2006 9:21 AM Subject: Re: [ivtv-users] lirc 0.7.0 + kernel 2.6.17 = no /dev/lirc/ entries On 27/07/06, Kevin Worth <kworth@gmail.com> wrote: > I am using Gentoo, running gentoo-sources-2.6.17-r4 with lirc-0.7.0-r4 > ebuilds. However, my /dev/lirc/0 device never gets created when I > modprobe lirc_i2c to use the hauppauge remote. I tried stepping back > to kernel 2.6.16 + lirc 0.6.3 and it works fine. > > Not sure if this is an lirc, kernel, or ivtv bug, but the maintainer > for Gentoo's lirc has 0.7.0 running fine on 2.6.17 using the > lirc_serial driver. Anyone have any suggestions or have this working? > You will need to get lirc from cvs to get this to work. AFAIK it had to do with a name change in the bttv driver. Greets Sander PS: Also on gentoo ;-) _______________________________________________ ivtv-users mailing list ivtv-users@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-users
The below link/patch should fix the issue. http://tinyurl.com/ptnkc
(In reply to comment #8) @Kevin: Can you please try out if this patch works for you. > The below link/patch should fix the issue. > http://tinyurl.com/ptnkc If yes, I will add it to the lirc-ebuild. PS: it is 0.8.0 not 0.7.0
Created attachment 92874 [details, diff] lirc-0.8.0-2.6.17-bttv-fix.patch The above link/patch was only 1 of 2 commits. This patch is both combined. I have tested it with kernel 2.6.17 but it broke kernel 2.6.15 for me.
(In reply to comment #10) Sounds good I will try that- I don't know enough about how some of these patches work. Should I add an epatch line with the diff you attached to the current lirc ebuild to test? Here is some info from Sander on the ivtv mailing list. : >I checked lirc cvs and i'm pretty sure this change is the fix. Could >you try it? If it works for you i'll submit a bug report b.g.o with a >patch. >http://lirc.cvs.sourceforge.net/lirc/lirc/drivers/lirc_i2c/lirc_i2c.c?r1=1.37&r2=1.38 > >Greets >Sander
lol ignore above comment.. I hadn't seen Sander was replying directly to this bug
(In reply to comment #10) > Created an attachment (id=92874) [edit] > lirc-0.8.0-2.6.17-bttv-fix.patch > > The above link/patch was only 1 of 2 commits. This patch is both combined. I > have tested it with kernel 2.6.17 but it broke kernel 2.6.15 for me. > The edit line needs to have a '{' in there somewhere.
Created attachment 93001 [details, diff] 2nd try An { was left out by accident. Uploading new patch
Created attachment 93002 [details, diff] Last one, promise It helps if I actually attach the correct patch :|
Patch worked great Sander. Sooner we can get a lirc bump in portage with this patch it will save a ton of people issues now that gentoo-sources-2.6.17-r4 was marked stable and people will start to upgrade and hit this problem.
Added the patch to new ebuild-revision lirc-0.8.0-r5.
(In reply to comment #17) > Added the patch to new ebuild-revision lirc-0.8.0-r5. > Tested on my machine with kernel 2.6.17-r4 + lirc 0.8.0-r5 and it is working nicely. Thanks!
