From: James S. <jam...@gm...> - 2011-04-04 14:40:33
|
I have an MCE IR receiver that is recognized as "Topseed Technology Corp. eHome Infrared Transceiver." Specifically, it is the one included in [1]. The `lsusb -v` output for this reciever is available in [2]. If I use the new upstream modules, mceusb and rc_rc6_mce, my receiver does not work. I can run `irw`, press buttons on my remote, and get no output. But when I switch to the old lirc driver, lirc_mceusb, specifically the one from Git branch a875cfd [3], then my remote works as expected. Using the lirc_mceusb driver, I can use `irw` and see codes for the buttons on my remote as I have them mapped. At some point, the old driver isn't going to work with a new kernel (I just updated to 2.6.37). So I would like to do what I can to get this resolved. What other information would you need from me? [1] -- http://www.newegg.com/Product/Product.aspx?Item=N82E16880121002 [2] -- http://dl.dropbox.com/u/1038672/mce_ir_receiver.txt [3] -- http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commit;h=04eb7eddbe93f7b5df4b59d379116c90ead18fe7 ~ James |
From: Jarod W. <ja...@wi...> - 2011-04-04 16:20:51
|
On Apr 4, 2011, at 10:39 AM, James Sumners wrote: > I have an MCE IR receiver that is recognized as "Topseed Technology > Corp. eHome Infrared Transceiver." Specifically, it is the one > included in [1]. The `lsusb -v` output for this reciever is available > in [2]. > > If I use the new upstream modules, mceusb and rc_rc6_mce, my receiver > does not work. I can run `irw`, press buttons on my remote, and get no > output. But when I switch to the old lirc driver, lirc_mceusb, > specifically the one from Git branch a875cfd [3], then my remote works > as expected. Using the lirc_mceusb driver, I can use `irw` and see codes > for the buttons on my remote as I have them mapped. > > At some point, the old driver isn't going to work with a new kernel (I > just updated to 2.6.37). So I would like to do what I can to get this > resolved. What other information would you need from me? I have the exact same hardware, and it works perfectly fine with the mceusb driver in 2.6.38 with a variety of different remotes. Please try 2.6.38 and/or the current media tree. If that's not working, we can dig into things further. If it is, we can look at what's required to get mceusb working better in 2.6.37.x via the -stable tree. http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers -- Jarod Wilson ja...@wi... |
From: James S. <jam...@gm...> - 2011-04-04 17:44:12
|
I will build the newer drivers for my current kernel since 2.6.38 isn't in Arch Linux stable yet. ~ James On 4/4/2011 12:20, Jarod Wilson wrote: > I have the exact same hardware, and it works perfectly fine with the > mceusb driver in 2.6.38 with a variety of different remotes. Please > try 2.6.38 and/or the current media tree. If that's not working, we > can dig into things further. If it is, we can look at what's required > to get mceusb working better in 2.6.37.x via the -stable tree. > > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers > |
From: James S. <jam...@gm...> - 2011-04-05 00:30:07
|
On 2011-04-04 12:20:51 -0400, Jarod Wilson <ja...@wi...> said: > I have the exact same hardware, and it works perfectly fine with the > mceusb driver in 2.6.38 with a variety of different remotes. Please > try 2.6.38 and/or the current media tree. If that's not working, we > can dig into things further. If it is, we can look at what's required > to get mceusb working better in 2.6.37.x via the -stable tree. > > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I > have built the backported linux-media drivers (branch: a500c7f) for my 2.6.37 kernel. I blacklisted the lirc_mceusb module and rebooted (just to be sure). Upon boot, I checked dmesg to verify that the new modules loaded. The relevant lines are in [1]. To be sure everything is up-to-date, I installed the most recent Lirc packages for my distribution -- [2] and [3]. With the new modules loaded, I tried irw and got no output. I then stopped lircd and tried irrecord. This also resulted in no output and irrecord quitting with the following messages: irrecord: no data for 10 secs, aborting irrecord: gap not found, can't continue However, if I view my kernel log (dmesg output), I see the debug information from mceusb that is in [4]. Simply removing the new modules and reloading the old one gives me a working remote again. [1] -- http://dl.dropbox.com/u/1038672/mceusb/dmesg_a.txt [2] -- http://www.archlinux.org/packages/extra/x86_64/lirc/ [3] -- http://projects.archlinux.org/svntogit/packages.git/commit/lirc/repos/extra-x86_64?id=8fd92141d15146512fc95ac650b7c0aae9ac02cc [4] -- http://dl.dropbox.com/u/1038672/mceusb/dmesg_b.txt |
From: Jarod W. <ja...@wi...> - 2011-04-06 14:29:54
|
On Apr 4, 2011, at 8:29 PM, James Sumners wrote: > On 2011-04-04 12:20:51 -0400, Jarod Wilson > <ja...@wi...> said: >> I have the exact same hardware, and it works perfectly fine with the >> mceusb driver in 2.6.38 with a variety of different remotes. Please >> try 2.6.38 and/or the current media tree. If that's not working, we >> can dig into things further. If it is, we can look at what's required >> to get mceusb working better in 2.6.37.x via the -stable tree. >> >> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers > > I >> > have built the backported linux-media drivers (branch: a500c7f) for my > 2.6.37 kernel. I blacklisted the lirc_mceusb module and rebooted (just > to be sure). Upon boot, I checked dmesg to verify that the new modules > loaded. The relevant lines are in [1]. > > To be sure everything is up-to-date, I installed the most recent Lirc > packages for my distribution -- [2] and [3]. > > With the new modules loaded, I tried irw and got no output. I think I forgot to ask for clarification... What remote are you using here? I've double-checked that my identical hardware works perfectly with both in-kernel decode and lirc userspace decode w/an mce remote, using lirc 0.9.0 and a 2.6.38 kernel. > I then > stopped lircd and tried irrecord. This also resulted in no output and > irrecord quitting with the following messages: > > irrecord: no data for 10 secs, aborting > irrecord: gap not found, can't continue > > However, if I view my kernel log (dmesg output), I see the debug > information from mceusb that is in [4]. Might try enabling rc_core debug=1 as well. > Simply removing the new modules and reloading the old one gives me a > working remote again. I tried an mce remote (rc6), a hauppauge remote (rc5) and a tivo remote (nec-ish), and all worked perfectly with my hardware here, so yeah, please confirm what remote you're using. I'm stymied at the moment, since none of my mceusb hardware is exhibiting this problem. -- Jarod Wilson ja...@wi... |
From: James S. <jam...@gm...> - 2011-04-07 13:50:11
|
On 4/6/2011 10:29, Jarod Wilson wrote: > I think I forgot to ask for clarification... What remote are you using > here? I've double-checked that my identical hardware works perfectly > with both in-kernel decode and lirc userspace decode w/an mce remote, > using lirc 0.9.0 and a 2.6.38 kernel. > ... > I tried an mce remote (rc6), a hauppauge remote (rc5) and a tivo remote > (nec-ish), and all worked perfectly with my hardware here, so yeah, > please confirm what remote you're using. I'm stymied at the moment, > since none of my mceusb hardware is exhibiting this problem. > I am using a Logitech Harmony 550 remote[1] configured as a second generation TiVo remote ([2], bottom of the page). My lircd.conf is at [3], if that helps. I loaded the rc_core module with the debug flag set, but didn't see anything new. Note: the only reason I'm loading the rc6 module is because it gets automatically detected at boot. So I figured it was required by the mceusb module. If there is a different one I should load, I don't know about it. ~ James [1] -- http://www.amazon.com/Logitech-Harmony-Universal-Remote-Control/dp/B001NLZ17W [2] -- http://www.tivopedia.com/model-tivo-tcd140060.php [3] -- http://dl.dropbox.com/u/1038672/mceusb/lircd.conf |
From: Jarod W. <ja...@wi...> - 2011-04-07 21:23:00
|
On Apr 7, 2011, at 9:49 AM, James Sumners wrote: > On 4/6/2011 10:29, Jarod Wilson wrote: >> I think I forgot to ask for clarification... What remote are you using >> here? I've double-checked that my identical hardware works perfectly >> with both in-kernel decode and lirc userspace decode w/an mce remote, >> using lirc 0.9.0 and a 2.6.38 kernel. >> ... >> I tried an mce remote (rc6), a hauppauge remote (rc5) and a tivo remote >> (nec-ish), and all worked perfectly with my hardware here, so yeah, >> please confirm what remote you're using. I'm stymied at the moment, >> since none of my mceusb hardware is exhibiting this problem. >> > > I am using a Logitech Harmony 550 remote[1] configured as a second > generation TiVo remote ([2], bottom of the page). My lircd.conf is at > [3], if that helps. > > I loaded the rc_core module with the debug flag set, but didn't see > anything new. > > Note: the only reason I'm loading the rc6 module is because it gets > automatically detected at boot. So I figured it was required by the > mceusb module. If there is a different one I should load, I don't know > about it. Had a thought last night... Whatcha get from this command: $ cat /sys/class/rc/rc0/protocols ? Wondering if the lirc bridge simply isn't active. The rc6 module is only needed for in-kernel decode of the stock mce remotes (well, or any other rc6 remote). The tivo remotes use an nec-ish protocol, but that's largely irrelevant in the case where you're looking to do lirc userspace decode instead of in-kernel decode. Nb: I've got an actual TiVo remote here, and it works fine w/the same receiver hardware you have and my 2.6.38 kernel. -- Jarod Wilson ja...@wi... |
From: James S. <jam...@gm...> - 2011-04-08 01:11:01
|
On 2011-04-07 17:23:01 -0400, Jarod Wilson <ja...@wi...> said: > > Had a thought last night... Whatcha get from this command: > > $ cat /sys/class/rc/rc0/protocols Okay, here's everything in the order I did it: [root] ~/ # init 3 [root] ~/ # /etc/rc.d/lircd stop :: Stopping LIRC Daemon [DONE] [root] ~/ # rmmod lirc_mceusb [root] ~/ # modprobe mceusb [root] ~/ # cat /sys/class/rc/rc0/protocols rc-5 nec [rc-6] jvc sony lirc And then `lsmod` gives me: Module Size Used by ir_lirc_codec 4523 0 ir_sony_decoder 2171 0 ir_jvc_decoder 2265 0 ir_rc6_decoder 2777 0 ir_rc5_decoder 2265 0 rc_rc6_mce 1396 0 ir_nec_decoder 2681 0 mceusb 12191 0 rc_core 15487 9 ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,rc_rc6_mce,ir_nec_decoder,mceusb And my kernel log thus far (no buttons on my remote having been pressed) is in [1]. > > > Wondering if the lirc bridge simply isn't active. The rc6 module is > only needed for in-kernel decode of the stock mce remotes (well, or > any other rc6 remote). The tivo remotes use an nec-ish protocol, > but that's largely irrelevant in the case where you're looking to do > lirc userspace decode instead of in-kernel decode. Next, I tried this: [root] ~/ # rmmod ir_sony_decoder ir_jvc_decoder ir_rc6_decoder rc_rc6_mce ir_nec_decoder [root] ~/ # /etc/rc.d/lircd start :: Starting LIRC Daemon [DONE] [root] ~/ # irw I pressed some buttons on my remote and got nothing, but the kernel log shows IR events happened. With the mceusb module loaded, I have the following devices: [root] ~/ # ls -l /dev/lirc* crw------- 1 root root 250, 0 Apr 7 20:43 /dev/lirc0 lrwxrwxrwx 1 root root 19 Apr 7 20:57 /dev/lircd -> /var/run/lirc/lircd [root] /sys/bus/usb/devices/3-2/ # ls -l /dev/mce* crw------- 1 root root 10, 227 Apr 6 19:19 /dev/mcelog [root] ~/ # ls -l /dev/input/by-id/usb-Topseed_Technology_Corp._eHome_Infrared_Transceiver_TS0002hz-event-if00 lrwxrwxrwx 1 root root 9 Apr 7 20:43 /dev/input/by-id/usb-Topseed_Technology_Corp._eHome_Infrared_Transceiver_TS0002hz-event-if00 -> ../event7 Now here's one that confuses me: [root] ~/ # cat /var/run/lirc/lircd cat: /var/run/lirc/lircd: No such device or address I don't know what else to do. ~ James [1] -- http://dl.dropbox.com/u/1038672/mceusb/4-7-2011_kernel.log |
From: Jarod W. <ja...@wi...> - 2011-04-08 13:48:31
|
On Apr 7, 2011, at 9:10 PM, James Sumners wrote: > On 2011-04-07 17:23:01 -0400, Jarod Wilson > <ja...@wi...> said: >> >> Had a thought last night... Whatcha get from this command: >> >> $ cat /sys/class/rc/rc0/protocols ... > [root] ~/ # cat /sys/class/rc/rc0/protocols > rc-5 nec [rc-6] jvc sony lirc That's it right there. Only the "protocols" with braces around them are active. See how it behaves if you: # echo lirc > /sys/class/rc/rc0/protocols Essentially, no data is passed from the rc-core layer to the lirc bridge driver, which feeds /dev/lirc0, when the lirc "protocol" isn't active. Something that didn't register for me until last night is that there does appear to be something limiting active protocols now in 2.6.38, which wasn't the case in earlier kernels (my primary 2.6.32 setup, all protocols, including lirc, are active by default). -- Jarod Wilson ja...@wi... |
From: James S. <jam...@gm...> - 2011-04-11 13:41:03
|
On 4/8/2011 09:48, Jarod Wilson wrote: > # echo lirc> /sys/class/rc/rc0/protocols > > Essentially, no data is passed from the rc-core layer to the > lirc bridge driver, which feeds /dev/lirc0, when the lirc "protocol" > isn't active. > > Something that didn't register for me until last night is that there > does appear to be something limiting active protocols now in 2.6.38, > which wasn't the case in earlier kernels (my primary 2.6.32 setup, > all protocols, including lirc, are active by default). Sorry, it was a busy weekend. I'll give this a go tonight. ~ James |
From: Jarod W. <ja...@wi...> - 2011-04-11 18:40:34
|
On Apr 11, 2011, at 9:40 AM, James Sumners wrote: > On 4/8/2011 09:48, Jarod Wilson wrote: >> # echo lirc> /sys/class/rc/rc0/protocols >> >> Essentially, no data is passed from the rc-core layer to the >> lirc bridge driver, which feeds /dev/lirc0, when the lirc "protocol" >> isn't active. >> >> Something that didn't register for me until last night is that there >> does appear to be something limiting active protocols now in 2.6.38, >> which wasn't the case in earlier kernels (my primary 2.6.32 setup, >> all protocols, including lirc, are active by default). > > Sorry, it was a busy weekend. I'll give this a go tonight. There's another problem I've encountered. A bug in v4l-utils' ir-keytable, which in recent releases, is auto-run on boot via udev, is screwing up the key mapping table. If you disable the rule in 70-ir-properties.rules (iirc), you should get better results... -- Jarod Wilson ja...@wi... |
From: James S. <jam...@gm...> - 2011-04-14 00:14:46
|
On 2011-04-11 14:40:32 -0400, Jarod Wilson <ja...@wi...> said: >> On 4/8/2011 09:48, Jarod Wilson wrote: >>> # echo lirc> /sys/class/rc/rc0/protocols > There's another problem I've encountered. A bug in v4l-utils' > ir-keytable, which in recent releases, is auto-run on boot via > udev, is screwing up the key mapping table. If you disable the > rule in 70-ir-properties.rules (iirc), you should get better > results... Okay, here's what I have done. First, I blacklisted the following modules: rc_rc6_mce ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder lirc_mceusb Then I commented out the following line in my /etc/udev/rules.d/70-infrared.rules: ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name" After rebooting: [root] ~/ # cat /sys/class/rc/rc0/protocols [rc-5] [nec] [rc-6] [jvc] [sony] [lirc] [root] ~/ # lsmod Module Size Used by lirc_dev 11671 1 ir_lirc_codec ir_sony_decoder 2171 0 ir_jvc_decoder 2265 0 ir_rc6_decoder 2777 0 rc_rc6_mce 1396 0 ir_rc5_decoder 2265 0 ir_nec_decoder 2681 0 mceusb 12191 0 rc_core 15487 9 ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,rc_rc6_mce,ir_rc5_decoder,ir_nec_decoder,mceusb usbcore 139496 6 mceusb,xpad,ohci_hcd,ehci_hcd,usbhid ... I don't know why all of these decoder modules have loaded. I have them explicitly disabled. Anyway, at this point I tried irw and received no output. Which lead me to: [root] /etc/udev/rules.d/ # cat /var/run/lirc/lircd cat: /var/run/lirc/lircd: No such device or address So I did: [root] ~/ # echo lirc > /sys/class/rc/rc0/protocols [root] ~/ # cat /sys/class/rc/rc0/protocols rc-5 nec rc-6 jvc sony [lirc] Still no device at /var/run/lirc/lircd. Checking dmesg: ... WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to lin...@vg...): 0b1b920610a4d41c584e97d38b5ce497c4a303d7 [media] drxd: use mutex instead of semaphore a8e8541bc7af59ec07e810bd29aa827878389d82 Remove the now obsolete drx397xD 9b2dd144435e397b6ed2a75d522b49868aef98a5 [media] drxd: CodingStyle cleanups mceusb 3-2:1.0: mceusb_dev_probe called mceusb 3-2:1.0: acceptable outbound endpoint found mceusb 3-2:1.0: acceptable inbound endpoint found IR NEC protocol handler initialized IR RC5(x) protocol handler initialized Registered IR keymap rc-rc6-mce input: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as /devices/pci0000:00/0000:00:13.1/usb3/3-2/3-2:1.0/rc/rc0/input7 rc0: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as /devices/pci0000:00/0000:00:13.1/usb3/3-2/3-2:1.0/rc/rc0 mceusb 3-2:1.0: receive request called (size=0x20) mceusb 3-2:1.0: receive request FAILED! (res=-22) mceusb 3-2:1.0: receive request called (size=0x20) mceusb 3-2:1.0: receive request FAILED! (res=-22) mceusb 3-2:1.0: receive request called (size=0x2) mceusb 3-2:1.0: receive request complete (res=0) mceusb 3-2:1.0: receive request called (size=0x20) mceusb 3-2:1.0: receive request complete (res=0) mceusb 3-2:1.0: receive request called (size=0x2) mceusb 3-2:1.0: receive request complete (res=0) mceusb 3-2:1.0: receive request called (size=0x20) mceusb 3-2:1.0: receive request FAILED! (res=-22) mceusb 3-2:1.0: receive request called (size=0x2) mceusb 3-2:1.0: receive request complete (res=0) mceusb 3-2:1.0: receive request called (size=0x20) mceusb 3-2:1.0: receive request FAILED! (res=-22) mceusb 3-2:1.0: receive request called (size=0x2) mceusb 3-2:1.0: receive request complete (res=0) mceusb 3-2:1.0: receive request called (size=0x20) mceusb 3-2:1.0: receive request FAILED! (res=-22) mceusb 3-2:1.0: Registered Topseed Technology Corp. eHome Infrared Transceiver on usb3:2 usbcore: registered new interface driver mceusb mceusb 3-2:1.0: callback called (status=0 len=2) mceusb 3-2:1.0: callback called (status=0 len=2) mceusb 3-2:1.0: setup answer received 4 bytes mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle mceusb 3-2:1.0: callback called (status=0 len=2) mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle mceusb 3-2:1.0: callback called (status=0 len=2) mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle IR RC6 protocol handler initialized IR JVC protocol handler initialized IR Sony protocol handler initialized lirc_dev: IR Remote Control driver registered, major 61 lirc_dev: lirc_register_driver: sample_rate: 0 IR LIRC bridge handler initialized ... Next, I did: [root] ~/ # /etc/rc.d/lircd stop :: Stopping LIRC Daemon [DONE] [root] ~/ # cat /dev/lirc0 ���Z#0XX��% ��X�XX½ï¿½X�X��X&&&X��<X� X�XGX��X���X�X&X�X�X&X�X>XCX�!X�(#�#X^C That's a single button press on my remote. I also verified that my lirc config is setup to read from /dev/lirc0, and it is. So I started lircd again and re-tried irw. I got the same results -- nothing. ~ James |
From: Simon H. <sim...@co...> - 2011-04-14 01:52:25
|
James, I have also had problems bridging from the in-kernel mceusb driver to userspace for using lircd to decode signals (I'm using a non-media center remote with a media center receiver for which there is yet no keymap, so I need to get lircd to decode it for the time being). It looks like you're about the same place as I am, with lircd not complaining, but not saying anything else either. Try pointing mode2 to your /dev/lirc0 and comparing the pulse/space output with your lircd.conf file to ensure that mceusb is sending something that looks like it should be decoded properly. I haven't had time to get lircd under a debugger to take a look yet, but I will in the next couple of days and let you know if anything turns up. Simon. On 14 April 2011 10:14, James Sumners <jam...@gm...> wrote: > On 2011-04-11 14:40:32 -0400, Jarod Wilson > <ja...@wi...> said: > >> On 4/8/2011 09:48, Jarod Wilson wrote: > >>> # echo lirc> /sys/class/rc/rc0/protocols > > There's another problem I've encountered. A bug in v4l-utils' > > ir-keytable, which in recent releases, is auto-run on boot via > > udev, is screwing up the key mapping table. If you disable the > > rule in 70-ir-properties.rules (iirc), you should get better > > results... > > Okay, here's what I have done. First, I blacklisted the following modules: > > rc_rc6_mce > ir_sony_decoder > ir_jvc_decoder > ir_rc6_decoder > ir_rc5_decoder > ir_nec_decoder > lirc_mceusb > > Then I commented out the following line in my > /etc/udev/rules.d/70-infrared.rules: > > ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a > /etc/rc_maps.cfg -s $name" > > After rebooting: > > [root] ~/ # cat /sys/class/rc/rc0/protocols > [rc-5] [nec] [rc-6] [jvc] [sony] [lirc] > > [root] ~/ # lsmod > Module Size Used by > lirc_dev 11671 1 ir_lirc_codec > ir_sony_decoder 2171 0 > ir_jvc_decoder 2265 0 > ir_rc6_decoder 2777 0 > rc_rc6_mce 1396 0 > ir_rc5_decoder 2265 0 > ir_nec_decoder 2681 0 > mceusb 12191 0 > rc_core 15487 9 > > ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,rc_rc6_mce,ir_rc5_decoder,ir_nec_decoder,mceusb > usbcore > > 139496 6 mceusb,xpad,ohci_hcd,ehci_hcd,usbhid > ... > > I don't know why all of these decoder modules have loaded. I have them > explicitly disabled. > > Anyway, at this point I tried irw and received no output. Which lead me to: > > [root] /etc/udev/rules.d/ # cat /var/run/lirc/lircd > cat: /var/run/lirc/lircd: No such device or address > > So I did: > > [root] ~/ # echo lirc > /sys/class/rc/rc0/protocols > [root] ~/ # cat /sys/class/rc/rc0/protocols > rc-5 nec rc-6 jvc sony [lirc] > > Still no device at /var/run/lirc/lircd. Checking dmesg: > > ... > WARNING: You are using an experimental version of the media stack. > As the driver is backported to an older kernel, it doesn't offer > enough quality for its usage in production. > Use it with care. > Latest git patches (needed if you report a bug to > lin...@vg...): > 0b1b920610a4d41c584e97d38b5ce497c4a303d7 [media] drxd: use > mutex instead of semaphore > a8e8541bc7af59ec07e810bd29aa827878389d82 Remove the now > obsolete drx397xD > 9b2dd144435e397b6ed2a75d522b49868aef98a5 [media] drxd: > CodingStyle cleanups > mceusb 3-2:1.0: mceusb_dev_probe called > mceusb 3-2:1.0: acceptable outbound endpoint found > mceusb 3-2:1.0: acceptable inbound endpoint found > IR NEC protocol handler initialized > IR RC5(x) protocol handler initialized > Registered IR keymap rc-rc6-mce > input: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) > as /devices/pci0000:00/0000:00:13.1/usb3/3-2/3-2:1.0/rc/rc0/input7 > rc0: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as > /devices/pci0000:00/0000:00:13.1/usb3/3-2/3-2:1.0/rc/rc0 > mceusb 3-2:1.0: receive request called (size=0x20) > mceusb 3-2:1.0: receive request FAILED! (res=-22) > mceusb 3-2:1.0: receive request called (size=0x20) > mceusb 3-2:1.0: receive request FAILED! (res=-22) > mceusb 3-2:1.0: receive request called (size=0x2) > mceusb 3-2:1.0: receive request complete (res=0) > mceusb 3-2:1.0: receive request called (size=0x20) > mceusb 3-2:1.0: receive request complete (res=0) > mceusb 3-2:1.0: receive request called (size=0x2) > mceusb 3-2:1.0: receive request complete (res=0) > mceusb 3-2:1.0: receive request called (size=0x20) > mceusb 3-2:1.0: receive request FAILED! (res=-22) > mceusb 3-2:1.0: receive request called (size=0x2) > mceusb 3-2:1.0: receive request complete (res=0) > mceusb 3-2:1.0: receive request called (size=0x20) > mceusb 3-2:1.0: receive request FAILED! (res=-22) > mceusb 3-2:1.0: receive request called (size=0x2) > mceusb 3-2:1.0: receive request complete (res=0) > mceusb 3-2:1.0: receive request called (size=0x20) > mceusb 3-2:1.0: receive request FAILED! (res=-22) > mceusb 3-2:1.0: Registered Topseed Technology Corp. eHome Infrared > Transceiver on usb3:2 > usbcore: registered new interface driver mceusb > mceusb 3-2:1.0: callback called (status=0 len=2) > mceusb 3-2:1.0: callback called (status=0 len=2) > mceusb 3-2:1.0: setup answer received 4 bytes > mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle > mceusb 3-2:1.0: callback called (status=0 len=2) > mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle > mceusb 3-2:1.0: callback called (status=0 len=2) > mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle > mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle > IR RC6 protocol handler initialized > IR JVC protocol handler initialized > IR Sony protocol handler initialized > lirc_dev: IR Remote Control driver registered, major 61 > lirc_dev: lirc_register_driver: sample_rate: 0 > IR LIRC bridge handler initialized > ... > > Next, I did: > > [root] ~/ # /etc/rc.d/lircd stop > :: Stopping LIRC Daemon > [DONE] > [root] ~/ # cat /dev/lirc0 > ���Z#0XX��% > ��X�XX½ï¿½X�X��X&&&X��<X� > X�XGX��X���X�X&X�X�X&X�X>XCX�!X�(#�#X^C > > That's a single button press on my remote. I also verified that my lirc > config is setup to read from /dev/lirc0, and it is. So I started lircd > again and re-tried irw. I got the same results -- nothing. > > ~ James > > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > |
From: James S. <jam...@gm...> - 2011-04-14 02:07:05
|
On 2011-04-13 21:48:25 -0400, Simon Haines <sim...@co...> said: > > > James, > I have also had problems bridging from the in-kernel mceusb driver to > userspace for using lircd to decode signals (I'm using a non-media center > remote with a media center receiver for which there is yet no keymap, so I > need to get lircd to decode it for the time being). It looks like you're > about the same place as I am, with lircd not complaining, but not saying > anything else either. Try pointing mode2 to your /dev/lirc0 and comparing > the pulse/space output with your lircd.conf file to ensure that mceusb is > sending something that looks like it should be decoded properly. > I haven't had time to get lircd under a debugger to take a look yet, but I > will in the next couple of days and let you know if anything turns up. > Simon. I started mode2 and pressed my "stop" button one time. The result of this can be found at [1]. Comparing it with my lircd.conf[2], I don't see anything wrong. But I also don't know how much is being repeated (or not). ~ James [1] -- http://dl.dropbox.com/u/1038672/mceusb/mode2.out [2] -- http://dl.dropbox.com/u/1038672/mceusb/lircd.conf |
From: Simon H. <sim...@co...> - 2011-04-14 03:33:17
|
Hmm. I think you'll get better results by abandoning your .conf file. Your mode2 output indicates your remote delivers a space-encoded fixed-length packet of 32 bits, with a 16-bit header of 0xA10C. The good news is that this is the NEC protocol, and should be decoded by the in-kernel ir-nec-decoder (I'll need to double check what the decoder does with the header though). Hopefully Jarod or someone more familiar with the internals will jump in and correct me here, but I believe this means you should only need to set /sys/class/rc0/protocols to 'nec' and provide a keytable with ir-keytable and (fingers crossed) you'll get events routed to the input layer. The keytable file should look something like this: # table=tivo type=NEC 0x120D=KEY_STOP 0x640B=KEY_PREVIOUS I've only decoded the first two entries from your .conf file, if you need any help with how to decode the rest, let me know. It is worthwhile decoding the raw_codes from your .conf file to scancodes, because it looks like this is what the kernel's IR subsystem will use (again Jarod or someone can correct me here). This is approximately where I'm up to as well--I've just today created a keytable file for my remote (I only found out about ir-keytable from looking back on this thread), and will try it out later on. I'll let you know how that goes. Good luck! Simon. On 14 April 2011 12:06, James Sumners <jam...@gm...> wrote: > On 2011-04-13 21:48:25 -0400, Simon Haines > <sim...@co...> said: > > > > > > > James, > > I have also had problems bridging from the in-kernel mceusb driver to > > userspace for using lircd to decode signals (I'm using a non-media center > > remote with a media center receiver for which there is yet no keymap, so > I > > need to get lircd to decode it for the time being). It looks like you're > > about the same place as I am, with lircd not complaining, but not saying > > anything else either. Try pointing mode2 to your /dev/lirc0 and comparing > > the pulse/space output with your lircd.conf file to ensure that mceusb is > > sending something that looks like it should be decoded properly. > > I haven't had time to get lircd under a debugger to take a look yet, but > I > > will in the next couple of days and let you know if anything turns up. > > Simon. > > > I started mode2 and pressed my "stop" button one time. The result of > this can be found at [1]. Comparing it with my lircd.conf[2], I don't > see anything wrong. But I also don't know how much is being repeated > (or not). > > ~ James > > [1] -- http://dl.dropbox.com/u/1038672/mceusb/mode2.out > [2] -- http://dl.dropbox.com/u/1038672/mceusb/lircd.conf > > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > |
From: James S. <jam...@gm...> - 2011-04-14 18:14:37
|
On 4/13/2011 23:32, Simon Haines wrote: > I've only decoded the first two entries from your .conf file, if you > need any help with how to decode the rest, let me know Yes, if you could point me to the documentation (or other), that would be helpful. ~ James |
From: Simon H. <sim...@co...> - 2011-04-15 01:42:04
|
On 15 April 2011 04:14, James Sumners <jam...@gm...> wrote: > > Yes, if you could point me to the documentation (or other), that would > be helpful. > >From Jarod's mail later in this thread, it seems the TiVo keymap will at some future stage make it into the kernel mainline. When this happens, your remote will just work. Until then you could try the lircd.conf Jarod mentions is sitting on his laptop, or try the path I am on, which is to route decoded signals via the keymap to the input layer, and use lircd to route the input layer events to applications that use the lirc subsystem (eg mythtv). Up to you. The reason I'm using this approach is that the userspace lirc_mceusb driver is 'dead and gone' and so I can't decode pulse/space signals from /dev/lirc0 (there is no valid driver option to pass to lircd anymore). Instead the kernel mceusb driver now handles this. It loads its own keymap for the remotes that usually are bundled with the receiver, which I need to override because I'm using a different remote altogether. Note that I'm using a recent kernel (a spanking new 2.6.38) and lirc 0.9.0. As I understand it, it's a bit of a mess at the moment with everything in flux due to major changes in kernel's IR subsystem. I expect within this year things will have settled down and the major distributions will have embraced the new order, and remote control handling will be significantly better than it ever has been before. Let me caveat all of this by saying that I've only recently started looking into the IR subsystem and don't know much about it at all. A lot of what I'm saying could very well be nonsense, and indeed I could be giving you bad information. If so, I hope someone more familiar with the project will jump in and correct me as soon as possible. If you want to try the approach I'm testing (routing via the event layer), and don't want to recompile your kernel with Jarod's patch that provides a kernel keymap for the tivo remote, you can create your own keymap from Jarod's patch. Look at the 'struct rc_map_table tivo' and for each entry take the hex number (first part), strip off the first four hex digits 'a10c' and combine it with the second part in the form: 0x900f=KEY_MEDIA etc. Put each new entry on its own line in a file and call it 'tivo.table' (or whatever). Now load the table with the command: sudo ir-keytable -v -s rc0 -p nec -c -w tivo.table This should give you a bunch of debug output to the effect that the protocol is now 'nec', and your keytable has been decoded and loaded, after clearing whatever keytable was already there (most likely the "rc-rc6-mce"). Now you can test whether this all hangs together by looking at the events generated using 'evtest'. Point this to the event device mounted by dev_lirc on your system (in my case it was /dev/input/event5) and press a few buttons on your remote. All going well, you'll get output like this: Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x471 product 0x815 version 0x0 Input device name: "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 2 (1) Event code 3 (2) ...etc... Event type 20 (Repeat) Testing ... (interrupt to exit) Event: time 1302779158.714791, type 4 (Misc), code 4 (ScanCode), value 409 Event: time 1302779163.454581, type 4 (Misc), code 4 (ScanCode), value 40a If you get something like this, it means the kernel-side of your setup works OK. It's now a matter of routing the scancodes to applications listening on the lirc interface. This should be a matter of starting lircd using the devinput driver, the /dev/input/eventX device, and the lircd.conf.devinput file, but I haven't had the time to test this myself yet. I think that's how it's supposed to work anyway. If anyone on the list knows a better way of doing this, or thinks that I'm giving bum advice, please jump in and set matters straight. In the meantime James I'll let you know how I get on. Good luck! Simon. On 15 April 2011 04:14, James Sumners <jam...@gm...> wrote: > On 4/13/2011 23:32, Simon Haines wrote: > > I've only decoded the first two entries from your .conf file, if you > > need any help with how to decode the rest, let me know > > Yes, if you could point me to the documentation (or other), that would > be helpful. > > ~ James > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > |
From: Simon H. <sim...@co...> - 2011-04-15 02:43:37
|
Sorry James, I just had another quick look at the nec decoder in the latest stable kernel and it will not correctly decode your tivo remote, failing on the command checksum. Support for it is in the current mainline (2.6.39-rc3), but this means you won't be able to use my approach (yet). Sorry for wasting your time, please ignore my earlier email. Maybe you'll have better luck with one of the .conf files Jarod pointed to in another email. Simon. On 15 April 2011 11:41, Simon Haines <sim...@co...>wrote: > On 15 April 2011 04:14, James Sumners <jam...@gm...> wrote: > > >> Yes, if you could point me to the documentation (or other), that would >> be helpful. >> > > From Jarod's mail later in this thread, it seems the TiVo keymap will at > some future stage make it into the kernel mainline. When this happens, your > remote will just work. Until then you could try the lircd.conf Jarod > mentions is sitting on his laptop, or try the path I am on, which is to > route decoded signals via the keymap to the input layer, and use lircd to > route the input layer events to applications that use the lirc subsystem (eg > mythtv). > > Up to you. The reason I'm using this approach is that the userspace > lirc_mceusb driver is 'dead and gone' and so I can't decode pulse/space > signals from /dev/lirc0 (there is no valid driver option to pass to lircd > anymore). Instead the kernel mceusb driver now handles this. It loads its > own keymap for the remotes that usually are bundled with the receiver, which > I need to override because I'm using a different remote altogether. > > Note that I'm using a recent kernel (a spanking new 2.6.38) and lirc 0.9.0. > As I understand it, it's a bit of a mess at the moment with everything in > flux due to major changes in kernel's IR subsystem. I expect within this > year things will have settled down and the major distributions will have > embraced the new order, and remote control handling will be significantly > better than it ever has been before. Let me caveat all of this by saying > that I've only recently started looking into the IR subsystem and don't know > much about it at all. A lot of what I'm saying could very well be nonsense, > and indeed I could be giving you bad information. If so, I hope someone more > familiar with the project will jump in and correct me as soon as possible. > > If you want to try the approach I'm testing (routing via the event layer), > and don't want to recompile your kernel with Jarod's patch that provides a > kernel keymap for the tivo remote, you can create your own keymap from > Jarod's patch. Look at the 'struct rc_map_table tivo' and for each entry > take the hex number (first part), strip off the first four hex digits 'a10c' > and combine it with the second part in the form: 0x900f=KEY_MEDIA etc. Put > each new entry on its own line in a file and call it 'tivo.table' (or > whatever). > > Now load the table with the command: sudo ir-keytable -v -s rc0 -p nec -c > -w tivo.table > This should give you a bunch of debug output to the effect that the > protocol is now 'nec', and your keytable has been decoded and loaded, after > clearing whatever keytable was already there (most likely the "rc-rc6-mce"). > > Now you can test whether this all hangs together by looking at the events > generated using 'evtest'. Point this to the event device mounted by dev_lirc > on your system (in my case it was /dev/input/event5) and press a few buttons > on your remote. All going well, you'll get output like this: > Input driver version is 1.0.1 > Input device ID: bus 0x3 vendor 0x471 product 0x815 version 0x0 > Input device name: "Media Center Ed. eHome Infrared Remote Transceiver > (0471:0815)" > Supported events: > Event type 0 (Sync) > Event type 1 (Key) > Event code 2 (1) > Event code 3 (2) > ...etc... > Event type 20 (Repeat) > Testing ... (interrupt to exit) > Event: time 1302779158.714791, type 4 (Misc), code 4 (ScanCode), value 409 > Event: time 1302779163.454581, type 4 (Misc), code 4 (ScanCode), value 40a > > If you get something like this, it means the kernel-side of your setup > works OK. It's now a matter of routing the scancodes to applications > listening on the lirc interface. This should be a matter of starting lircd > using the devinput driver, the /dev/input/eventX device, and the > lircd.conf.devinput file, but I haven't had the time to test this myself > yet. I think that's how it's supposed to work anyway. > > If anyone on the list knows a better way of doing this, or thinks that I'm > giving bum advice, please jump in and set matters straight. In the meantime > James I'll let you know how I get on. Good luck! > Simon. > > > On 15 April 2011 04:14, James Sumners <jam...@gm...> wrote: > >> On 4/13/2011 23:32, Simon Haines wrote: >> > I've only decoded the first two entries from your .conf file, if you >> > need any help with how to decode the rest, let me know >> >> Yes, if you could point me to the documentation (or other), that would >> be helpful. >> >> ~ James >> >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about >> boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> > > |
From: James S. <jam...@gm...> - 2011-04-15 12:46:48
|
On 4/14/2011 22:43, Simon Haines wrote: > Sorry James, I just had another quick look at the nec decoder in the > latest stable kernel and it will not correctly decode your tivo remote, > failing on the command checksum. Support for it is in the current > mainline (2.6.39-rc3), but this means you won't be able to use my > approach (yet). Sorry for wasting your time, please ignore my earlier > email. Maybe you'll have better luck with one of the .conf files Jarod > pointed to in another email. > Simon. > Thank you anyway. ~ James |
From: Jarod W. <ja...@wi...> - 2011-04-15 14:41:56
|
On Apr 15, 2011, at 8:46 AM, James Sumners wrote: > On 4/14/2011 22:43, Simon Haines wrote: >> Sorry James, I just had another quick look at the nec decoder in the >> latest stable kernel and it will not correctly decode your tivo remote, >> failing on the command checksum. Support for it is in the current >> mainline (2.6.39-rc3), but this means you won't be able to use my >> approach (yet). Sorry for wasting your time, please ignore my earlier >> email. Maybe you'll have better luck with one of the .conf files Jarod >> pointed to in another email. >> Simon. >> > > Thank you anyway. Since, iirc, the driver you're running are built using the v4l/dvb media_build infra, I believe you've actually got the necessary nec decoder support included. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-04-15 14:40:56
|
On Apr 14, 2011, at 9:41 PM, Simon Haines wrote: > On 15 April 2011 04:14, James Sumners <jam...@gm...> wrote: > > Yes, if you could point me to the documentation (or other), that would > be helpful. > > From Jarod's mail later in this thread, it seems the TiVo keymap will at some future stage make it into the kernel mainline. When this happens, your remote will just work. Until then you could try the lircd.conf Jarod mentions is sitting on his laptop, or try the path I am on, which is to route decoded signals via the keymap to the input layer, and use lircd to route the input layer events to applications that use the lirc subsystem (eg mythtv). > > Up to you. The reason I'm using this approach is that the userspace lirc_mceusb driver is 'dead and gone' and so I can't decode pulse/space signals from /dev/lirc0 (there is no valid driver option to pass to lircd anymore). This isn't actually correct. The new mceusb driver's default mode does in-kernel decoding, but there's an lirc bridge driver plugin that *will* pass signals out to userspace via /dev/lirc0. If you look at /sys/class/rc/rc*/protocols, for any raw IR hardware supported by rc-core, you should see evidence of both protocol-specific in-kernel decoders (rc5, rc6, nec, jvc, sony) and an lirc "decoder", which rather than decoding data and mapping the resulting scancodes to linux input layer keycodes, passes the pulse/space data out to userspace via /dev/lirc0, which lircd should be able to decode just as it always has with lirc_mceusb. (The same holds true for streamzap vs. lirc_streamzap, and the new ene_ir, nuvoton-cir and ite-cir drivers also work this way). -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-04-14 19:33:00
|
On Apr 13, 2011, at 11:32 PM, Simon Haines wrote: > Hmm. I think you'll get better results by abandoning your .conf file. Your mode2 output indicates your remote delivers a space-encoded fixed-length packet of 32 bits, with a 16-bit header of 0xA10C. The good news is that this is the NEC protocol, Sort of. Its NEC transport, but decode is slightly different than what's considered true NEC. (The two high bytes are a vendor code, rather than a command/!command checksum pair -- Apple's remotes do essentially the same thing). > and should be decoded by the in-kernel ir-nec-decoder (I'll need to double check what the decoder does with the header though). Its supported by the latest ir-nec-decoder, which will just pass along the full 32 bits for keycode lookup. > Hopefully Jarod or someone more familiar with the internals will jump in and correct me here, but I believe this means you should only need to set /sys/class/rc0/protocols to 'nec' and provide a keytable with ir-keytable and (fingers crossed) you'll get events routed to the input layer. The keytable file should look something like this: > > # table=tivo type=NEC > 0x120D=KEY_STOP > 0x640B=KEY_PREVIOUS More like this: https://patchwork.kernel.org/patch/660101/ :) Looks like either that, or the lircd.conf I've got sitting on my laptop at home would work perfectly in this case, based on those two keys you have done the manual translation on. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-04-14 19:27:57
|
On Apr 13, 2011, at 10:06 PM, James Sumners wrote: > On 2011-04-13 21:48:25 -0400, Simon Haines > <sim...@co...> said: > >> >> >> James, >> I have also had problems bridging from the in-kernel mceusb driver to >> userspace for using lircd to decode signals (I'm using a non-media center >> remote with a media center receiver for which there is yet no keymap, so I >> need to get lircd to decode it for the time being). It looks like you're >> about the same place as I am, with lircd not complaining, but not saying >> anything else either. Try pointing mode2 to your /dev/lirc0 and comparing >> the pulse/space output with your lircd.conf file to ensure that mceusb is >> sending something that looks like it should be decoded properly. >> I haven't had time to get lircd under a debugger to take a look yet, but I >> will in the next couple of days and let you know if anything turns up. >> Simon. > > > I started mode2 and pressed my "stop" button one time. The result of > this can be found at [1]. Comparing it with my lircd.conf[2], I don't > see anything wrong. But I also don't know how much is being repeated > (or not). > > ~ James > > [1] -- http://dl.dropbox.com/u/1038672/mceusb/mode2.out > [2] -- http://dl.dropbox.com/u/1038672/mceusb/lircd.conf Where did that lircd.conf come from? You might have better luck with one of these here: http://lirc.sourceforge.net/remotes/tivo/ (And I've got yet another tivo remote config variant file here that I have yet to get uploaded I can send your way if none of those work). -- Jarod Wilson ja...@wi... |
From: James S. <jam...@gm...> - 2011-04-14 19:34:36
|
On 4/14/2011 15:27, Jarod Wilson wrote: > Where did that lircd.conf come from? It's one I generated with irrecord when I first built my DVR. Or rather, when I first acquired my Harmony 550 remote. ~ James |
From: Jarod W. <ja...@wi...> - 2011-04-14 19:26:48
|
On Apr 13, 2011, at 8:14 PM, James Sumners wrote: > On 2011-04-11 14:40:32 -0400, Jarod Wilson > <ja...@wi...> said: >>> On 4/8/2011 09:48, Jarod Wilson wrote: >>>> # echo lirc> /sys/class/rc/rc0/protocols >> There's another problem I've encountered. A bug in v4l-utils' >> ir-keytable, which in recent releases, is auto-run on boot via >> udev, is screwing up the key mapping table. If you disable the >> rule in 70-ir-properties.rules (iirc), you should get better >> results... > > Okay, here's what I have done. First, I blacklisted the following modules: > > rc_rc6_mce > ir_sony_decoder > ir_jvc_decoder > ir_rc6_decoder > ir_rc5_decoder > ir_nec_decoder > lirc_mceusb Only the blacklisting of lirc_mceusb makes any sense here. :) > Then I commented out the following line in my > /etc/udev/rules.d/70-infrared.rules: > > ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a > /etc/rc_maps.cfg -s $name" > > After rebooting: > > [root] ~/ # cat /sys/class/rc/rc0/protocols > [rc-5] [nec] [rc-6] [jvc] [sony] [lirc] Okay, good. > [root] ~/ # lsmod > Module Size Used by > lirc_dev 11671 1 ir_lirc_codec > ir_sony_decoder 2171 0 > ir_jvc_decoder 2265 0 > ir_rc6_decoder 2777 0 > rc_rc6_mce 1396 0 > ir_rc5_decoder 2265 0 > ir_nec_decoder 2681 0 > mceusb 12191 0 > rc_core 15487 9 > ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,rc_rc6_mce,ir_rc5_decoder,ir_nec_decoder,mceusb > usbcore > > 139496 6 mceusb,xpad,ohci_hcd,ehci_hcd,usbhid > ... > > I don't know why all of these decoder modules have loaded. I have them > explicitly disabled. No, you've told modprobe not to load them. Modprobe didn't. The kernel did, because rc-core requested them. But it doesn't matter one way or another if they're loaded or not. Don't worry about them. > Anyway, at this point I tried irw and received no output. Which lead me to: > > [root] /etc/udev/rules.d/ # cat /var/run/lirc/lircd > cat: /var/run/lirc/lircd: No such device or address > > So I did: > > [root] ~/ # echo lirc > /sys/class/rc/rc0/protocols > [root] ~/ # cat /sys/class/rc/rc0/protocols > rc-5 nec rc-6 jvc sony [lirc] > > Still no device at /var/run/lirc/lircd. /var/run/lirc/lircd is created by starting lircd. > Checking dmesg: Looks mostly sane. I've seen the failure bits w/various generations of mceusb hardware during bring-up, but they're non-fatal. > Next, I did: > > [root] ~/ # /etc/rc.d/lircd stop > :: Stopping LIRC Daemon > [DONE] > [root] ~/ # cat /dev/lirc0 > ���Z#0XX��% > ��X�XX½ï¿½X�X��X&&&X��<X� > X�XGX��X���X�X&X�X�X&X�X>XCX�!X�(#�#X^C mode2 /dev/lirc0 gives more useful output. > That's a single button press on my remote. I also verified that my lirc > config is setup to read from /dev/lirc0, and it is. So I started lircd > again and re-tried irw. I got the same results -- nothing. I think your lircd.conf is no good. -- Jarod Wilson ja...@wi... |