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

Jarod Wilson jarod at wilsonet.com
Fri Jun 24 19:45:13 UTC 2011


On Jun 24, 2011, at 12:53 AM, Gabe Rubin wrote:

> On Thu, Jun 23, 2011 at 8:59 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
>> On Jun 23, 2011, at 11:03 PM, Gabe Rubin wrote:
>> 
>>> 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).
>> 
>> Okay, if some of the keys above *are* working, then in the keymap you
>> load into the kernel, try chopping out the 1e. I swear you should be
>> seeing full codes passed along, rather than just button codes, but if
>> you're getting keycode matches with the 0x00?? scancodes, it must be
>> that only button codes are going through.
>> 
> Maybe I was not being clear.

Nope, it was perfectly clear. Apparently, my reply wasn't. :)

> That output is the default keytable that
> gets loaded.  All the keys in that output are recognized in irw (with
> the exception of the KEY_TV button).  However, those keys are just a
> subset of the keys on my remote.  There are about 15 keys that are not
> on that list nor are they recognized by irw (cal those keys the
> "Missing Keys").  With the exception of KEY_TV, none of the Missing
> Keys (the keys irw does not recognize) is in that list.
> 
> However, my file /etc/rc_keymaps/haupp contains codes for every one of
> the keys on my remote and each of those codes corresponds to the hex
> figure for the device (30 -> 0x1e) and code as confirmed by looking at
> dmesg.  You had told me to use dmesg output in a prior email in this
> chain; however, I did not need to edit that file at all, it was
> installed with those codes already in it.

Yeah, but in my prior reply, what I meant to say was "try replacing 0x1e
with 0x00, load that, and see if they all work now".


-- 
Jarod Wilson
jarod at wilsonet.com





More information about the mythtv-users mailing list