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

[Jarod Wilson]

On Jun 24, 2011, at 3:51 PM, Gabe Rubin wrote:

> 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.

Yep! :)


> 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)?

Not sure about Fedora 14 anymore. I thought it had a sufficiently new
enough ir-kbd-i2c, but it appears not. It'll be different with the F15
kernel, the default keytable *should* work out of the box, if I'm
thinking clearly. I'm actually running mostly locally git-built 3.0-rc
kernels myself right now, so my view of reality is skewed. :)

-- 
Jarod Wilson
jarod at wilsonet.com