From: <cv...@kr...> - 2011-03-22 14:44:36
|
Hi - I hope this is the right forum for my question. I'm using an imon receiver (0036), and am running kernel 2.6.35 (Ubuntu 10.10). I've set lirc to use /dev/input/eventX. That works for imon mode, but leaves me with some issues, including startup in mouse mode and endless key repeats at some time. So I'd like to use MCE mode of the imon instead. For this purpose, I have compiled ir-keytable from git and used it to set rc6 and load imon_mce. This works to some extent, i.e. some keys are recognized by irw (KEY_UP, ...) while others (play, stop, ...) are not. I have looked around a lot, but failed to find any information how to create a custom keytable for use with ir-keytable. In previous setups, I used irrecord for this. Any hint for how to adjust the keytable would be highly appreciated. Thanks, Chris |
From: Jarod W. <ja...@wi...> - 2011-03-23 15:30:22
|
On Mar 22, 2011, at 10:09 AM, cv...@kr... wrote: > Hi - I hope this is the right forum for my question. I'm using an imon > receiver (0036), and am running kernel 2.6.35 (Ubuntu 10.10). I've set > lirc to use /dev/input/eventX. That works for imon mode, but leaves me > with some issues, including startup in mouse mode and endless key > repeats at some time. Blame Canonical. These issues have long since been fixed upstream. :) You can use a newer imon driver by going this route too though: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers > So I'd like to use MCE mode of the imon instead. For this purpose, I > have compiled ir-keytable from git and used it to set rc6 and load > imon_mce. This works to some extent, i.e. some keys are recognized by > irw (KEY_UP, ...) while others (play, stop, ...) are not. I have looked > around a lot, but failed to find any information how to create a custom > keytable for use with ir-keytable. In previous setups, I used irrecord > for this. > > Any hint for how to adjust the keytable would be highly appreciated. Run the imon driver in debug mode and snarf the scancode data out of dmesg. I may look at having the driver report unknown scancodes out the event interface like we do with raw IR devices at some point, but its not terribly high priority, so no clue when it might happen... -- Jarod Wilson ja...@wi... |
From: <cv...@kr...> - 2011-03-23 21:11:55
|
On Wed, 23 Mar 2011 11:04:13 -0400, Jarod Wilson wrote: >> Hi - I hope this is the right forum for my question. I'm using an >> imon >> receiver (0036), and am running kernel 2.6.35 (Ubuntu 10.10). I've >> set >> lirc to use /dev/input/eventX. That works for imon mode, but leaves >> me >> with some issues, including startup in mouse mode and endless key >> repeats at some time. > Blame Canonical. These issues have long since been fixed upstream. :) Not sure blaming Canonical would help me. I'd rather like to fix the problem. :-) > You can use a newer imon driver by going this route too though: > > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Thanks, did that. >> Any hint for how to adjust the keytable would be highly appreciated. > Run the imon driver in debug mode and snarf the scancode data out of > dmesg. I may look at having the driver report unknown scancodes out > the event interface like we do with raw IR devices at some point, but > its not terribly high priority, so no clue when it might happen... Ok, no prob. As long as I can get the info from somewhere, I don't care. So I compiled all modules from git installed them, rebooted the machine (yes, I'm taking the easy way). I then reconfigured lirc, the event-way, and had some reports of keypresses in irw - but rather sluggish. So I set it the MCE mode using ir-keytable -p rc6 -w /etc/rc_keymaps/imon_mce. "Play", e.g., on my Harmony (set to MCE) still does not show an output in irw. I put "options debug=1" into lirc_imon.conf. This did show some things in imon mode, but the play key in MCE mode still does not produce any output in the syslog... Hm. Any hints what else I could try? Thanks! |
From: <cv...@kr...> - 2011-03-24 07:17:36
|
I made some further tests: > So I compiled all modules from git installed them, rebooted the > machine > (yes, I'm taking the easy way). I then reconfigured lirc, the > event-way, > and had some reports of keypresses in irw - but rather sluggish. So > I > set it the MCE mode using ir-keytable -p rc6 -w > /etc/rc_keymaps/imon_mce. > > "Play", e.g., on my Harmony (set to MCE) still does not show an > output > in irw. > > I put "options debug=1" into lirc_imon.conf. This did show some > things > in imon mode, but the play key in MCE mode still does not produce > any > output in the syslog... This is not related to MCE (RC6) or imon mode. In both modes, debug mode is working such that *some* unknown keys show up in the syslog. (I loaded "wrong" keytables to test.) However, in both modes (RC6 and IMON), some other keys (sent by the Harmony as well as by the original imon pad) show up neither in irw nor in the syslog. I tried running mode2 (mode2 -d /dev/input/event3 -H devinput), but it says "This program does not work for this hardware yet". So how can I work around lirc (or the kernel mod?) (apparently?) not recognizing some of the signals? Again, I compiled the kernel mod from git, as suggested. Thanks. |
From: Jarod W. <ja...@wi...> - 2011-03-24 19:13:44
|
On Mar 24, 2011, at 3:17 AM, cv...@kr... wrote: > I made some further tests: > >> So I compiled all modules from git installed them, rebooted the >> machine >> (yes, I'm taking the easy way). I then reconfigured lirc, the >> event-way, >> and had some reports of keypresses in irw - but rather sluggish. So >> I >> set it the MCE mode using ir-keytable -p rc6 -w >> /etc/rc_keymaps/imon_mce. >> >> "Play", e.g., on my Harmony (set to MCE) still does not show an >> output >> in irw. >> >> I put "options debug=1" into lirc_imon.conf. This did show some >> things >> in imon mode, but the play key in MCE mode still does not produce >> any >> output in the syslog... I don't know how putting "options debug=1" into lirc_imon.conf does anything. The thing you need is "options imon debug=1", and its just imon, not lirc_imon. > This is not related to MCE (RC6) or imon mode. In both modes, debug > mode is working such that *some* unknown keys show up in the syslog. (I > loaded "wrong" keytables to test.) > > However, in both modes (RC6 and IMON), some other keys (sent by the > Harmony as well as by the original imon pad) show up neither in irw nor > in the syslog. Are your batteries good? Completely unrecognized signals are simply discarded by the hardware, so weak batteries could result in that happening. If the signal is recognized but not matched in the key table, I swear it ought to be showing up in dmesg, but its possible that functionality broke for certain cases at some point, I suppose. > I tried running mode2 (mode2 -d /dev/input/event3 -H > devinput), but it says "This program does not work for this hardware > yet". mode2 is for raw IR. The imon hardware decodes IR onboard and passes along scancodes. mode2 isn't going to do anything. > So how can I work around lirc (or the kernel mod?) (apparently?) not > recognizing some of the signals? Again, I compiled the kernel mod from > git, as suggested. Make sure your batteries are good first. If you're positive they are, then we may need to do some additional instrumentation to the imon driver to see where things are going awry. All five of my imon devices work perfectly though, so I'm sort of shooting in the dark here. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-03-24 19:52:10
|
On Mar 24, 2011, at 3:13 PM, Jarod Wilson wrote: > On Mar 24, 2011, at 3:17 AM, cv...@kr... wrote: > >> I made some further tests: >> >>> So I compiled all modules from git installed them, rebooted the >>> machine >>> (yes, I'm taking the easy way). I then reconfigured lirc, the >>> event-way, >>> and had some reports of keypresses in irw - but rather sluggish. So >>> I >>> set it the MCE mode using ir-keytable -p rc6 -w >>> /etc/rc_keymaps/imon_mce. >>> >>> "Play", e.g., on my Harmony (set to MCE) still does not show an >>> output >>> in irw. >>> >>> I put "options debug=1" into lirc_imon.conf. This did show some >>> things >>> in imon mode, but the play key in MCE mode still does not produce >>> any >>> output in the syslog... > > I don't know how putting "options debug=1" into lirc_imon.conf does > anything. The thing you need is "options imon debug=1", and its just > imon, not lirc_imon. > > >> This is not related to MCE (RC6) or imon mode. In both modes, debug >> mode is working such that *some* unknown keys show up in the syslog. (I >> loaded "wrong" keytables to test.) >> >> However, in both modes (RC6 and IMON), some other keys (sent by the >> Harmony as well as by the original imon pad) show up neither in irw nor >> in the syslog. > > Are your batteries good? Completely unrecognized signals are simply > discarded by the hardware, so weak batteries could result in that > happening. If the signal is recognized but not matched in the key > table, I swear it ought to be showing up in dmesg, but its possible > that functionality broke for certain cases at some point, I suppose. > > >> I tried running mode2 (mode2 -d /dev/input/event3 -H >> devinput), but it says "This program does not work for this hardware >> yet". > > mode2 is for raw IR. The imon hardware decodes IR onboard and passes > along scancodes. mode2 isn't going to do anything. > > >> So how can I work around lirc (or the kernel mod?) (apparently?) not >> recognizing some of the signals? Again, I compiled the kernel mod from >> git, as suggested. > > Make sure your batteries are good first. If you're positive they are, > then we may need to do some additional instrumentation to the imon > driver to see where things are going awry. All five of my imon devices > work perfectly though, so I'm sort of shooting in the dark here. Just looked at the code. For every key press, if you have debugging enabled in the latest imon driver code, it will print out a message: intf{0,1} decoded packet: <scancode> The only cases where that doesn't run is when the remote is in mouse mode and you use the mouse pad or buttons, or if you hit the toggle button. -- Jarod Wilson ja...@wi... |
From: <cv...@kr...> - 2011-03-25 14:01:59
|
On Thu, 24 Mar 2011 15:52:14 -0400, Jarod Wilson wrote: > Just looked at the code. For every key press, if you have debugging > enabled in the latest imon driver code, it will print out a message: > > intf{0,1} decoded packet: <scancode> > > The only cases where that doesn't run is when the remote is in mouse > mode and you use the mouse pad or buttons, or if you hit the toggle > button. Changing parameters and filename for enabling the debug mode helped. I do now get syslog output for every keypress. The second problem was that eventX-allocation was changing upon every boot, which made irw unreliable. So I changed hardware.conf to refer to /dev/input/by-path/... Interestingly, now KEY_PLAY is recognized as well. Strange, but good. By the way, now when I press the KEY_UP now for the first time, irw shows nothing, and the syslog says: Mar 25 14:49:52 htpc kernel: [ 293.524776] intf0 decoded packet: 01 00 00 f2 00 00 00 00 Mar 25 14:49:52 htpc kernel: [ 293.524787] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 Pressing KEY_UP the second time, irw shows 0000000080010067 00 KEY_UP devinput and the syslog shows Mar 25 14:50:00 htpc kernel: [ 302.016015] intf0 decoded packet: 01 00 00 f2 00 00 00 00 Mar 25 14:50:00 htpc kernel: [ 302.016025] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 Mar 25 14:50:00 htpc kernel: [ 302.056102] intf0 decoded packet: 01 00 00 f2 00 00 00 00 Mar 25 14:50:00 htpc kernel: [ 302.056112] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: you are using an obsolete devinput config file: Success Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: get the new version at http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput: Success Mar 25 14:50:00 htpc kernel: [ 302.088128] intf0 decoded packet: 01 00 80 00 00 00 00 00 I have done the obvious: In /usr/share/lirc/remotes/devinput I rant wget http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput and rebooted the machine. But this message continues to appear in syslog... Even after the above message about an automatic update of lircd.conf.devinput, irw and syslog still show strange messages (thereafter tested with KEY_DOWN): First press: No show in irw, syslog says: Mar 25 14:53:30 htpc kernel: [ 511.798377] intf0 decoded packet: 01 00 00 0e 00 00 00 00 Mar 25 14:53:30 htpc kernel: [ 511.798388] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e Second press: Success in irw: 000000008001006c 00 KEY_DOWN devinput syslog: Mar 25 14:53:38 htpc kernel: [ 519.482156] intf0 decoded packet: 01 00 00 0e 00 00 00 00 Mar 25 14:53:38 htpc kernel: [ 519.482163] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e Mar 25 14:53:38 htpc kernel: [ 519.522184] intf0 decoded packet: 01 00 00 0e 00 00 00 00 Mar 25 14:53:38 htpc kernel: [ 519.522194] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e Mar 25 14:53:38 htpc kernel: [ 519.562156] intf0 decoded packet: 01 00 7f 00 00 00 00 00 Do I have do add additional keycodes for the keypresses (KEY_UP, KEY_DOWN, ...) to imon_pad? Or is something else still messed up in my setup? Clearly, I'm looking to get every key press recognized. :-) BTW: These problems only occur with the directions (KEY_UP, KEY_DOWN, ...). KEY_PLAY, e.g., is working ok - and recognized every time I press the key. Also no error messages there in syslog. Thanks again! |
From: Jarod W. <ja...@wi...> - 2011-03-25 19:46:04
|
On Mar 25, 2011, at 10:01 AM, cv...@kr... wrote: > On Thu, 24 Mar 2011 15:52:14 -0400, Jarod Wilson wrote: >> Just looked at the code. For every key press, if you have debugging >> enabled in the latest imon driver code, it will print out a message: >> >> intf{0,1} decoded packet: <scancode> >> >> The only cases where that doesn't run is when the remote is in mouse >> mode and you use the mouse pad or buttons, or if you hit the toggle >> button. > > Changing parameters and filename for enabling the debug mode helped. I do now get syslog output for every keypress. The second problem was that eventX-allocation was changing upon every boot, which made irw unreliable. So I changed hardware.conf to refer to /dev/input/by-path/... > > Interestingly, now KEY_PLAY is recognized as well. Strange, but good. By the way, now when I press the KEY_UP now for the first time, irw shows nothing, and the syslog says: > > Mar 25 14:49:52 htpc kernel: [ 293.524776] intf0 decoded packet: 01 00 00 f2 00 00 00 00 > Mar 25 14:49:52 htpc kernel: [ 293.524787] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 > > Pressing KEY_UP the second time, irw shows > > 0000000080010067 00 KEY_UP devinput > > and the syslog shows > > Mar 25 14:50:00 htpc kernel: [ 302.016015] intf0 decoded packet: 01 00 00 f2 00 00 00 00 > Mar 25 14:50:00 htpc kernel: [ 302.016025] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 > Mar 25 14:50:00 htpc kernel: [ 302.056102] intf0 decoded packet: 01 00 00 f2 00 00 00 00 > Mar 25 14:50:00 htpc kernel: [ 302.056112] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 This happens, because of the way the pad-to-keys filtering in the imon driver works. The pad sends hundreds of distinct signals, which we try to gather up and determine an up/down/left/right direction from. If we don't have enough data to work with (see the pad threshold bits in the code), then we don't find a direction, and the raw value from the pad leaks through (when in keyboard mode -- in mouse mode, its just mouse movement). Basically, its nothing to worry about. You may want to tweak your pad_thresh value (via modparam) to fine-tune how much pressure is needed on the pad to register up/down/left/right though. > Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: you are using an obsolete devinput config file: Success > Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: get the new version at http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput: Success > Mar 25 14:50:00 htpc kernel: [ 302.088128] intf0 decoded packet: 01 00 80 00 00 00 00 00 > > I have done the obvious: In /usr/share/lirc/remotes/devinput I rant wget http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput and rebooted the machine. But this message continues to appear in syslog... Yeah, I think you actually want the one in lirc git, I need to push out a bunch of remote definition updates, including that one. -- Jarod Wilson ja...@wi... |
From: <cv...@kr...> - 2011-03-28 10:28:45
|
On Fri, 25 Mar 2011 15:39:21 -0400, Jarod Wilson wrote: >> when I press the KEY_UP now for the first time, irw shows nothing, >> and the syslog says: >> >> Mar 25 14:49:52 htpc kernel: [ 293.524776] intf0 decoded packet: 01 >> 00 00 f2 00 00 00 00 >> Mar 25 14:49:52 htpc kernel: [ 293.524787] imon 1-1.6.1:1.0: >> imon_incoming_packet: unknown keypress, code 0x10000f2 >> >> Pressing KEY_UP the second time, irw shows >> >> 0000000080010067 00 KEY_UP devinput >> >> and the syslog shows >> >> Mar 25 14:50:00 htpc kernel: [ 302.016015] intf0 decoded packet: 01 >> 00 00 f2 00 00 00 00 >> Mar 25 14:50:00 htpc kernel: [ 302.016025] imon 1-1.6.1:1.0: >> imon_incoming_packet: unknown keypress, code 0x10000f2 >> Mar 25 14:50:00 htpc kernel: [ 302.056102] intf0 decoded packet: 01 >> 00 00 f2 00 00 00 00 >> Mar 25 14:50:00 htpc kernel: [ 302.056112] imon 1-1.6.1:1.0: >> imon_incoming_packet: unknown keypress, code 0x10000f2 > > This happens, because of the way the pad-to-keys filtering in the > imon > driver works. The pad sends hundreds of distinct signals, which we > try > to gather up and determine an up/down/left/right direction from. If > we > don't have enough data to work with (see the pad threshold bits in > the > code), then we don't find a direction, and the raw value from the pad > leaks through (when in keyboard mode -- in mouse mode, its just mouse > movement). Basically, its nothing to worry about. You may want to > tweak > your pad_thresh value (via modparam) to fine-tune how much pressure > is > needed on the pad to register up/down/left/right though. I'm getting these errors/messages in syslog as well when I use a harmony configured as imon-pad. And the harmony has normal buttons, not this pad. So it seems that, for a better responsiveness, I should add 0x10000f2 and the other codes somehow to lirc. I tried editing the imon-pad keytable and then loading it into the kernel with ir-keytable. But that didn't help, pressing keys still caused the "unknown keypress" messages in syslog. How would I need to edit the keytable (or anything else) in order to get the additional 0x10000f2 code recognized? I can then add the other codes as well, and am happy to feed back the result to you, if that helps (others). >> Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: you are using an >> obsolete devinput config file: Success >> Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: get the new version at >> http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput: >> Success > Yeah, I think you actually want the one in lirc git, I need to push > out a bunch of remote definition updates, including that one. The new one was not included in the 0.9.0 archive, right? I tried the devinput from that archive, but it was similar to the one I already have installed. |
From: Jarod W. <ja...@wi...> - 2011-03-29 20:00:28
|
On Mar 28, 2011, at 6:28 AM, cv...@kr... wrote: > On Fri, 25 Mar 2011 15:39:21 -0400, Jarod Wilson wrote: > >>> when I press the KEY_UP now for the first time, irw shows nothing, and the syslog says: >>> >>> Mar 25 14:49:52 htpc kernel: [ 293.524776] intf0 decoded packet: 01 00 00 f2 00 00 00 00 >>> Mar 25 14:49:52 htpc kernel: [ 293.524787] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 >>> >>> Pressing KEY_UP the second time, irw shows >>> >>> 0000000080010067 00 KEY_UP devinput >>> >>> and the syslog shows >>> >>> Mar 25 14:50:00 htpc kernel: [ 302.016015] intf0 decoded packet: 01 00 00 f2 00 00 00 00 >>> Mar 25 14:50:00 htpc kernel: [ 302.016025] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 >>> Mar 25 14:50:00 htpc kernel: [ 302.056102] intf0 decoded packet: 01 00 00 f2 00 00 00 00 >>> Mar 25 14:50:00 htpc kernel: [ 302.056112] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x10000f2 >> >> This happens, because of the way the pad-to-keys filtering in the imon >> driver works. The pad sends hundreds of distinct signals, which we try >> to gather up and determine an up/down/left/right direction from. If we >> don't have enough data to work with (see the pad threshold bits in the >> code), then we don't find a direction, and the raw value from the pad >> leaks through (when in keyboard mode -- in mouse mode, its just mouse >> movement). Basically, its nothing to worry about. You may want to tweak >> your pad_thresh value (via modparam) to fine-tune how much pressure is >> needed on the pad to register up/down/left/right though. > > I'm getting these errors/messages in syslog as well when I use a harmony configured as imon-pad. And the harmony has normal buttons, not this pad. So it seems that, for a better responsiveness, I should add 0x10000f2 and the other codes somehow to lirc. I tried editing the imon-pad keytable and then loading it into the kernel with ir-keytable. But that didn't help, pressing keys still caused the "unknown keypress" messages in syslog. Hm. Wonder what the Harmony config is actually doing there as far as the signals its sending... > How would I need to edit the keytable (or anything else) in order to get the additional 0x10000f2 code recognized? I can then add the other codes as well, and am happy to feed back the result to you, if that helps (others). Edit drivers/media/rc/keymaps/rc-imon-pad.c. But pushing the code in using ir-keytable *should* work just as well. >>> Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: you are using an obsolete devinput config file: Success >>> Mar 25 14:50:00 htpc lircd-0.8.7-pre3[959]: get the new version at http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput: Success >> Yeah, I think you actually want the one in lirc git, I need to push >> out a bunch of remote definition updates, including that one. > > The new one was not included in the 0.9.0 archive, right? I tried the devinput from that archive, but it was similar to the one I already have installed. Hrm. I'm not sure what the heck is going on then. I've never seen this message myself, using the one in git. Perhaps I just haven't been looking, or its somehow particular to Ubuntu, which it seems just about everyone who has reported this issue is using... -- Jarod Wilson ja...@wi... |
From: <cv...@kr...> - 2011-04-04 16:10:46
|
On Tue, 29 Mar 2011 16:00:30 -0400, Jarod Wilson wrote: >> I'm getting these errors/messages in syslog as well when I use a >> harmony configured as imon-pad. And the harmony has normal buttons, >> not this pad. So it seems that, for a better responsiveness, I >> should add 0x10000f2 and the other codes somehow to lirc. I tried >> editing the imon-pad keytable and then loading it into the kernel >> with ir-keytable. But that didn't help, pressing keys still caused >> the "unknown keypress" messages in syslog. > Hm. Wonder what the Harmony config is actually doing there as far as > the signals its sending... Don't know, but except for this it's working ok. >> How would I need to edit the keytable (or anything else) in order >> to get the additional 0x10000f2 code recognized? I can then add the >> other codes as well, and am happy to feed back the result to you, >> if that helps (others). > Edit drivers/media/rc/keymaps/rc-imon-pad.c. But pushing the code in > using ir-keytable *should* work just as well. Ok, I tried the latter. Syslog: Apr 3 15:44:08 htpc kernel: [ 103.731590] intf0 decoded packet: 01 00 00 0e 00 00 00 00 Apr 3 15:44:08 htpc kernel: [ 103.731601] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e Apr 3 15:44:08 htpc kernel: [ 103.771564] intf0 decoded packet: 01 00 00 0e 00 00 00 00 Apr 3 15:44:08 htpc kernel: [ 103.771574] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e Apr 3 15:44:08 htpc kernel: [ 103.803599] intf0 decoded packet: 01 00 7f 00 00 00 00 00 Then I created a new keytable with the 0x100000e code, based on the imon template: [...] 0x01008000 KEY_UP 0x10000f2 KEY_UP 0x01007f00 KEY_DOWN 0x100000e KEY_DOWN 0x01000080 KEY_LEFT 0x100f200 KEY_LEFT 0x0100007f KEY_RIGHT 0x1000e00 KEY_RIGHT 0x2aa515b7 KEY_UP 0x289515b7 KEY_DOWN 0x29a515b7 KEY_LEFT 0x2ba515b7 KEY_RIGHT [...] After loading this with ir-keytable (yes, the number of loaded keysets is matching, so it is loading the new config), syslog is still saying: Apr 3 15:51:33 htpc kernel: [ 548.618452] imon 1-1.6.1:1.0: Configuring IR receiver for iMON protocol Apr 3 15:52:05 htpc kernel: [ 580.768830] intf0 decoded packet: 01 00 00 0e 00 00 00 00 Apr 3 15:52:05 htpc kernel: [ 580.768841] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e Apr 3 15:52:05 htpc kernel: [ 580.808854] intf0 decoded packet: 01 00 00 0e 00 00 00 00 Apr 3 15:52:05 htpc kernel: [ 580.808865] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e Any idea what I might be doing wrong? Thanks! |
From: Jarod W. <ja...@wi...> - 2011-04-06 15:11:28
|
On Apr 4, 2011, at 12:10 PM, cv...@kr... wrote: > On Tue, 29 Mar 2011 16:00:30 -0400, Jarod Wilson wrote: > >>> I'm getting these errors/messages in syslog as well when I use a >>> harmony configured as imon-pad. And the harmony has normal buttons, >>> not this pad. So it seems that, for a better responsiveness, I >>> should add 0x10000f2 and the other codes somehow to lirc. I tried >>> editing the imon-pad keytable and then loading it into the kernel >>> with ir-keytable. But that didn't help, pressing keys still caused >>> the "unknown keypress" messages in syslog. >> Hm. Wonder what the Harmony config is actually doing there as far as >> the signals its sending... > > Don't know, but except for this it's working ok. > >>> How would I need to edit the keytable (or anything else) in order >>> to get the additional 0x10000f2 code recognized? I can then add the >>> other codes as well, and am happy to feed back the result to you, >>> if that helps (others). >> Edit drivers/media/rc/keymaps/rc-imon-pad.c. But pushing the code in >> using ir-keytable *should* work just as well. > > Ok, I tried the latter. Syslog: > > Apr 3 15:44:08 htpc kernel: [ 103.731590] intf0 decoded packet: 01 00 00 0e 00 00 00 00 > Apr 3 15:44:08 htpc kernel: [ 103.731601] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e > Apr 3 15:44:08 htpc kernel: [ 103.771564] intf0 decoded packet: 01 00 00 0e 00 00 00 00 > Apr 3 15:44:08 htpc kernel: [ 103.771574] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e > Apr 3 15:44:08 htpc kernel: [ 103.803599] intf0 decoded packet: 01 00 7f 00 00 00 00 00 > > Then I created a new keytable with the 0x100000e code, based on the imon template: > > [...] > 0x01008000 KEY_UP > 0x10000f2 KEY_UP > 0x01007f00 KEY_DOWN > 0x100000e KEY_DOWN > 0x01000080 KEY_LEFT > 0x100f200 KEY_LEFT > 0x0100007f KEY_RIGHT > 0x1000e00 KEY_RIGHT > 0x2aa515b7 KEY_UP > 0x289515b7 KEY_DOWN > 0x29a515b7 KEY_LEFT > 0x2ba515b7 KEY_RIGHT > [...] > > After loading this with ir-keytable (yes, the number of loaded keysets is matching, so it is loading the new config), syslog is still saying: > > Apr 3 15:51:33 htpc kernel: [ 548.618452] imon 1-1.6.1:1.0: Configuring IR receiver for iMON protocol > Apr 3 15:52:05 htpc kernel: [ 580.768830] intf0 decoded packet: 01 00 00 0e 00 00 00 00 > Apr 3 15:52:05 htpc kernel: [ 580.768841] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e > Apr 3 15:52:05 htpc kernel: [ 580.808854] intf0 decoded packet: 01 00 00 0e 00 00 00 00 > Apr 3 15:52:05 htpc kernel: [ 580.808865] imon 1-1.6.1:1.0: imon_incoming_packet: unknown keypress, code 0x100000e > > Any idea what I might be doing wrong? Yeah, just dawned on me what you're hitting here... There's a lingering issue with ir-keytable... It really only supports 32-bit keycodes at the moment, and those are 64-bit keycodes. Fixing that is on the TODO list, but it ain't done yet. -- Jarod Wilson ja...@wi... |
From: <cv...@kr...> - 2011-04-07 09:54:17
|
On Wed, 6 Apr 2011 11:11:31 -0400, Jarod Wilson wrote: > There's a lingering issue with ir-keytable... It really only supports > 32-bit keycodes at the moment, and those are 64-bit keycodes. Fixing > that > is on the TODO list, but it ain't done yet. Ok... is there any possible workaround, or do I just have to live with this for now? |
From: Stephan R. <mai...@op...> - 2011-04-07 10:21:28
|
Hi, i have two patches to solve this and another issue. Will submit this patches to for including soon: https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/sysutils/v4l-utils/patches/v4l-utils-0.8.3-01-fix_overflow.patch https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/sysutils/v4l-utils/patches/v4l-utils-0.8.3-02-fix_OTHER_protocol.patch Stephan Am 07.04.2011 11:54, schrieb cv...@kr...: > On Wed, 6 Apr 2011 11:11:31 -0400, Jarod Wilson wrote: > >> There's a lingering issue with ir-keytable... It really only supports >> 32-bit keycodes at the moment, and those are 64-bit keycodes. Fixing >> that >> is on the TODO list, but it ain't done yet. > Ok... is there any possible workaround, or do I just have to live with > this for now? > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev |