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

[Gabe Rubin]

On Fri, Jun 24, 2011 at 12:45 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
> 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".
>

Right, I understood your reply and will try loading that.  However, I
am concerned because if I do that, some of the keys wont be proper
like in one of the examples I gave:(KEY_CHANNEL in the keytable loaded
by default is 0x0022 and in the /etc/rc_keymaps/haupp keytable
0x1e12).  If I do that for KEY_CHANNEL in the haupp keytable, it will
be 0x0012, but in the default keytable, that is scancode 0x0012 =
KEY_BRIGHTNESSUP (0xe1)

I guess I can just change all of these and adjust the key names in the
haupp file.  If that works, so be it.  Once I get all the keys
working, I will bother you to find out how to have that keymap loaded
by default.  I am also wondering if things will screw up when I
eventually upgrade to F15 or a later kernel in F14 as you seemed so
surprised by these results (i.e., I am fixing things for a broken
configuration that won't work when I have a "proper" configuration)?