For ~amd64 the lirc ioctl has slightly changed, lirc devices will not work with kernels >=2.6.36 unless you use the lirc staging drivers in the kernel and lirc >=0.9.0pre1. The modifications I've made to the ebuild check for and do precisely that, please review this ebuild and make whatever changes are felt necessary. Reproducible: Always Steps to Reproduce: 1. upgrade to kernel >=2.6.36 2. build lirc modules 3. watch the modules fail to load Actual Results: module can't be loaded. Expected Results: sucess module load and device operation More details on the Lirc project's change can be found here: http://www.lirc.org/faq.html#compilation
Created attachment 254581 [details] 0.9.0-pre1 ebuild
Created attachment 254583 [details] New manifest including the ebuild
Created attachment 254585 [details] Modified the header for ebuild to reflect version
Created attachment 254587 [details] redigested manifest for fixed ebuild
Created attachment 254589 [details, diff] patch file to show differences between ebuilds
Created attachment 254599 [details] fixed fixed ebuild switched header in ebuild back (reread the rules on modifying it), made exception for when architecture is not amd64 (for now).
Created attachment 254601 [details, diff] most current patchfile to show diff
Created attachment 254675 [details, diff] fixed fixed fixed ebuild My bad, apparently lirc drivers are in the kernel for all architectures, however you won't see them unless you compile v4l support :-/. So here is my fixed patch, once again.
Well, the ebuild is not bad, but the line ECONF_PARAMS=${ECONF_PARAMS}" --with-moduledir=. leads to the kernel modules being compiled anyway for 2.6.36 and, even worse, being installed into / of the system. This is one thing that has to be solved. I dod not find the solution to it yet.
Ah so there basically needs to be a trashpit where it installs the modules to. Doesn't look like there is any option to feed to configure or make to tell it to not build the modules at all.
Exactly. And /dev/null is no option. It will just overwrite the file and make it a directory with the modules inside. No good style, IMHO. Upstream should change that and add an option to disable the modules.
Sounds like for now I'll have to write a quick patch to the automake script, I guess now is a good a time as any to learn the much hated autotools :-p.
It seems like we should use ./configure —with-dirver=userspace in case that the kernel is >=2.6.36. That's what I got as info from the lirc IRC channel.
Created attachment 254943 [details, diff] uses --with-driver=userspace Hooray for less hackery.
Do I get this right? --with-driver=userspace should be set when the kernel is >=2.6.36 as a default. I'm asking because when commenting out all LIRC_DEVICES in make.conf, i get "--with-driver=none" when emerging. Maybe the ebuild can be simplified a bit because it is not very clear with all its options.
I think --with-driver=none and --with-driver=userspace are actually identical options.
Well, I made a mistake when patching. Now I noticed that all is good and your solution works as expected. Hope this gets more testing from people with other hardware, too.
I can confirm that it works properly with lirc-serial.
The ebuild works with me with a few catches. I use the mceusb driver, this is found under Device Drivers - Multimedia Support - Infrared remote controller adapters. To the best of my knowledge, I have no need for anything under Staging drivers with regards to LIRC. Could you have the ebuild check both spots before failing or add something stating that the drivers can be found in both spots? Aside from that, just enabling the top level LIRC option was sufficient to bypass the check. My only other issue is with the mceusb driver's responsiveness compared to the previous external modules, but that wouldn't be addressed here.
I guess it's possible, but do we really need to do that to cover that corner case? If the user has to enable v4l for lirc staging in the kernel (an extremely unnecessary dependency imho), it's not that crazy to make them enable lirc's staging drivers in the kernel. Could you give me a list of devices which are compatible with lirc but don't require the lirc-staging options? A lot of this mess involves the strange entanglement of driver dependencies in the kernel.
Maybe I don't understand what's going on with this, but the ebuild fails and errors out for me at line 156 of the latest patched ebuild Adam submitted. It just dies after printing the warning "You have a kernel greater than or equal to 2.6.36, lirc modules are now bundled with your kernel, please configure your kernel to enable staging drivers and select the respective lirc devices" I am running a 2.6.37 kernel, and I built the mceusb drivers. I commented out the "LIRC_DEVICES" line in my /etc/make.conf. Thanks to Adam and everyone else for tackling this problem. LIRC has been a thorn in my side for a few versions now. :(
I'm also getting the warning about lirc_devices_mceusb2. I don't know where that's coming from, but I believe I've taken care to use "mceusb" instead of "mceusb2" where possible. Any guidance on where/how that is being set?
(In reply to comment #21) > Maybe I don't understand what's going on with this, but the ebuild fails and > errors out for me at line 156 of the latest patched ebuild Adam submitted. It > just dies after printing the warning "You have a kernel greater than or equal > to 2.6.36, lirc modules are now bundled with your kernel, please configure your > kernel to enable staging drivers and select the respective lirc devices" > > I am running a 2.6.37 kernel, and I built the mceusb drivers. I commented out > the "LIRC_DEVICES" line in my /etc/make.conf. > > Thanks to Adam and everyone else for tackling this problem. LIRC has been a > thorn in my side for a few versions now. :( > Enable V4L support, go to staging drivers, and then enable lirc devices (MCE USB I believe doesn't need any of them, so this check doesn't really apply to you)
Please get this into the tree and make sure lirc-0.8.7 can not be installed for >=2.6.36 kernels. So module-rebuild will fail giving users the hint to keyword and install 0.9.0_pre1.
Not sure why this hasn't been committed yet
(In reply to comment #25) > Not sure why this hasn't been committed yet > I can confirm this fails on x86 (stable) with kernels >= 2.6.36 (and I'm not using staging drivers). I'm using a serial IR blaster because Comcast is switching to requiring a digital adapter, so many MythTV installations will start feeling this pain soon.
What fails, the patch or the current version? LIRC project is moving all of their drivers into the staging area of the kernel, if you are using a kernel >= 2.6.36 you must enable them.
Thanks, Adam, for your work on this. The lirc-0.9.0_pre1 ebuild worked for me using the staging drivers from the gentoo-sources-2.6.37-r1 kernel. All of the buttons on my mceusb remote work, but they seem to repeat hyperactively. VERY touchy. Single keypresses like volume up will repeat a dozen or more times. Same thing happens in the main MythTV menu where it makes it hard to land on the desired menu item. My lircrc hasn't changed, and it's in its right place for MythTV, so who knows where the problem is. For my primary PVR frontend, I'm going to stick with the old lirc-0.8.7 which means a 2.6.35-r15 kernel. That's acceptable on that frontend, but my backend (which also doubles as a secondary frontend in the basement) has to roll with a newer kernel, so this 0.9.0_pre1 ebuild is necessary to accomodate a >= 2.6.36 kernel. As Henning stated above, lirc-0.8.7 should not be built for kernels >= 2.6.36. We should at least prevent that.
(In reply to comment #27) > What fails, the patch or the current version? > LIRC project is moving all of their drivers into the staging area of the > kernel, if you are using a kernel >= 2.6.36 you must enable them. Adam, What Robert Lippman (comment 26) was referring to is that the new drivers/lirc 0.90 do not support serial IR Transmitters (e.g. IR Blaster or homebrew transmitters). This is a bug known to upstream (Jarod Wilson, LIRC maintainer). I've communicated with Jarod and he gave me this link (which I haven't tried, time constraints): https://bugzilla.redhat.com/show_bug.cgi?id=658600 He did however send a follow-up email saying: "General-purpose fix is merged in the v4l/dvb tree now, and in lirc git." That sound pretty cool, unfortunately, I don't really know how to apply it. Until this is resolved, however, I'm stuck at 2.6.35 and lirc 0.87 as are all who use lirc with a serial transmitter. Can you make heads or tails of his comments? -- Jeff
(In reply to comment #27) > What fails, the patch or the current version? > LIRC project is moving all of their drivers into the staging area of the > kernel, if you are using a kernel >= 2.6.36 you must enable them. Sorry, got sidetracked (grr, Comcast). Didn't know that the staging drivers need to be enabled with 2.6.36 and higher. Having that warning about needing staging drivers and lirc 0.90 would have helped a great deal. It hasn't popped up for me doing a module-rebuild on the 2.6.36 kernels. I didn't know IR blasters don't work even with lirc 0.90. Guess I'm stuck on 2.6.35 and lirc 0.87 too.
Robert, That warning is in the ebuild, it warns: ewarn "You have a kernel greater than or equal to 2.6.36, lirc modules" ewarn "are now bundled with your kernel, please configure your kernel" ewarn "to enable staging drivers and select the respective lirc devices" Are you using the same ebuild? It should have told you that unless you were using an older kernel.
Greg, Your problem with the MCE remote I believe is a bug upstream.
(In reply to comment #28) > Thanks, Adam, for your work on this. The lirc-0.9.0_pre1 ebuild worked for me > using the staging drivers from the gentoo-sources-2.6.37-r1 kernel. All of the > buttons on my mceusb remote work, but they seem to repeat hyperactively. VERY > touchy. Single keypresses like volume up will repeat a dozen or more times. > Same thing happens in the main MythTV menu where it makes it hard to land on > the desired menu item. My lircrc hasn't changed, and it's in its right place > for MythTV, so who knows where the problem is. > > For my primary PVR frontend, I'm going to stick with the old lirc-0.8.7 which > means a 2.6.35-r15 kernel. That's acceptable on that frontend, but my backend > (which also doubles as a secondary frontend in the basement) has to roll with a > newer kernel, so this 0.9.0_pre1 ebuild is necessary to accomodate a >= 2.6.36 > kernel. > > As Henning stated above, lirc-0.8.7 should not be built for kernels >= 2.6.36. > We should at least prevent that. Actually just out of curiosity could you post me your lircrc? There's a "repeat" option that you likely have to tweak to make it behave the way you want.
IMO, LIRC either needs to be removed from the tree or fixed. This situation is becoming increasingly problematic as more people will be moving to the current stable kernel series over time. It looks as if most of the recent past commits to the LIRC ebuild were made by Christian Faulhammer who is currently flagged as "away" on the dev page. This build might need a new maintainer (at least temporarily).
Created attachment 267103 [details] lircrc used by mceusb remote and MythTV Attached my lircrc. I tried tweaking the "repeat = X" lines to no avail. What I'm seeing is that arrow buttons repeat a lot, but I have to hit numbers twice for them to be registered. irw testing on the command line is similar, and I see some funky, non-remote related characters intermittently.
mceusb driver send the arrow keys as keyboard input and to lirc ... so you got the double press. Have a look at cat /sys/class/rc/rc0/protocols if you do a echo none +lirc > /sys/class/rc/rc0/protocols the keyboard input is disabled. i don't know how to disable this when you load the module. the default settings from the lirc.conf.mceusb didn't work for me ... i have to set the gap to 155000 (very laggy) (In reply to comment #35) > Created attachment 267103 [details] > lircrc used by mceusb remote and MythTV > Attached my lircrc. I tried tweaking the "repeat = X" lines to no avail. What > I'm seeing is that arrow buttons repeat a lot, but I have to hit numbers twice > for them to be registered. irw testing on the command line is similar, and I > see some funky, non-remote related characters intermittently.
Updating importance to major, this bug report has been stagnating for far too long.
FWIW, 0.9.0 has been officially released. http://sourceforge.net/mailarchive/forum.php?thread_name=528FF319-D1D9-4B89-8430-3DAB56A43151%40wilsonet.com&forum_name=lirc-list
>... the new drivers/lirc > 0.90 do not support serial IR Transmitters (e.g. IR Blaster or homebrew > transmitters). This is a bug known to upstream (Jarod Wilson, LIRC > maintainer). I've communicated with Jarod and he gave me this link (which I > haven't tried, time constraints): > > https://bugzilla.redhat.com/show_bug.cgi?id=658600 > > He did however send a follow-up email saying: > "General-purpose fix is merged in the v4l/dvb tree now, and in lirc git." > > That sound pretty cool, unfortunately, I don't really know how to apply it. > Until this is resolved, however, I'm stuck at 2.6.35 and lirc 0.87 as are all > who use lirc with a serial transmitter. Can you make heads or tails of his > comments? > > -- Jeff Okay, so the "fix" for the serial transmitter is is a kernel patch. Apparently, there is a typo in lirc_serial.c. I'm attaching a kernel patch that can fix this, taken from the redhat bug listed above (note that although this is a simple patch, I've never created one before, so use at your own risk). This is confirmed to work on my Gentoo with lirc 0.9.0 and Kernel 2.6.37-r4. Without the patch, the transmit function of a serial lirc device still fails. -- Jeff
Created attachment 272441 [details, diff] Patch to solve serial transmitter problems in the kernel staging drivers.
gentoo-sources-2.6.38-r5 appears to have this patch already applied in the source tree.
For myself, the new input level ir drivers have allowed me to drop lirc from my HTPC setup completely. All I had to do was to get my ir-keytable set up to be consistent with the keyboard.
oh, and I still don't get a warning telling me to enable staging drivers with lirc 0.8.7 and kernel 2.6.37 when I do a module-rebuild populate or module-rebuild rebuild
(In reply to comment #43) > oh, and I still don't get a warning telling me to enable staging drivers with > lirc 0.8.7 and kernel 2.6.37 when I do a module-rebuild populate or > module-rebuild rebuild Robert, try rebooting into your newly configured >=2.6.37 kernel. I wrote the ebuild do check your kernel version and not necessarily the latest kernel sources ebuild you have installed.
Since lirc-0.9.0 entered the portage tree some time ago, I guess this bug could be closed now.
