[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
Wed Jun 8 21:15:41 UTC 2011


On Wed, Jun 8, 2011 at 2:09 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
> On Jun 8, 2011, at 2:29 PM, Gabe Rubin wrote:
>
>> On Wed, Jun 8, 2011 at 11:22 AM, Jarod Wilson <jarod at wilsonet.com> wrote:
>>> On Jun 8, 2011, at 2:01 PM, Gabe Rubin wrote:
>>>
>>>> On Wed, Jun 8, 2011 at 10:48 AM, Jarod Wilson <jarod at wilsonet.com> wrote:
>>>>> On Jun 8, 2011, at 1:09 AM, Gabe Rubin wrote:
>>>>>
>>>>>> On Tue, Jun 7, 2011 at 9:14 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
>>>>>>> On Jun 7, 2011, at 6:03 PM, Gabe Rubin wrote:
>>> ...
>>>>>>>>>> I just realized, there are also 5 buttons on the remote's touchscreen
>>>>>>>>>> that shows up in demsg but not irw.  Here is the output in dmesg for
>>>>>>>>>> those:
>>>>>>>>>>
>>>>>>>>>> [936592.054938] ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=28
>>>>>>>>>> [936612.056075] ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=24
>>>>>>>>>> [936624.269950] ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=26
>>>>>>>>>> [936632.776960] ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=14
>>>>>>>>>> [936641.785956] ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=25
>>>>>>>>>
>>>>>>>>> Okay, if you haven't already, yum install v4l-utils, then edit /etc/rc_keymaps/haupp,
>>>>>>>>> and add 0x30xx KEY_WHATEVER lines for each of those keys (where "WHATEVER" needs to
>>>>>>>>> line up with key names in /usr/include/linux/input.h and the devinput lircd.conf),
>>>>>>>>> then run 'ir-keytable -a', and I *think* you should be good to go. That will tell
>>>>>>>>> ir-keytable to upload the modified/extended keytable into the kernel for ir-kbd-i2c
>>>>>>>>> to use for scancode to keycode mapping.
>>>>>>>>
>>>>>>>> OK, so to confirm that I am doing this correctly, I should look in
>>>>>>>> /usr/include/linux/input.h to find out what the KEY_WHATEVER name is
>>>>>>>> and then edit /etc/rc_keymaps/haupp to add that.  For example, they
>>>>>>>> key that generates a code of 28 in dmesg, I see in the input.h file
>>>>>>>> that:
>>>>>>>> #define KEY_ENTER               28
>>>>>>>
>>>>>>> The code from the remote and the defines in input.h aren't in any way directly
>>>>>>> related. If the button that generates code 28 is rewind, map it to KEY_REWIND.
>>>>>>>
>>>>>>> However... I just realized that I missed a conversion step. 30 is base 10, the
>>>>>>> values in the config are hex. 30 -> 0x1e. Same decimal to hex conversion needs
>>>>>>> to be done for the code values as well.
>>>>>>>
>>>>>>>
>>>>>>>> So I should enter 0x30xx KEY_ENTER in the haupp file?  (are the xx in
>>>>>>>> that line variables or should it read exactly that?)
>>>>>>>
>>>>>>> 'dev=30 code=28' in dmesg for the button labeled rewind -> '0x1e1c KEY_REWIND'
>>>>>>> in the haupp file.
>>>>>>
>>>>>>
>>>>>> OK, I converted the values for the 16 keys to hexidecimal.  I am not
>>>>>> sure about dev=30 code=14 (is that 0x1e0e?).
>>>>>
>>>>> Yes, that's correct.
>>>>>
>>>>>> It turns out that all
>>>>>> are already in haupp file (with the exception of dev=30 code=14,
>>>>>> unless that is 0x1e0e).
>>>>>
>>>>> You sure? The haupp file I'm looking at over here only has 0x1fxx
>>>>> variants of the keys. Should be expanded in v4l-utils 0.8.4, I believe,
>>>>> but what I'm looking at is from what I believe is the current latest
>>>>> package in fedora 15... (There was a bit of churn with the hauppauge
>>>>> config files, as there were several different ones, all actually more
>>>>> or less the same, but some with device in the scancode, some without,
>>>>> and they're finally merged together in the latest v4l/dvb code).
>>>>>
>>>>
>>>> Pretty sure.  I just copied /etc/rc_keymaps/haupp to my webdirectory.
>>>> Look here: http://mustbethemoney.mine.nu:8080/haupp.txt
>>>> Those all appear to me to be 0x1exx variants.  So I am confused (and
>>>> some of the keys show up in irw, some don't).
>>>
>>> Huh. Now I'm not quite sure what the heck is going on... One thing that
>>> does need to be fixed in that table though, is 'type: UNKNOWN' should
>>> be 'type: RC-5'.
>>>
>>>
>>>> I am using F14 and v4l-utils-0.8.3-2.fc14.i686.
>>>
>>> Bizarre. Seems to have slightly different table files than the package
>>> with the same nvr for fedora 15.
>>>
>>>
>>>>>> So I am not sure why I don't see those when I
>>>>>> run irw.  Do I need to execute "ir-keytables -a first even though I
>>>>>> made no changes?  If so, what is the exact syntaxt, because I get
>>>>>> errors when I run that command:
>>>>>> [root at localhost lirc]# ir-keytable -a /etc/rc_keymaps/haupp
>>>>>
>>>>> Just 'ir-keyable -a', nothing else. Its supposed to use /etc/rc_maps.cfg
>>>>> to auto-determine which keytable file to upload. You can also try an
>>>>> explicit 'ir-keytable -c -w /etc/rc_keymaps/haupp'.
>>>>>
>>>>
>>>> When I try just ir-keytable -a, here is what happens (have not tried
>>>> ir-keytable -c -w /etc/rc_keymaps/haupp yet as I am not in front of
>>>> the computer and would not be able to test the remote at this point):
>>>> [root at localhost ~]# ir-keytable -a
>>>> ir-keytable: option requires an argument -- 'a'
>>>> Try `ir-keytable --help' or `ir-keytable --usage' for more information.
>>>
>>> Sorry, I'm an idjit. It is indeed supposed to be
>>> 'ir-keytable -a /etc/rc_keymaps.cfg', which you've tried, and got an
>>> error from... I wonder if setting UNKNOWN to RC-5 will get you past
>>> that...
>>>
>> Actually, I was trying ir-keytable -a /etc/rc_keymaps/haupp
>> When I try ir-keytable -a /etc/rc_maps.cfg I get the following error:
>> Couldn't find any node at /sys/class/rc/rc*.
>>
>> I do not have the ir-kbd-i2c module loaded right now though, so maybe
>> that is the issue.
>
> Yeah, module has to be loaded, or there's no rc device for ir-keytable
> to upload the keytable into.
>
>
>> I will also try changing the UNKNOWN to RC-5.
>> When exactly do I need to execute the command?  With the lirc service
>> off?  With the correct module loaded?  At any time?  And do I need to
>> do it on each reboot?
>
> In theory, the udev rule should trigger automatically after you load
> up the ir-kbd-i2c module, but maybe its not enabled in F14... In which
> case, you'd want to modprobe ir-kbd-i2c, then run ir-keytable, from
> somewhere such as /etc/sysconfig/modules/lirc.modules. (There's no
> auto-loading of ir-kbd-i2c, so it has to be loaded by hand before there
> is anything for ir-keytable and/or lirc to talk to).
>
>
>> Still not understanding why some keys that are mapped in that haupp
>> file show up in irw when I have the right module loaded but others
>> don't.
>
> That file doesn't necessarily match what's actually in the kernel.
> After loading ir-kbd-i2c, ir-keytable -r will dump the keytable that
> is actually present in the kernel.
>

Thanks.  I will try this.  Either tonight or next week when I have
free time.  Is there a way to automate this on boot up once I confirm
everything works?

As an aside, why did support for lirc_i2c get dropped?  I do
appreciate all the work that has gone into lirc, but it seems like a
huge hassle when things were working before.  As a result, I am still
using an older kernel until I get things working (but I am sure I will
get things working soon and don't want this to sound like a
complaint).


More information about the mythtv-users mailing list