From: Jarod W. <ja...@wi...> - 2010-10-09 05:09:42
|
Hey folks, Today, I finally got around to finishing cleanup and testing of a local git branch I've had for a while that represents the road to lirc 0.9.0, which has a heavy focus on compat with the lirc bits that were merged upstream. Just a bit ago, I finally pushed all those bits in git, after going through a battery of tests (well, some basic sanity testing with a few devices and a full run of a protocol encoder/decoder regression test against lirc 0.8.7). Thus far, I've only tested a small handful of ir-core-based drivers, and only on a 64-bit host, so any and all testing is welcomed. Going to try to do a bit more testing myself, but I think I'll cut an lirc-0.9.0-pre1 tarball later this weekend after merging one more userspace piece (out of time for tonight)... So those who aren't particularly git-comfortable, you'll have to wait a few more days, but those who are game for git, clone like so: $ git clone git://lirc.git.sourceforge.net/gitroot/lirc/lirc (Per http://sourceforge.net/projects/lirc/develop ) CVS is currently *not* being updated anymore. -- Jarod Wilson ja...@wi... |
From: Mariusz B. <ma...@sk...> - 2010-10-12 19:20:23
|
Hello Jarod, I am trying to run the lirc on kernel 2.6.36 (currently using rc7) using devinput driver - unfortunately no luck so far :( I cloned the sources from git and it build successfully. I am using debian testing (64bit). So far - on kernel 2.6.34 and debian's lirc 0.8.3 it works correctly. But on 2.6.36 with lirc from git i collected the following info: Before all - i did for sure: cat < /dev/input/event3 and i have data while pressing remote buttons. Next, i am running lirc like this: lircd -n --driver=devinput --device=/dev/input/event3 /etc/lirc/lircd.conf and i've got: lircd: lircd(devinput) ready, using /var/run/lirc/lircd lircd: accepted new client on /var/run/lirc/lircd lircd: initializing '/dev/input/event3' so far - everything is good but - then i am trying to see the codes - so i am running irw, and i am pressing the buttons - but when i press the first button i've got this information from lircd daemon: lircd: WARNING: you are using an obsolete devinput config file: Success lircd: WARNING: get the new version at http://lirc.sourceforge.net/remotes/ devinput/lircd.conf.devinput: Success ... and on irw - null output :( of course - i was also trying change my previously working lircd.conf with the pointed sourceforge config - but i've got same results, than i also make my own lircd.conf using devinput.sh - also same results :( I even try to run inputlirc, then irw to see the results - also irw doesn't show codes while i was pressing remote. Thoughts? Need I to wait for final 0.9.0 with eventlircd which is being merged now? |
From: Mariusz B. <ma...@sk...> - 2010-10-13 17:45:33
|
Hello again I found the difference. On 2.6.36 the key presses are "translated" as EV_MSC events - i believe this causes the reading problem with lircd/inputlircd. on kernel 2.6.34 i've got: $ input-events 3 /dev/input/event3 bustype : BUS_PCI vendor : 0xb034 product : 0x3034 version : 1 name : "cx88 IR (Prof 7301 DVB-S/S2)" phys : "pci-0000:04:06.2/ir0" bits ev : EV_SYN EV_KEY EV_REP waiting for events 18:05:41.769387: EV_KEY KEY_1 pressed 18:05:41.769396: EV_SYN code=0 value=0 18:05:41.957328: EV_KEY KEY_1 released 18:05:41.957336: EV_SYN code=0 value=0 18:05:43.322475: EV_KEY KEY_2 pressed 18:05:43.322479: EV_SYN code=0 value=0 18:05:43.510425: EV_KEY KEY_2 released 18:05:43.510429: EV_SYN code=0 value=0 18:05:44.044628: EV_KEY KEY_3 pressed 18:05:44.044636: EV_SYN code=0 value=0 18:05:44.222674: EV_KEY KEY_3 released 18:05:44.222682: EV_SYN code=0 value=0 18:05:44.796448: EV_KEY KEY_5 pressed ... and so on but on 2.6.36 i've got: $ input-events 3 /dev/input/event3 bustype : BUS_PCI vendor : 0xb034 product : 0x3034 version : 1 name : "cx88 IR (Prof 7301 DVB-S/S2)" phys : "pci-0000:04:06.2/ir0" bits ev : EV_SYN EV_KEY EV_MSC EV_REP waiting for events 18:09:04.354391: EV_MSC code=4 value=153 18:09:04.403854: EV_MSC code=4 value=153 18:09:04.512692: EV_MSC code=4 value=153 18:09:04.621515: EV_MSC code=4 value=153 18:09:04.730346: EV_MSC code=4 value=153 18:09:05.383340: EV_MSC code=4 value=153 18:09:05.432795: EV_MSC code=4 value=153 18:09:05.541627: EV_MSC code=4 value=153 18:09:05.650459: EV_MSC code=4 value=153 will lircd and devinput driver support these events? |
From: Jarod W. <ja...@wi...> - 2010-10-14 19:45:38
|
On Oct 13, 2010, at 1:45 PM, Mariusz Bialonczyk wrote: > Hello again > I found the difference. On 2.6.36 the key presses are "translated" as EV_MSC > events - i believe this causes the reading problem with lircd/inputlircd. Ah, crud. I don't know that I've tested the devinput driver since the EV_MSC addition went in. > on kernel 2.6.34 i've got: > $ input-events 3 > /dev/input/event3 > bustype : BUS_PCI > vendor : 0xb034 > product : 0x3034 > version : 1 > name : "cx88 IR (Prof 7301 DVB-S/S2)" > phys : "pci-0000:04:06.2/ir0" > bits ev : EV_SYN EV_KEY EV_REP > > waiting for events > 18:05:41.769387: EV_KEY KEY_1 pressed > 18:05:41.769396: EV_SYN code=0 value=0 ... > ... and so on > > but on 2.6.36 i've got: > $ input-events 3 > /dev/input/event3 > bustype : BUS_PCI > vendor : 0xb034 > product : 0x3034 > version : 1 > name : "cx88 IR (Prof 7301 DVB-S/S2)" > phys : "pci-0000:04:06.2/ir0" > bits ev : EV_SYN EV_KEY EV_MSC EV_REP > > waiting for events > 18:09:04.354391: EV_MSC code=4 value=153 ... > will lircd and devinput driver support these events? We'll have to do something here, yes. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-10-25 15:36:41
|
On Oct 14, 2010, at 3:45 PM, Jarod Wilson wrote: > On Oct 13, 2010, at 1:45 PM, Mariusz Bialonczyk wrote: > >> Hello again >> I found the difference. On 2.6.36 the key presses are "translated" as EV_MSC >> events - i believe this causes the reading problem with lircd/inputlircd. > > Ah, crud. I don't know that I've tested the devinput driver since the EV_MSC addition went in. So I finally got around to looking at this just now. I'm not sure what the problem is/was on your end, but everything works perfectly fine here, even with the EV_MSC events reported. (I'm using lircd built from the git tree w/a Fedora kernel that has all the pending 2.6.37-rc1 IR bits merged in it). -- Jarod Wilson ja...@wi... |
From: Laurence D. <ld...@tu...> - 2010-10-16 03:25:14
|
Hi, configure failed for me with: checking for python... no checking for python2... no checking for python3... no checking for python3.0... no checking for python2.5... no checking for python2.4... no checking for python2.3... no checking for python2.2... no checking for python2.1... no checking for python2.0... no configure: error: no suitable Python interpreter found Since when did python become a lirc dependency? ... Here's a patch to make it conditional: diff --git a/configure.ac b/configure.ac index ff860f3..7a09b7c 100644 --- a/configure.ac +++ b/configure.ac @@ -23,7 +23,7 @@ AC_PATH_PROG(depmod, depmod, /sbin/depmod, $PATH:/sbin) AC_PATH_PROG(LIBUSB_CONFIG, libusb-config) AC_PROG_LN_S AC_PROG_LIBTOOL -AM_PATH_PYTHON +AM_PATH_PYTHON(,, [:]) AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != ""]) dnl Checks for header files. Thanks, Laurence Jarod Wilson wrote: > Hey folks, > > Today, I finally got around to finishing cleanup and testing of a > local git branch I've had for a while that represents the road to lirc > 0.9.0, which has a heavy focus on compat with the lirc bits that were > merged upstream. Just a bit ago, I finally pushed all those bits in > git, after going through a battery of tests (well, some basic sanity > testing with a few devices and a full run of a protocol > encoder/decoder regression test against lirc 0.8.7). Thus far, I've > only tested a small handful of ir-core-based drivers, and only on a > 64-bit host, so any and all testing is welcomed. Going to try to do a > bit more testing myself, but I think I'll cut an lirc-0.9.0-pre1 > tarball later this weekend after merging one more userspace piece (out > of time for tonight)... So those who aren't particularly > git-comfortable, you'll have to wait a few more days, but those who > are game for git, clone like so: > > $ git clone git://lirc.git.sourceforge.net/gitroot/lirc/lirc > > (Per http://sourceforge.net/projects/lirc/develop ) > > CVS is currently *not* being updated anymore. > > -- > Jarod Wilson > ja...@wi... > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb |
From: Jarod W. <ja...@wi...> - 2010-10-20 17:57:56
|
On Oct 15, 2010, at 11:08 PM, Laurence Darby wrote: > Hi, > > configure failed for me with: > > checking for python... no > checking for python2... no > checking for python3... no > checking for python3.0... no > checking for python2.5... no > checking for python2.4... no > checking for python2.3... no > checking for python2.2... no > checking for python2.1... no > checking for python2.0... no > configure: error: no suitable Python interpreter found > > Since when did python become a lirc dependency? ... Here's a patch to > make it conditional: > > > diff --git a/configure.ac b/configure.ac > index ff860f3..7a09b7c 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -23,7 +23,7 @@ AC_PATH_PROG(depmod, depmod, /sbin/depmod, $PATH:/sbin) > AC_PATH_PROG(LIBUSB_CONFIG, libusb-config) > AC_PROG_LN_S > AC_PROG_LIBTOOL > -AM_PATH_PYTHON > +AM_PATH_PYTHON(,, [:]) > AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != ""]) > > dnl Checks for header files. Committed and pushed, thanks much! -- Jarod Wilson ja...@wi... |
From: HC S. <hc...@co...> - 2010-10-20 15:17:06
|
On 09-10-2010 07:09, Jarod Wilson wrote: > Hey folks, > > Today, I finally got around to finishing cleanup and testing of a > local git branch I've had for a while that represents the road to lirc > 0.9.0, which has a heavy focus on compat with the lirc bits that were > merged upstream. Just a bit ago, I finally pushed all those bits in > git, after going through a battery of tests (well, some basic sanity > testing with a few devices and a full run of a protocol > encoder/decoder regression test against lirc 0.8.7). Thus far, I've > only tested a small handful of ir-core-based drivers, and only on a > 64-bit host, so any and all testing is welcomed. Going to try to do a > bit more testing myself, but I think I'll cut an lirc-0.9.0-pre1 > tarball later this weekend after merging one more userspace piece (out > of time for tonight)... So those who aren't particularly > git-comfortable, you'll have to wait a few more days, but those who > are game for git, clone like so: Hi Jarod! I'm testing like a crazed.. well.. tester, and I managed to compile and install your 2.6.35 kernel on my box. I'm getting some sort of output from /dev/lirc0 after inserting the nuvoton_cir module, so I'm optimistic. Realizing that it doesn't speak well with the lirc 0.8.6 that comes with my Fedora 13 installation (*), I decided to try this prerelease of 0.9.0. It seems like setup-driver.sh and configure is missing. I tried running automake, but without much luck. I'd be happy to test, but I'm a bit stuck here. Running updated Fedora 13 with your 2.6.35 kernel on an AsRock 330HT fitted with a Nuvoton chip. Cheers, HC *) I tried running something like "irrecord --device=/dev/input/event4 --driver=devinput foo", but had trouble with data not being sent through before I stopped pressing buttons. Testing with an Apple remote just generated one single dot, and nothing more. Generated configuration files for the original remote contained "bits 0", which probably isn't a good sign. *Something* got through though, so I'm very optimistic :-) -- Hans Christian Saustrup Partner, CodeCompany.dk, Skolebakken 7, 8000 Århus C Mobil +45-30261024 |
From: Jarod W. <ja...@wi...> - 2010-10-20 17:15:43
|
On Oct 20, 2010, at 11:16 AM, HC Saustrup wrote: > On 09-10-2010 07:09, Jarod Wilson wrote: >> Hey folks, >> >> Today, I finally got around to finishing cleanup and testing of a >> local git branch I've had for a while that represents the road to lirc >> 0.9.0, which has a heavy focus on compat with the lirc bits that were >> merged upstream. Just a bit ago, I finally pushed all those bits in >> git, after going through a battery of tests (well, some basic sanity >> testing with a few devices and a full run of a protocol >> encoder/decoder regression test against lirc 0.8.7). Thus far, I've >> only tested a small handful of ir-core-based drivers, and only on a >> 64-bit host, so any and all testing is welcomed. Going to try to do a >> bit more testing myself, but I think I'll cut an lirc-0.9.0-pre1 >> tarball later this weekend after merging one more userspace piece (out >> of time for tonight)... So those who aren't particularly >> git-comfortable, you'll have to wait a few more days, but those who >> are game for git, clone like so: > > Hi Jarod! > > I'm testing like a crazed.. well.. tester, and I managed to compile and install your 2.6.35 kernel on my box. I'm getting some sort of output from /dev/lirc0 after inserting the nuvoton_cir module, so I'm optimistic. Realizing that it doesn't speak well with the lirc 0.8.6 that comes with my Fedora 13 installation (*), I decided to try this prerelease of 0.9.0. Nb: I'm still updating the git tree some even as I type, fixing up some things that I broke last night when merging in changes from the upstreamed lirc_dev... :) > It seems like setup-driver.sh and configure is missing. I tried running automake, but without much luck. I'd be happy to test, but I'm a bit stuck here. For an scm checkout, see http://lirc.org/cvs.html for details. I need to put together some web site updates to switch cvs refs to git, but the git version is like so: Get sources: git clone git://lirc.git.sourceforge.net/gitroot/lirc/lirc Subsequent updates: git pull Compile: cd lirc ./autogen.sh ./setup.sh make (Though I typically actually do ./autogen.sh, then ./configure --with-driver=foo, then make, where 'foo' is either 'all', or 'userspace', depending on whether I want to test lirc kernel modules built from the tree, or just the ones in-kernel). > Running updated Fedora 13 with your 2.6.35 kernel on an AsRock 330HT fitted with a Nuvoton chip. For Fedora, I have an easier solution... :) Even for F13, you should be able to just grab and install these, and have things work: http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.6/46.fc14/ http://kojipkgs.fedoraproject.org/packages/lirc/0.8.7/1.fc14/ (lirc isn't strictly needed either if you're using the mce remote, that'll be automatically decoded to input layer events) -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-10-20 19:13:18
|
On Oct 20, 2010, at 1:15 PM, Jarod Wilson wrote: > On Oct 20, 2010, at 11:16 AM, HC Saustrup wrote: > >> On 09-10-2010 07:09, Jarod Wilson wrote: >>> Hey folks, >>> >>> Today, I finally got around to finishing cleanup and testing of a >>> local git branch I've had for a while that represents the road to lirc >>> 0.9.0, which has a heavy focus on compat with the lirc bits that were >>> merged upstream. Just a bit ago, I finally pushed all those bits in >>> git, after going through a battery of tests (well, some basic sanity >>> testing with a few devices and a full run of a protocol >>> encoder/decoder regression test against lirc 0.8.7). Thus far, I've >>> only tested a small handful of ir-core-based drivers, and only on a >>> 64-bit host, so any and all testing is welcomed. Going to try to do a >>> bit more testing myself, but I think I'll cut an lirc-0.9.0-pre1 >>> tarball later this weekend after merging one more userspace piece (out >>> of time for tonight)... So those who aren't particularly >>> git-comfortable, you'll have to wait a few more days, but those who >>> are game for git, clone like so: >> >> Hi Jarod! >> >> I'm testing like a crazed.. well.. tester, and I managed to compile and install your 2.6.35 kernel on my box. I'm getting some sort of output from /dev/lirc0 after inserting the nuvoton_cir module, so I'm optimistic. Realizing that it doesn't speak well with the lirc 0.8.6 that comes with my Fedora 13 installation (*), I decided to try this prerelease of 0.9.0. > > Nb: I'm still updating the git tree some even as I type, fixing up some things that I broke last night when merging in changes from the upstreamed lirc_dev... :) All sorted out now, hopefully. Have successfully tested lirc_igorplugusb, lirc_mceusb and lirc_streamzap from the lirc git tree (with matching lircd, of course) on a 2.6.32 (RHEL6) kernel. -- Jarod Wilson ja...@wi... |
From: HC S. <hc...@co...> - 2010-10-21 07:53:11
|
Hi! On 20-10-2010 19:15, Jarod Wilson wrote: > > For Fedora, I have an easier solution... :) Even for F13, you should be able to just grab and install these, and have things work: > > http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.6/46.fc14/ > http://kojipkgs.fedoraproject.org/packages/lirc/0.8.7/1.fc14/ > > (lirc isn't strictly needed either if you're using the mce remote, that'll be automatically decoded to input layer events) I went for the easy solution :) With everything installed, I was able to run irrecord without any device/driver specified (just a fresh filename). I've tried running it with two different remotes - the one that ships with the AsRock 330HT and an Apple aluminium remote. A weird thing happened - on the original remote, some buttons generate "real time" dots, while other buttons generate 5-10 dots *after* releasing the button. AFAIR, "volume up" made dots in real time, and "volume down" didn't display anything before I released the button. This behaviour was consistent - specific buttons behaved the same through the process of running irrecord. I see the same behaviour when I cat /dev/lirc0 - lots of repeating output when pressing some buttons, and buffered-until-release when pressing others. Output from the two irrecord sessions below. With the original AsRock remote: --8<-- Press RETURN now to start recording. ................................................................................ Found const length: 106620 Please keep on pressing buttons like described above. ................................................................................ RC-6 remote control found. No header found. No repeat code found. Signals are biphase encoded. Signal length is 41 Checking for toggle bit mask. Please press an arbitrary button repeatedly as fast as possible. Make sure you keep pressing the SAME button and that you DON'T HOLD the button down!. If you can't see any dots appear, then wait a bit between button presses. Press RETURN to continue. No toggle bit mask found. But I know for sure that RC6 has a toggle bit! --8<-- With the new Apple aluminium remote: --8<-- Press RETURN now to start recording. ................................................................................ Found const length: 108016 Please keep on pressing buttons like described above. ................................................................................ Space/pulse encoded remote control found. Signal length is 67. Found possible header: 9093 4400 Found trail pulse: 601 Found repeat code: 9090 2195 Signals are space encoded. Signal length is 32 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) <- because of "buffered" output? Something went wrong. Please try again. (8 retries left) irrecord: no data for 10 secs, aborting The last button did not seem to generate any signal. Press RETURN to continue. Please enter the name for the next button (press <ENTER> to finish recording) KEY_OK Now hold down button "KEY_OK". irrecord: no data for 10 secs, aborting The last button did not seem to generate any signal. Press RETURN to continue. --8<-- Again, this is a plain vanilla Fedora 13, updated with kernel/lirc packages suggested by Jason: - lirc-0.8.7-1.fc14.x86_64 - kernel-2.6.35.6-46.fc14.x86_64 Hardware is an AsRock 330HT. Cheers, HC -- Hans Christian Saustrup Partner, CodeCompany.dk, Skolebakken 7, 8000 Århus C Mobil +45-30261024 |
From: Jarod W. <ja...@wi...> - 2010-10-21 13:56:24
|
On Oct 21, 2010, at 3:53 AM, HC Saustrup wrote: > Hi! > > On 20-10-2010 19:15, Jarod Wilson wrote: >> >> For Fedora, I have an easier solution... :) Even for F13, you should be able to just grab and install these, and have things work: >> >> http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.6/46.fc14/ >> http://kojipkgs.fedoraproject.org/packages/lirc/0.8.7/1.fc14/ >> >> (lirc isn't strictly needed either if you're using the mce remote, that'll be automatically decoded to input layer events) > I went for the easy solution :) With everything installed, I was able to run irrecord without any device/driver specified (just a fresh filename). I've tried running it with two different remotes - the one that ships with the AsRock 330HT and an Apple aluminium remote. A weird thing happened - on the original remote, some buttons generate "real time" dots, while other buttons generate 5-10 dots *after* releasing the button. Hrm, that's a bit odd. Not sure what's going on there. I never tried irrecord on this hardware myself. I just went straight to using the existing mceusb config when testing lirc support: http://lirc.sourceforge.net/remotes/mceusb/lircd.conf.mceusb ... > With the new Apple aluminium remote: > > --8<-- > Press RETURN now to start recording. > ................................................................................ > Found const length: 108016 > Please keep on pressing buttons like described above. > ................................................................................ > Space/pulse encoded remote control found. > Signal length is 67. I would just start w/an existing NEC template for this one. Note that I know next to squat about irrecord just yet. :) -- Jarod Wilson ja...@wi... |
From: HC S. <hc...@co...> - 2010-10-21 14:51:46
|
Hi! On 21-10-2010 15:56, Jarod Wilson wrote: > I went for the easy solution :) With everything installed, I was able to run irrecord without any device/driver specified (just a fresh filename). I've tried running it with two different remotes - the one that ships with the AsRock 330HT and an Apple aluminium remote. A weird thing happened - on the original remote, some buttons generate "real time" dots, while other buttons generate 5-10 dots *after* releasing the button. > Hrm, that's a bit odd. Not sure what's going on there. I never tried irrecord on this hardware myself. I just went straight to using the existing mceusb config when testing lirc support: > > http://lirc.sourceforge.net/remotes/mceusb/lircd.conf.mceusb No luck with any of the configuration files. I inserted the nuvoton-cir module with debugging enabled, and pressed the "Menu" button on my Apple remote, while cat'ing /dev/lirc0 (through hexdump) and tail'ing /var/log/messages. I got this while holding the button down: Oct 21 16:35:14 localhost kernel: [26444.782829] nuvoton_cir: IRQ 0xc2 (IREN 0x60) : RDR RTR TFU Oct 21 16:35:14 localhost kernel: [26444.782888] nvt_dump_rx_buf (len 24): 0xff 0xb6 0x59 0x8b 0x0b 0x8b 0x21 0x8b 0x21 0x8b 0x21 0x8b 0x0b 0x8b 0x21 0x8c 0x21 0x8b 0x21 0x8c 0x20 0x8b 0x21 0x8c Oct 21 16:35:14 localhost kernel: [26444.799582] nuvoton_cir: IRQ 0xc4 (IREN 0x60) : RDR RTR TTR Oct 21 16:35:14 localhost kernel: [26444.799640] nvt_dump_rx_buf (len 24): 0x20 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x21 0x8b 0x0b 0x8b 0x21 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8c 0x0b 0x8b Oct 21 16:35:14 localhost kernel: [26444.840654] nuvoton_cir: IRQ 0xc4 (IREN 0x60) : RDR RTR TTR Oct 21 16:35:14 localhost kernel: [26444.840715] nvt_dump_rx_buf (len 24): 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x21 0x8b 0x21 0x8c 0x20 0x8b 0x21 0x8b 0x0b 0x8c 0x0b 0x8b 0x7f 0x7f 0x7f 0x7f Oct 21 16:35:15 localhost kernel: [26444.970179] nuvoton_cir: IRQ 0xc6 (IREN 0x60) : RDR RTR TTR TFU Oct 21 16:35:15 localhost kernel: [26444.970238] nvt_dump_rx_buf (len 24): 0x7f 0x7f 0x30 0xff 0xb6 0x2c 0x8b 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x13 0xff Oct 21 16:35:15 localhost kernel: [26445.090143] nuvoton_cir: IRQ 0xc4 (IREN 0x60) : RDR RTR TTR Oct 21 16:35:15 localhost kernel: [26445.090200] nvt_dump_rx_buf (len 24): 0xb6 0x2c 0x8b 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x13 0xff 0xb6 0x2c 0x8c 0x7f Oct 21 16:35:15 localhost kernel: [26445.223573] nuvoton_cir: IRQ 0xc6 (IREN 0x60) : RDR RTR TTR TFU Oct 21 16:35:15 localhost kernel: [26445.223632] nvt_dump_rx_buf (len 24): 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x12 0xff 0xb7 0x2c 0x8b 0x7f 0x7f 0x7f 0x7f 0x7f Oct 21 16:35:15 localhost kernel: [26445.357021] nuvoton_cir: IRQ 0xc6 (IREN 0x60) : RDR RTR TTR TFU Oct 21 16:35:15 localhost kernel: [26445.357081] nvt_dump_rx_buf (len 24): 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x13 0xff 0xb7 0x2b 0x8b 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f Oct 21 16:35:15 localhost kernel: [26445.490497] nuvoton_cir: IRQ 0xc6 (IREN 0x60) : RDR RTR TTR TFU Oct 21 16:35:15 localhost kernel: [26445.490556] nvt_dump_rx_buf (len 24): 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x13 0xff 0xb6 0x2c 0x8c 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f Oct 21 16:35:15 localhost kernel: [26445.507920] nuvoton_cir: IRQ 0xa6 (IREN 0x60) : RDR PE TTR TFU Oct 21 16:35:15 localhost kernel: [26445.507947] nvt_dump_rx_buf (len 3): 0x7f 0x7f 0x80 While nothing appeared in the 'cat /dev/lirc0' window until I *released* the button again: $ cat /dev/lirc0 | hexdump -C 00000000 5a 23 00 01 62 11 00 00 26 02 00 01 26 02 00 00 |Z#..b...&...&...| 00000010 26 02 00 01 72 06 00 00 26 02 00 01 72 06 00 00 |&...r...&...r...| 00000020 26 02 00 01 72 06 00 00 26 02 00 01 26 02 00 00 |&...r...&...&...| 00000030 26 02 00 01 72 06 00 00 58 02 00 01 72 06 00 00 |&...r...X...r...| 00000040 26 02 00 01 72 06 00 00 58 02 00 01 40 06 00 00 |&...r...X...@...| * 00000060 26 02 00 01 26 02 00 00 26 02 00 01 26 02 00 00 |&...&...&...&...| * 00000080 26 02 00 01 72 06 00 00 26 02 00 01 26 02 00 00 |&...r...&...&...| * 000000a0 26 02 00 01 26 02 00 00 26 02 00 01 26 02 00 00 |&...&...&...&...| 000000b0 58 02 00 01 26 02 00 00 26 02 00 01 26 02 00 00 |X...&...&...&...| 000000c0 26 02 00 01 26 02 00 00 26 02 00 01 26 02 00 00 |&...&...&...&...| 000000d0 26 02 00 01 26 02 00 00 26 02 00 01 72 06 00 00 |&...&...&...r...| 000000e0 26 02 00 01 72 06 00 00 58 02 00 01 40 06 00 00 |&...r...X...@...| 000000f0 26 02 00 01 72 06 00 00 26 02 00 01 26 02 00 00 |&...r...&...&...| 00000100 58 02 00 01 26 02 00 00 26 02 00 01 34 9e 00 00 |X...&...&...4...| 00000110 5a 23 00 01 98 08 00 00 26 02 00 01 c8 77 01 00 |Z#......&....w..| * 00000130 5a 23 00 01 98 08 00 00 58 02 00 01 96 77 01 00 |Z#......X....w..| 00000140 8c 23 00 01 98 08 00 00 26 02 00 01 c8 77 01 00 |.#......&....w..| 00000150 8c 23 00 01 66 08 00 00 26 02 00 01 c8 77 01 00 |.#..f...&....w..| 00000160 5a 23 00 01 98 08 00 00 58 02 00 01 12 74 01 00 |Z#......X....t..| While the Apple remote does *not* produce any output from /dev/lirc0 until I release the button, *some* of the buttons on the original remote do I'm not sure if it's useful, but here is output from "volume down" (-) on the original remote - it produces continuous data from /dev/lirc0: Oct 21 16:40:11 localhost kernel: [26741.070262] nuvoton_cir: IRQ 0xc6 (IREN 0x60) : RDR RTR TTR TFU Oct 21 16:40:11 localhost kernel: [26741.070320] nvt_dump_rx_buf (len 24): 0xb7 0x10 0x8a 0x07 0x8b 0x07 0x8a 0x10 0x8a 0x10 0x9c 0x10 0x8a 0x08 0x8a 0x08 0x8a 0x08 0x8a 0x08 0x8a 0x08 0x8a 0x07 Oct 21 16:40:11 localhost kernel: [26741.081812] nuvoton_cir: IRQ 0xc4 (IREN 0x60) : RDR RTR TTR Oct 21 16:40:11 localhost kernel: [26741.081870] nvt_dump_rx_buf (len 24): 0x8a 0x08 0x8a 0x08 0x8a 0x08 0x8a 0x08 0x93 0x08 0x8a 0x08 0x8a 0x08 0x8a 0x10 0x8a 0x08 0x8a 0x07 0x8a 0x07 0x8a 0x08 Oct 21 16:40:11 localhost kernel: [26741.136123] nuvoton_cir: IRQ 0xc6 (IREN 0x60) : RDR RTR TTR TFU Oct 21 16:40:11 localhost kernel: [26741.136182] nvt_dump_rx_buf (len 24): 0x93 0x11 0x8a 0x07 0x8a 0x08 0x8b 0x07 0x8a 0x08 0x93 0x11 0x8a 0x07 0x8a 0x07 0x93 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 00008a80 f4 01 00 01 12 74 01 00 be 0a 00 01 20 03 00 00 |.....t...... ...| 00008a90 f4 01 00 01 5e 01 00 00 26 02 00 01 5e 01 00 00 |....^...&...^...| 00008aa0 f4 01 00 01 20 03 00 00 f4 01 00 01 20 03 00 00 |.... ....... ...| 00008ab0 78 05 00 01 20 03 00 00 f4 01 00 01 90 01 00 00 |x... ...........| 00008ac0 f4 01 00 01 90 01 00 00 f4 01 00 01 90 01 00 00 |................| I'm doing a lot of guessing here, and I'm thinking it's an issue with the nuvoton-cir module - from what's coming from the kernel in /var/log/messages, it looks like data is flowing nicely from the IR receiver but something in the driver refuses to pass the data on to /dev/lirc0. Could this be a problem with gap detection maybe? Maybe my AsRock 330HT box is configured slightly different than yours? Please let me know if there is anything I can do to assist debugging this issue. Cheers, HC -- Hans Christian Saustrup Partner, CodeCompany.dk, Skolebakken 7, 8000 Århus C Mobil +45-30261024 |
From: Jarod W. <ja...@wi...> - 2010-10-25 15:48:23
|
On Oct 21, 2010, at 10:51 AM, HC Saustrup wrote: > Hi! > > On 21-10-2010 15:56, Jarod Wilson wrote: >> I went for the easy solution :) With everything installed, I was able to run irrecord without any device/driver specified (just a fresh filename). I've tried running it with two different remotes - the one that ships with the AsRock 330HT and an Apple aluminium remote. A weird thing happened - on the original remote, some buttons generate "real time" dots, while other buttons generate 5-10 dots *after* releasing the button. >> Hrm, that's a bit odd. Not sure what's going on there. I never tried irrecord on this hardware myself. I just went straight to using the existing mceusb config when testing lirc support: >> >> http://lirc.sourceforge.net/remotes/mceusb/lircd.conf.mceusb > No luck with any of the configuration files. I inserted the nuvoton-cir module with debugging enabled, and pressed the "Menu" button on my Apple remote, while cat'ing /dev/lirc0 (through hexdump) and tail'ing /var/log/messages. Well, the Apple remote definitely isn't going to work with the mceusb config... Which you may know, and I may just be misreading what you said above, but I just want to be sure that's clear. > I got this while holding the button down: > > Oct 21 16:35:14 localhost kernel: [26444.782829] nuvoton_cir: IRQ 0xc2 (IREN 0x60) : RDR RTR TFU > Oct 21 16:35:14 localhost kernel: [26444.782888] nvt_dump_rx_buf (len 24): 0xff 0xb6 0x59 0x8b 0x0b 0x8b 0x21 0x8b 0x21 0x8b 0x21 0x8b 0x0b 0x8b 0x21 0x8c 0x21 0x8b 0x21 0x8c 0x20 0x8b 0x21 0x8c > Oct 21 16:35:14 localhost kernel: [26444.799582] nuvoton_cir: IRQ 0xc4 (IREN 0x60) : RDR RTR TTR > Oct 21 16:35:14 localhost kernel: [26444.799640] nvt_dump_rx_buf (len 24): 0x20 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x21 0x8b 0x0b 0x8b 0x21 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8c 0x0b 0x8b > Oct 21 16:35:14 localhost kernel: [26444.840654] nuvoton_cir: IRQ 0xc4 (IREN 0x60) : RDR RTR TTR > Oct 21 16:35:14 localhost kernel: [26444.840715] nvt_dump_rx_buf (len 24): 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x0b 0x8b 0x21 0x8b 0x21 0x8c 0x20 0x8b 0x21 0x8b 0x0b 0x8c 0x0b 0x8b 0x7f 0x7f 0x7f 0x7f > Oct 21 16:35:15 localhost kernel: [26444.970179] nuvoton_cir: IRQ 0xc6 (IREN 0x60) : RDR RTR TTR TFU > Oct 21 16:35:15 localhost kernel: [26444.970238] nvt_dump_rx_buf (len 24): 0x7f 0x7f 0x30 0xff 0xb6 0x2c 0x8b 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x13 0xff ... > I'm doing a lot of guessing here, and I'm thinking it's an issue with the nuvoton-cir module - from what's coming from the kernel in /var/log/messages, it looks like data is flowing nicely from the IR receiver but something in the driver refuses to pass the data on to /dev/lirc0. Could this be a problem with gap detection maybe? Yeah, I think I see what's going on. I suspect protocol in use makes a difference here (the Apple remotes being NEC, vs. the MCE ones being RC-6), though I dunno why not all of your MCE keys were coming through -- all worked perfectly here, last I tried. > Maybe my AsRock 330HT box is configured slightly different than yours? I doubt it, I think its probably a bug in the driver with its buffer parsing to determine end of signal. > Please let me know if there is anything I can do to assist debugging this issue. I've got an Apple remote around here somewhere, and/or a Harmony I can program to emulate one, so I should be able to reproduce the problem here and get it fixed. -- Jarod Wilson ja...@wi... |
From: HC S. <hc...@co...> - 2010-10-25 18:58:30
|
On 10/25/10 5:48 PM, Jarod Wilson wrote: > Well, the Apple remote definitely isn't going to work with the mceusb config... Which you may know, and I may just be misreading what you said above, but I just want to be sure that's clear. > Absolutely - I just inserted the nuvoton-cir driver, cat'ed /dev/lirc0 and looked in dmesg. lircd wasn't running, so the mceusb config wasn't even in the picture. > Yeah, I think I see what's going on. I suspect protocol in use makes a difference here (the Apple remotes being NEC, vs. the MCE ones being RC-6), though I dunno why not all of your MCE keys were coming through -- all worked perfectly here, last I tried. > So the data coming from /dev/lirc0 isn't as raw as I thought it was :) Is there any way to turn off protocol decoding or perhaps switch to NEC? I'm equally puzzled about the original remote not working - let me know if/how I can provide helpful information. Maybe you can use output from the "mode2" tool? > I doubt it, I think its probably a bug in the driver with its buffer parsing to determine end of signal. We have about a dozen boxes purchased over the last six months or so - I'll happily test anything you come up with on them and provide whatever feedback you may need. Thanks for your work on this :) Cheers, HC |
From: Jarod W. <ja...@wi...> - 2010-10-25 19:54:05
|
On Oct 25, 2010, at 2:58 PM, HC Saustrup wrote: > On 10/25/10 5:48 PM, Jarod Wilson wrote: >> >> Yeah, I think I see what's going on. I suspect protocol in use makes a difference here (the Apple remotes being NEC, vs. the MCE ones being RC-6), though I dunno why not all of your MCE keys were coming through -- all worked perfectly here, last I tried. >> > So the data coming from /dev/lirc0 isn't as raw as I thought it was :) No, it is pretty raw, but its not delivered instantaneously from the hardware to userspace. > Is there any way to turn off protocol decoding or perhaps switch to NEC? I'm equally puzzled about the original remote not working - let me know if/how I can provide helpful information. Maybe you can use output from the "mode2" tool? There's no protocol decoding being done at all here. Its a case of decoding the hardware RX FIFO format. There are specific bytes we look for and key off of in an RX FIFO stream to know when we've reached the end of a discrete signal. What we're keying off of now seems to work fine for RC6 on my box, but your raw buffer contents for the NEC-proto Apple remote look a bit different at the tail end. I have an idea in my head for how this might be remedied, but I need to sit down, write some code and test it. >> I doubt it, I think its probably a bug in the driver with its buffer parsing to determine end of signal. > We have about a dozen boxes purchased over the last six months or so - I'll happily test anything you come up with on them and provide whatever feedback you may need. Cool. I'll try to get some work in on this as soon as I can, but I'm a bit tied up with other things at the moment (among which is finally putting together a 0.9.0-pre1 lirc tarball). -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-11-02 19:45:06
|
On Mon, Oct 25, 2010 at 3:53 PM, Jarod Wilson <ja...@wi...> wrote: > On Oct 25, 2010, at 2:58 PM, HC Saustrup wrote: ... >> Is there any way to turn off protocol decoding or perhaps switch to NEC? I'm equally puzzled about the original remote not working - let me know if/how I can provide helpful information. Maybe you can use output from the "mode2" tool? > > There's no protocol decoding being done at all here. Its a case of decoding the hardware RX FIFO format. There are specific bytes we look for and key off of in an RX FIFO stream to know when we've reached the end of a discrete signal. What we're keying off of now seems to work fine for RC6 on my box, but your raw buffer contents for the NEC-proto Apple remote look a bit different at the tail end. I have an idea in my head for how this might be remedied, but I need to sit down, write some code and test it. I believe I have a functional patch to the nuvoton driver, but I need/want to do a touch more testing with it -- specifically with my own Apple remote. Which, by the way, is NEC only at the physical layer, the actual format of the data is significantly different, so at the moment, the in-kernel NEC decoder barfs on it. :) (I've also thrown together an Apple-specific decoder, complete with pairing support, but I still need to test that out as well). Hope to have something you can try out by the end of the week, but its also Linux Plumbers Conference this week, so time may or may not be found to get this squared away... -- Jarod Wilson ja...@wi... |
From: HC S. <hc...@co...> - 2010-11-02 23:07:56
|
On 11/2/10 8:44 PM, Jarod Wilson wrote: > > I believe I have a functional patch to the nuvoton driver, but I > need/want to do a touch more testing with it -- specifically with my > own Apple remote. Which, by the way, is NEC only at the physical > layer, the actual format of the data is significantly different, so at > the moment, the in-kernel NEC decoder barfs on it. :) (I've also > thrown together an Apple-specific decoder, complete with pairing > support, but I still need to test that out as well). Hope to have > something you can try out by the end of the week, but its also Linux > Plumbers Conference this week, so time may or may not be found to get > this squared away... > > This is amazing news! Thank your all the time you're invested in this! I'm really looking forward to test this :-) I can't believe you went out and got an Apple remote just to make this slightly weird combo work - you're awesome :-D Cheers, HC |
From: Jarod W. <ja...@wi...> - 2010-11-03 05:25:23
|
On Nov 2, 2010, at 7:07 PM, HC Saustrup wrote: > On 11/2/10 8:44 PM, Jarod Wilson wrote: >> >> I believe I have a functional patch to the nuvoton driver, but I >> need/want to do a touch more testing with it -- specifically with my >> own Apple remote. Which, by the way, is NEC only at the physical >> layer, the actual format of the data is significantly different, so at >> the moment, the in-kernel NEC decoder barfs on it. :) (I've also >> thrown together an Apple-specific decoder, complete with pairing >> support, but I still need to test that out as well). Hope to have >> something you can try out by the end of the week, but its also Linux >> Plumbers Conference this week, so time may or may not be found to get >> this squared away... >> >> > This is amazing news! Thank your all the time you're invested in this! I'm really looking forward to test this :-) I can't believe you went out and got an Apple remote just to make this slightly weird combo work - you're awesome :-D Heh, I'm not *that* awesome, I already had the Apple remote laying around, I just had to find it. (I own several macs and an appletv, typing this very mail on one of said macs). Just did a quick smoke test w/my asrock and the apple remote, and its decoding perfectly. I still have Fedora 13 installed on mine, but built a kernel based on the Fedora 15-to-be kernel tree that should work on 13, 14 or 15, which you can grab here to try out (assuming you're running x86_64), if you like: http://wilsonet.com/jarod/ir-core/test_kernel/ Its got an updated nuvoton-cir driver in it w/the buffer parsing changes I mentioned, as well as a stand-alone Apple remote decoder, which is still under development/discussion upstream for exact implementation details (main question left is how to support pairing). -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-11-11 15:46:32
|
On Nov 3, 2010, at 1:25 AM, Jarod Wilson wrote: > On Nov 2, 2010, at 7:07 PM, HC Saustrup wrote: > >> On 11/2/10 8:44 PM, Jarod Wilson wrote: >>> >>> I believe I have a functional patch to the nuvoton driver, but I >>> need/want to do a touch more testing with it -- specifically with my >>> own Apple remote. Which, by the way, is NEC only at the physical >>> layer, the actual format of the data is significantly different, so at >>> the moment, the in-kernel NEC decoder barfs on it. :) (I've also >>> thrown together an Apple-specific decoder, complete with pairing >>> support, but I still need to test that out as well). Hope to have >>> something you can try out by the end of the week, but its also Linux >>> Plumbers Conference this week, so time may or may not be found to get >>> this squared away... >>> >>> >> This is amazing news! Thank your all the time you're invested in this! I'm really looking forward to test this :-) I can't believe you went out and got an Apple remote just to make this slightly weird combo work - you're awesome :-D > > Heh, I'm not *that* awesome, I already had the Apple remote laying around, I just had to find it. (I own several macs and an appletv, typing this very mail on one of said macs). > > Just did a quick smoke test w/my asrock and the apple remote, and its decoding perfectly. I still have Fedora 13 installed on mine, but built a kernel based on the Fedora 15-to-be kernel tree that should work on 13, 14 or 15, which you can grab here to try out (assuming you're running x86_64), if you like: > > http://wilsonet.com/jarod/ir-core/test_kernel/ > > Its got an updated nuvoton-cir driver in it w/the buffer parsing changes I mentioned, as well as a stand-alone Apple remote decoder, which is still under development/discussion upstream for exact implementation details (main question left is how to support pairing). Still wrestling with some keybounce issues, so the Apple remote patches still aren't upstream yet. Did get an updated F14 kernel together that includes the buffer parsing responsiveness improvements for nuvoton-cir though: http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.8/53.fc14/ With that, you should at least be able to use the Apple remotes just fine using lirc userspace decoding. -- Jarod Wilson ja...@wi... |
From: Mariusz B. <ma...@sk...> - 2010-10-25 17:04:25
|
> So I finally got around to looking at this just now. I'm not sure what the problem is/was on your end, but > everything works perfectly fine here, even with the EV_MSC events reported. (I'm using lircd built from > the git tree w/a Fedora kernel that has all the pending 2.6.37-rc1 IR bits merged in it). Please tell me if you have EV_MSC events *only* - like me? I temporary workaround the problem by loading my custom keyboard map from file: input-kbd -f my_keymap 3 I created this file from EV_MSC codes and in this way i have EV_KEY events which are handled properly by lirc. regards, -- Mariusz Białończyk jabber/e-mail: ma...@sk... http://manio.skyboo.net |
From: Jarod W. <ja...@wi...> - 2010-10-25 17:10:59
|
On Oct 25, 2010, at 1:03 PM, Mariusz Bialonczyk wrote: >> So I finally got around to looking at this just now. I'm not sure what the > problem is/was on your end, but >> everything works perfectly fine here, even with the EV_MSC events reported. > (I'm using lircd built from >> the git tree w/a Fedora kernel that has all the pending 2.6.37-rc1 IR bits > merged in it). > > Please tell me if you have EV_MSC events *only* - like me? No, I get both EV_MSC scancodes and EV_KEY keycodes. The devinput driver has *never* worked with just EV_MSC scancodes, so far as I know. > I temporary workaround the problem by loading my custom keyboard map from file: > input-kbd -f my_keymap 3 > I created this file from EV_MSC codes and in this way i have EV_KEY events which > are handled properly by lirc. Okay, so things are actually behaving as expected here. Now, in the future, we actually *can* make the devinput driver handle either or both -- which would actually be useful for handling devices that generate scancodes for which there's no in-kernel keycode mapping, but the current behavior definitely isn't a regression, which was my primary concern here. :) -- Jarod Wilson ja...@wi... |