I had a Fedora 12, on which lirc was working fine. Philips (I think) OVU4003/00 IR receiver, Harmony One remote (device type set to Plex Player), mostly used for controlling XBMC. Then I did a clean Fedora 14, restored my /etc/lirc/lircd.conf, but it doesn't work anymore. I see signals being received with mode2, but irw doesn't show anything. Steps to Reproduce: Start lirc, which produces in the log: lircd-0.8.7[9819]: lircd(devinput) ready, using /var/run/lirc/lircd Then start irw: lircd-0.8.7[9819]: accepted new client on /var/run/lirc/lircd lircd-0.8.7[9819]: initializing '/dev/lirc0' lircd-0.8.7[9819]: can't get exclusive access to events coming from `/dev/lirc0' interface Pressing buttons on the remote gives me a lot of: lircd-0.8.7[9819]: error reading '/dev/lirc0' lircd-0.8.7[9819]: error reading '/dev/lirc0' I saw some mentions on Internet about possible conflicts with HAL, so I stopped the HAL service, but nothing changes. Expected results: irw should echo the pressed buttons. Fedora is up-to-date, using lirc from the Fedora repository. As I said, it worked just fine with Fedora 12.
An update about this bug: the error about exclusive access occurs when LIRC_DRIVER=devinput. When setting LIRC_DRIVER=default, using the same lircd.conf that I used with Fedora 12, I don't get the error anymore, but the remote still doesn't work properly. A few buttons are recognized constantly by irw (e.g. LargeUp, LargeDown - see attached conf), other buttons are recognized only occasionally. Most buttons don't work though. I don't know if this is the same issue or should be reported as a separate one.
Created attachment 468428 [details] Config file which worked fine in F12 but doesn't work in F14 anymore This is a configuration file which used to work in F12 with my Harmony One remote, device set to Plex Player, using an OVU4003/00 IR receiver (probably from Philips).
I found a description of a similar problem: buttons not being recognized or recognized occasionally after an F12 - F14 upgrade: http://www.gossamer-threads.com/lists/mythtv/users/464311 I tried installing the suggested media_build.git, but I get the same build error as the other poster mentioned on that thread. Some more details, if needed: kernel 2.6.35.9-64.fc14.x86_64 (F14 up-to-date) lirc-0.8.7-1.fc14.x86_64
This is a problem for me also. F12 -> F14 clean installation, although I'm running on a 32 bit installation. I'm using the same eHome USB transceiver. Buttons are recognized, but you usually have to push the remote button 2 times to see 1 line of output in IRW. My same config files worked without problems through F10, F11, and F12, and are based on Jarod's previous great documentation. I also found this thread (http://www.gossamer-threads.com/lists/mythtv/users/464311), but I haven tried the compile and install. I'm assuming a fix will be coming down the line, and I hoping when this bug closes, I will get a heads up.
Yeah, I'm attempting to find the time to get this fixed, just been very busy with other things. I've reproduced what's definitely incorrect behavior here, I just haven't yet figured out what the fix is. I swear I already fixed this issue in the upstream tree, but as far as I can see at the moment, all the relevant code is identical, so I need to get a closer look at what's happening in the buffer parsing routine that's screwing things up.
If I can help with anything (more information, testing etc.) please let me know.
I've just submitted a build that I've already built and tested locally, and it resolves the issues I was seeing here. Everyone please have at it when its done... http://koji.fedoraproject.org/koji/taskinfo?taskID=2667815
Sigh. Make that: http://koji.fedoraproject.org/koji/taskinfo?taskID=2667844
I installed updating just the kernel from the test-update repository (2.6.35.10-68.fc14.x86_64), but unfortunately my system won't start (issues with smartd and some other services). Probably I would have to install more stuff from test-update, but I'm afraid for the system's stability. So I'll wait until the updated kernel shows up in the standard updates. In the mean time, now I don't even have a /dev/lirc0: lircd-0.8.7[3386]: accepted new client on /var/run/lirc/lircd lircd-0.8.7[3386]: could not get file information for /dev/lirc0 lircd-0.8.7[3386]: default_init(): No such file or directory lircd-0.8.7[3386]: Failed to initialize hardware I'm not sure if it's related to the present bugreport. I'm also not sure what caused it. I've installed some updates recently and I've installed PulseAudio, including also a package called pulseaudio-module-lirc. Something there made things worse, but I don't know which. Trying to manually load any lirc_* module gives me: [root@hermes ~]# modprobe lirc_i2c FATAL: Error inserting lirc_i2c (/lib/modules/2.6.35.9-64.fc14.x86_64/kernel/drivers/staging/lirc/lirc_i2c.ko): Unknown symbol in module, or unknown parameter (see dmesg) And in the log: kernel: [ 673.401650] lirc_i2c: module is from the staging directory, the quality is unknown, you have been warned. kernel: [ 673.401837] lirc_i2c: Unknown symbol lirc_unregister_driver (err 0) kernel: [ 673.402144] lirc_i2c: Unknown symbol lirc_register_driver (err 0) Anyway, when I get a kernel update I'll let you know how things are.
I got the latest updates (kernel 2.6.35.10-72.fc14.x86_64), but unfortunately no good news. The service starts OK now (using default driver), but no buttons are recognized from the remote. I tried using gnome-lirc-properties as well (devinput driver), still no reaction. There are no errors in the logs. lircd-0.8.7[6120]: lircd(devinput) ready, using /var/run/lirc/lircd lircd-0.8.7[6120]: accepted new client on /var/run/lirc/lircd lircd-0.8.7[6120]: initializing 'name=Media?Center?Ed.?eHome?Infrared?Remote?Transceiver?(0471:0815)' Furthermore, I can't even use irrecord anymore (it worked fine in F12): -------------------------------------------------- Press RETURN now to start recording. ................................................................................ Found gap: 114342 Please keep on pressing buttons like described above. ................................................................................ Space/pulse encoded remote control found. Signal length is 71. No header found. Found trail pulse: 586 Found repeat code: 8973 2199 Found repeat gap: 114342 Signals are space encoded. Signal length is 35 Now enter the names for the buttons. Please enter the name for the next button (press <ENTER> to finish recording) KEY_UP Now hold down button "KEY_UP". Something went wrong. Please try again. (9 retries left) Something went wrong. Please try again. (8 retries left) .... --------------------------------------------------
(In reply to comment #10) > I got the latest updates (kernel 2.6.35.10-72.fc14.x86_64), but unfortunately > no good news. The service starts OK now (using default driver), but no buttons > are recognized from the remote. Which lircd.conf are you using where no buttons are recognized? I've got five different mceusb-driven devices, and they all work perfectly here w/that kernel. > I tried using gnome-lirc-properties as well (devinput driver), still no > reaction. There are no errors in the logs. > > lircd-0.8.7[6120]: lircd(devinput) ready, using /var/run/lirc/lircd > lircd-0.8.7[6120]: accepted new client on /var/run/lirc/lircd > lircd-0.8.7[6120]: initializing > 'name=Media?Center?Ed.?eHome?Infrared?Remote?Transceiver?(0471:0815)' > > Furthermore, I can't even use irrecord anymore (it worked fine in F12): Hrm. Not sure what's up there. Might be worth trying out lirc 0.9.0-pre1, which is in f14 updates-testing now.
Thank you again for looking into this. Regarding the config file, I'm trying two things. 1. With the default driver, I'm using the configuration file which you see attached to this bug (HarmonyPlex). The remote control, Harmony One, is configured to emulate a Plex media player - and that's the configuration which was working for me in F12. In irw no key presses are shown, although mode2 shows signals coming in. 2. I've also used the gnome-lirc-properties GUI tool, which sets the driver to devinput. The tool correctly detects the Philis IR receiver device. I've tried in that tool to set different types of remotes (updating the Harmony One accordingly), none of them worked. If you want, maybe you can send me one or two config files that I can try. Just tell me for what kind of remotes they are, so I can configure the Harmony to emulate them. I'll try to install lirc 0.9.0-pre1 as well and will let you know if I get a different result.
Jarod, I just installed the kernel updates and verified that it's not working for me either (from comment #4). In IRW, I see these results: 1) some keys don't show results at all. 2) for some keys, you have to double push to get a result. 3) some keys return one results the first click, then two (or three) results the second click, then alternates back to one result per click. I was using a Logitech Harmany set up to simulate a Hauppauge PVR-350. I went back to the original Hauppauge PVR 350 remote and verified the same results. My eHome USB receiver is model 1040 and looks like this: (http://plone.lucidsolutions.co.nz/linux/mythtv/microsoft-remote-control-and-receiver-1.0a-for-media-center-pc-with-windows-model-1040) Based on your suggestion to Sebastian, in comment 11, I installed lirc 0.9.0-pre1 from f14 updates-testing, but it looks like the same results. In case it helps, here is my /etc/lircd.conf file: #################################################### # This file is: /etc/lircd.conf # # this config file was automatically generated # using lirc-0.7.0(any) on Sun Nov 28 20:25:09 2004 # # contributed by # # brand: Hauppauge 350 # Created: G.J. Werler (The Netherlands) # Project: Mythtv Fedora Pundit-R www.mythtvportal.com # Date: 2004/11/28 # model no. of remote control: Hauppauge A415-HPG # devices being controlled by this remote: PVR-350 # begin remote name Hauppauge_350 bits 13 flags RC5|CONST_LENGTH eps 30 aeps 100 one 969 811 zero 969 811 plead 1097 gap 114605 toggle_bit 2 begin codes Go 0x00000000000017BB Power 0x00000000000017BD TV 0x000000000000179C Videos 0x0000000000001798 Music 0x0000000000001799 Pictures 0x000000000000179A Guide 0x000000000000179B Radio 0x000000000000178C Up 0x0000000000001794 Left 0x0000000000001796 Right 0x0000000000001797 Down 0x0000000000001795 OK 0x00000000000017A5 Back/Exit 0x000000000000179F Menu/i 0x000000000000178D Vol+ 0x0000000000001790 Vol- 0x0000000000001791 Prev.Ch 0x0000000000001792 Mute 0x000000000000178F Ch+ 0x00000000000017A0 Ch- 0x00000000000017A1 Record 0x00000000000017B7 Stop 0x00000000000017B6 Rewind 0x00000000000017B2 Play 0x00000000000017B5 Forward 0x00000000000017B4 Replay/SkipBackward 0x00000000000017A4 Pause 0x00000000000017B0 SkipForward 0x000000000000179E 1 0x0000000000001781 2 0x0000000000001782 3 0x0000000000001783 4 0x0000000000001784 5 0x0000000000001785 6 0x0000000000001786 7 0x0000000000001787 8 0x0000000000001788 9 0x0000000000001789 Asterix 0x000000000000178A 0 0x0000000000001780 Menu/x 0x000000000000178E Red 0x000000000000178B Green 0x00000000000017AE Yellow 0x00000000000017B8 Blue 0x00000000000017A9 end codes end remote # End of /etc/lircd.conf
Hell. Admittedly, I've not done a *huge* amount of testing of the new mceusb code w/anything but its stock remote. I swear I've tried the grey Hauppauge remotes recently though. Will look into it over the upcoming week...
Merry Christmas! And don't worry Jarod, we know you're putting a lot of work into this. As I said, I could test some configurations, to see what results I get on my hardware. I can configure the Harmony One to emulate whatever needed device/remote - just let me know how I can help, it's the least I can do.
Jarod, One more thing that may be interesting to you. After seeing your comment about the stock remote, I found mine in the bottom of an old box, and changed my lircd.conf file to this one (http://www.koders.com/noncode/fid6D67FFD81B8B2CFC2D73CE4C64380F5913D7AB15.aspx), and now my setup works with the stock remote. Merry Christmas all. I agree with Sebastian. We appreciate the work you've done on this. Fedora and MythTV just keep getting better. Thanks.
So I finally took a look at this with one of my mceusb transceivers and a grey Hauppauge remote... For the most part, its actually working just fine for me. Short presses all register perfectly with both the in-kernel rc-5 decoder and with lirc, though I say "for the most part", as when I hold a button down, the repeat is a touch sporadic (seems to burst 3 at a time) and upon release, I get a second new event. So there's definitely something slightly off, and I'll see if I can fix that, and maybe it'll help with the issues others are seeing as well. I'll also try the plex config with my own harmony remote, and perhaps some of my other mceusb devices, as some of them do behave slightly different (using the pinnacle one here right now for initial testing).
Same machine, same kernel, same remote (grey hauppauge rc5), different mceusb device, and irw doesn't report a single keypress. Now we're getting somewhere. :) On with some further debugging...
Got it figured out. Patched kernel build forthcoming.
2.6.35.10-76.fc14 is building right now. http://koji.fedoraproject.org/koji/buildinfo?buildID=212815
I'm looking forward to trying the update, to see if I get my previous Plex config working. In the meantime, I did get lirc working with an mce keyboard profile (see attached). In fact, things were working too well after the recent updates, now the kernel was picking up some IR commands too and XBMC was seeing them double. Fixed by unloading some kernel modules and leaving only lirc to handle IR.
Created attachment 472354 [details] Config file which works for me in F14 too.
(In reply to comment #21) > I'm looking forward to trying the update, to see if I get my previous Plex > config working. Fingers crossed. Pretty sure it'll behave. The specific change to fix this issue, for anyone that is curious: http://git.linuxtv.org/jarod/linux-2.6-ir.git?a=commitdiff;h=4eb7b1041ea7b2c51752da158d6dae8ee29a8de5 > In the meantime, I did get lirc working with an mce keyboard profile (see > attached). In fact, things were working too well after the recent updates, now > the kernel was picking up some IR commands too and XBMC was seeing them double. > Fixed by unloading some kernel modules and leaving only lirc to handle IR. No need to unload modules, just 'echo lirc > /sys/class/rc/rc0/protocols', to set only the lirc decoder to active. The lirc packages in updates-testing do exactly that, for exactly the reason you describe. :)
kernel-2.6.35.11-83.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.11-83.fc14
kernel-2.6.35.11-83.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Jarod, I just ran updates, which loaded kernel-2.6.35.11-83.fc14.686, and I verified that this kernel works with both the stock remote and my original Hauppauge 350 configuration. My remote issue has been resolved. Good work - as always. Thanks, Mike
I am getting nothing from irw though I do get at least some codes from mode2. irw doesn't give any error messages but I do get a message that lircd has accepted a new client in the messages log. But irw doesn't return any thing. I am using an MCE remote and my set up worked fine in the past. I tried down grading to kernel-2.6.35.6-46.fc14.x86_64 which one of the links above suggested should work but it doesn't. These are the versions I am running. kernel-2.6.35.11-83.fc14.x86_64 lirc-remotes-0.9.0-0.1.pre1.fc14.x86_64 lirc-libs-0.9.0-0.1.pre1.fc14.x86_64 lirc-0.9.0-0.1.pre1.fc14.x86_64 Thanks for the effort
(In reply to comment #27) > I am getting nothing from irw though I do get at least some codes from mode2. > irw doesn't give any error messages but I do get a message that lircd has > accepted a new client in the messages log. But irw doesn't return any thing. I > am using an MCE remote and my set up worked fine in the past. Need more info. What usb device ID does your receiver have, and what lircd.conf are you using?
Please disregard comment 27. While reading through dmesg I discovered that the system has an internal IR reciever I didn't know about and wasn't detecting before. It is now loading a driver for it. This pushed my external reciever to device 1 from device 0 and was causing the problem. Sorry for adding to your work load.
Phew. Okay, I'm going to CLOSED->CURRENTRELEASE this bug then. :)