[mythtv-users] Using devinput but devinput lircd.conf file does not contain all my remote buttons on Harmony One

Gabe Rubin gaberubin at gmail.com
Fri Jun 24 03:03:29 UTC 2011


On Mon, Jun 20, 2011 at 10:35 AM, Jarod Wilson <jarod at wilsonet.com> wrote:
> On Jun 14, 2011, at 10:42 PM, Gabe Rubin wrote:
>
>> On Thu, Jun 9, 2011 at 9:03 AM, Jarod Wilson <jarod at wilsonet.com> wrote:
>>>
>>> Hrm. What does 'ir-keytable' without any args spit back?
>>>
>>
>> [root at localhost ~]# ir-keytable
>> Found /sys/class/rc/rc1/ (/dev/input/event2) with:
>>        Driver ir-kbd-i2c, table rc-rc5-tv
>>        Supported protocols: RC-5
>>        Enabled protocols:
>>        Repeat delay = 500 ms, repeat period = 33 ms
>
> Completely and totally NOT the keytable I was expecting, and that
> probably explains some things... This one was, iirc, merged into the
> hauppauge one after 2.6.38 or so...
>
> So *before* loading a new keytable, try:
>
> ir-keytable -s rc1 -r
>
> The -s can be used to select non-rc0 devices. The -r says "read the
> currently loaded keytable". I'm now wondering if that keytable uses
> full rc5 codes (device + button) or just the button codes...
>
>
This is what I get (using kernel version : 2.6.35.12-88.fc14.i686)
[root at localhost ~]# ir-keytable -r
scancode 0x0000 = KEY_0 (0x0b)
scancode 0x0001 = KEY_1 (0x02)
scancode 0x0002 = KEY_2 (0x03)
scancode 0x0003 = KEY_3 (0x04)
scancode 0x0004 = KEY_4 (0x05)
scancode 0x0005 = KEY_5 (0x06)
scancode 0x0006 = KEY_6 (0x07)
scancode 0x0007 = KEY_7 (0x08)
scancode 0x0008 = KEY_8 (0x09)
scancode 0x0009 = KEY_9 (0x0a)
scancode 0x000b = KEY_CHANNEL (0x16b)
scancode 0x000c = KEY_POWER (0x74)
scancode 0x000d = KEY_MUTE (0x71)
scancode 0x000f = KEY_TV (0x179)
scancode 0x0010 = KEY_VOLUMEUP (0x73)
scancode 0x0011 = KEY_VOLUMEDOWN (0x72)
scancode 0x0012 = KEY_BRIGHTNESSUP (0xe1)
scancode 0x0013 = KEY_BRIGHTNESSDOWN (0xe0)
scancode 0x001e = KEY_SEARCH (0xd9)
scancode 0x0020 = KEY_CHANNELUP (0x192)
scancode 0x0021 = KEY_CHANNELDOWN (0x193)
scancode 0x0022 = KEY_CHANNEL (0x16b)
scancode 0x0023 = KEY_LANGUAGE (0x170)
scancode 0x0026 = KEY_SLEEP (0x8e)
scancode 0x002e = KEY_MENU (0x8b)
scancode 0x0030 = KEY_PAUSE (0x77)
scancode 0x0032 = KEY_REWIND (0xa8)
scancode 0x0033 = KEY_GOTO (0x162)
scancode 0x0035 = KEY_PLAY (0xcf)
scancode 0x0036 = KEY_STOP (0x80)
scancode 0x0037 = KEY_RECORD (0xa7)
scancode 0x003c = KEY_TEXT (0x184)
scancode 0x003d = KEY_SUSPEND (0xcd)

Not surprisingly, none of the buttons that irw doesn't recognizes is
is in that output (with the exception KEY_TV, which irw does not
recognize but is in the above output).

When I clear the keytable and load the haupp keytable and try to read
it, here is the output:
scancode 0x1e00 = KEY_0 (0x0b)
scancode 0x1e01 = KEY_1 (0x02)
scancode 0x1e02 = KEY_2 (0x03)
scancode 0x1e03 = KEY_3 (0x04)
scancode 0x1e04 = KEY_4 (0x05)
scancode 0x1e05 = KEY_5 (0x06)
scancode 0x1e06 = KEY_6 (0x07)
scancode 0x1e07 = KEY_7 (0x08)
scancode 0x1e08 = KEY_8 (0x09)
scancode 0x1e09 = KEY_9 (0x0a)
scancode 0x1e0a = KEY_KPASTERISK (0x37)
scancode 0x1e0b = KEY_RED (0x18e)
scancode 0x1e0c = KEY_RADIO (0x181)
scancode 0x1e0d = KEY_MENU (0x8b)
scancode 0x1e0e = KEY_GRAVE (0x29)
scancode 0x1e0f = KEY_MUTE (0x71)
scancode 0x1e10 = KEY_VOLUMEUP (0x73)
scancode 0x1e11 = KEY_VOLUMEDOWN (0x72)
scancode 0x1e12 = KEY_CHANNEL (0x16b)
scancode 0x1e14 = KEY_UP (0x67)
scancode 0x1e15 = KEY_DOWN (0x6c)
scancode 0x1e16 = KEY_LEFT (0x69)
scancode 0x1e17 = KEY_RIGHT (0x6a)
scancode 0x1e18 = KEY_VIDEO (0x189)
scancode 0x1e19 = KEY_AUDIO (0x188)
scancode 0x1e1a = KEY_MEDIA (0xe2)
scancode 0x1e1b = KEY_EPG (0x16d)
scancode 0x1e1c = KEY_TV (0x179)
scancode 0x1e1e = KEY_NEXT (0x197)
scancode 0x1e1f = KEY_BACK (0x9e)
scancode 0x1e20 = KEY_CHANNELUP (0x192)
scancode 0x1e21 = KEY_CHANNELDOWN (0x193)
scancode 0x1e24 = KEY_LAST (0x195)
scancode 0x1e25 = KEY_OK (0x160)
scancode 0x1e29 = KEY_BLUE (0x191)
scancode 0x1e2e = KEY_GREEN (0x18f)
scancode 0x1e30 = KEY_PAUSE (0x77)
scancode 0x1e32 = KEY_REWIND (0xa8)
scancode 0x1e34 = KEY_FASTFORWARD (0xd0)
scancode 0x1e35 = KEY_PLAY (0xcf)
scancode 0x1e36 = KEY_STOP (0x80)
scancode 0x1e37 = KEY_RECORD (0xa7)
scancode 0x1e38 = KEY_YELLOW (0x190)
scancode 0x1e3b = KEY_GOTO (0x162)
scancode 0x1e3d = KEY_POWER (0x74)


So I assume there is something wrong in my /etc/rc_keymaps/haupp file
(again, when I load that keytable explicitly, no keypresses are
recognized).  The scancodes in the haupp file also match up with the
dmesg output (based on the syntax and conversion you discussed
earlier) and in any event, I never modified that file.  I am happy to
edit the haupp file and can obviously do that for the keys that are in
the keytable that automatically loads; however I don't know what the
proper scancode is for the missing buttons (it does not seem to follow
a pattern I can easily detect).

Incidentally, when I read the keytable in the older kernel (version:
2.6.35.10-74.fc14.i686) I get this output:
[root at localhost ~]#  ir-keytable -r
scancode 0x0000 = KEY_0 (0x0b)
scancode 0x0001 = KEY_1 (0x02)
scancode 0x0002 = KEY_2 (0x03)
scancode 0x0003 = KEY_3 (0x04)
scancode 0x0004 = KEY_4 (0x05)
scancode 0x0005 = KEY_5 (0x06)
scancode 0x0006 = KEY_6 (0x07)
scancode 0x0007 = KEY_7 (0x08)
scancode 0x0008 = KEY_8 (0x09)
scancode 0x0009 = KEY_9 (0x0a)
EVIOCGKEYCODE: Invalid argument
scancode 0x000b = KEY_CHANNEL (0x16b)
scancode 0x000c = KEY_POWER (0x74)
scancode 0x000d = KEY_MUTE (0x71)
EVIOCGKEYCODE: Invalid argument
scancode 0x000f = KEY_TV (0x179)
scancode 0x0010 = KEY_VOLUMEUP (0x73)
scancode 0x0011 = KEY_VOLUMEDOWN (0x72)
scancode 0x0012 = KEY_BRIGHTNESSUP (0xe1)
scancode 0x0013 = KEY_BRIGHTNESSDOWN (0xe0)
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
scancode 0x001e = KEY_SEARCH (0xd9)
EVIOCGKEYCODE: Invalid argument
scancode 0x0020 = KEY_CHANNELUP (0x192)
scancode 0x0021 = KEY_CHANNELDOWN (0x193)
scancode 0x0022 = KEY_CHANNEL (0x16b)
scancode 0x0023 = KEY_LANGUAGE (0x170)
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
scancode 0x0026 = KEY_SLEEP (0x8e)
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
scancode 0x002e = KEY_MENU (0x8b)
EVIOCGKEYCODE: Invalid argument
scancode 0x0030 = KEY_PAUSE (0x77)
EVIOCGKEYCODE: Invalid argument
scancode 0x0032 = KEY_REWIND (0xa8)
scancode 0x0033 = KEY_GOTO (0x162)
EVIOCGKEYCODE: Invalid argument
scancode 0x0035 = KEY_PLAY (0xcf)
scancode 0x0036 = KEY_STOP (0x80)
scancode 0x0037 = KEY_RECORD (0xa7)
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
EVIOCGKEYCODE: Invalid argument
scancode 0x003c = KEY_TEXT (0x184)
scancode 0x003d = KEY_SUSPEND (0xcd)
EVIOCGKEYCODE: Invalid argument

And then EVIOCGKEYCODE: Invalid argument repeats a lot.

I fell like I am getting real close here.  Just need to get a complete
and correct keytable.

>>> Interestingly, it doesn't seem there's a rule that would actually
>>> load the haupp table in there. Providing a line to add will be easier
>>> after seeing the ir-keytable no-args output though.
>>
>> Does the info I put up above help with creating a rule I can add?  I
>> am not even certain that a rule would help though.  I rebooted using a
>> more recent kernel (2.6.35.12-88.fc14.i686) and tried loading the
>> specific haupp keytable but when I do that, irw recognizes no keys.
>
> Hrm. That's surprising. Does 'ir-keytable -t -s rc1' behave entirely
> silent as well?
>
>
>> This is what I did:
>>
>> When I do this, I get the following output:
>> [root at localhost ~]#  ir-keytable -c -w /etc/rc_keymaps/haupp
>> Old keytable cleared
>> Wrote 46 keycode(s) to driver
>>
>> If I unload and reload the ir-kbd-i2c module, irw will recognize the
>> same keys it did when I originally loaded the module and not recognize
>> the same keys it didn't recognize before (but dmesg is showing me that
>> the system is recognizing all the keys).  Of course, if I try to load
>> a keytable at that point, I get the error "Not found device rc0"
>> because I have loaded it previously and as you noted, the rc device
>> moved to rc1 instead of rc0.
>
> Yeah, ir-keytable -s rcX to tinker with non-rc0 devices. The utility could
> and should be extended to try to find the first device and always operate
> on it if no device is specified...
>
> --
> Jarod Wilson
> jarod at wilsonet.com
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>


More information about the mythtv-users mailing list