Re: imon, ir-keytable, imon_pad, unknown keypress handling, additional scancodes

[Jarod W. <ja...@wi...>]

On Apr 30, 2011, at 12:53 PM, Leho Kraav wrote:

> Hi
> 
> (This is a subscribed resend. Sending this unsubscribed gave me "admin 
> must approve message" and now nothing has happened for two days.)
> 
> This is to continue on topic of 
> http://sourceforge.net/mailarchive/message.php?msg_id=27241663.
> 
> I'm running into the same thing as OP there, with a couple of 
> differences I guess.
> 
> $ sudo lsusb | grep 15c2
> Bus 006 Device 002: ID 15c2:0038 SoundGraph Inc. GD01 MX VFD Display/IR 
> Receiver
> 
> $ ir-keytable --version
> IR keytable control version 0.8.3
> 
> $ uname -r
> 2.6.38-gentoo-r3
> 
> 1. udev rules don't seem to set my keymap up correctly
> 
> Apr 28 14:05:32 udevd-work[17065]: RUN '/usr/bin/ir-keytable -a 
> /etc/rc_maps.cfg -s $name' /lib/udev/rules.d/70-infrared.rules:6
> Apr 28 14:05:32 udevd-work[17065]: '/usr/bin/ir-keytable -a 
> /etc/rc_maps.cfg -s rc0' started
> Apr 28 14:05:32 udevd-work[17065]: '/usr/bin/ir-keytable -a 
> /etc/rc_maps.cfg -s rc0' returned with exitcode 0
> 
> But then ir-keytable -r only returns a single registered keycode: KEY_COFFEE
> 
> When I manually do:
> 
> $ sudo ir-keytable -w /etc/rc_keymaps/imon_pad
> 
> keymap is loaded correctly.
> 
> Now that I am writing this, I'm thinking this might be because I did not 
> compile rc-imon-pad, because there is no way ("yet" hopefully) to single 
> it out.

Yep, that would do it. Don't do that. :)


> So rc_maps.cfg line doesn't match:
> 
> *       rc-imon-pad              imon_pad
> 
> Should it be just "imon" instead:
> 
> *       imon              imon_pad
> 
> Setting the driver "imon" does not help:
> 
> imon       rc-imon-pad              imon_pad

In reading the comments in rc_maps.cfg, it looks like what you
want is:

imon    *    imon_pad

Its driver, table name, keymap file. You have no keymap loaded (or
rather, the default empty one you get when you don't build the
keymaps), so you don't want to match "imon" or "rc-imon-pad" for
keymap.


> 2. Since I can load keytables manually, I can see I basically don't need 
> LIRC at all anymore, since remote becomes a keyboard, which is awesome.

Well, there's still the problem of X being a steaming pile, and not
passing along any keycodes > 255, so you still need something to
remap keycodes > 255 if you want to be able to use them. You can do
that either with lirc or with a custom keymap.


> Now I still have a problem with unrecognized scancodes spamming my 
> syslog like the OP mentioned. Jared responded that it is an issue with 
> 32-bit vs 64-bit keycodes.

Hrm. These are all 32-bit keycodes, so it *should* be okay, but...
I'd have to experiment with my own imon stuff, but I'm short on time
to do that right now.


> Putting these into imon_pad doesn't do anything for me.
> 
> +0x010000f2 KEY_UP
> +0x01000e00 KEY_RIGHT
> +0x0100000e KEY_DOWN
> +0x0100f200 KEY_LEFT
> 
> Should they?

Probably.


> 3. imon debug=1 codes that doesn't seem to be handled at all for now
> 
> Timer
> Apr 28 16:21:00 vmr45 kernel: [61560.699740] intf1 decoded packet: 2b 83 
> 95 b7 00 00 02 01
> Apr 28 16:21:00 vmr45 kernel: [61560.747672] intf1 decoded packet: 2b 83 
> d5 b7 00 00 02 01

KEY_TIME, its mapped in the imon pad keymap...

> Task Switcher
> Apr 28 16:21:38 vmr45 kernel: [61598.696736] intf1 decoded packet: 2a 93 
> 95 b7 00 00 02 01
> Apr 28 16:21:38 vmr45 kernel: [61598.800726] intf1 decoded packet: 2a 93 
> d5 b7 00 00 02 01

KEY_CYCLEWINDOWS, its mapped...


> go
> Apr 28 16:21:57 vmr45 kernel: [61617.747209] intf1 decoded packet: 2a b1 
> 95 b7 00 00 02 01
> Apr 28 16:21:57 vmr45 kernel: [61617.803166] intf1 decoded packet: 2a b1 
> d5 b7 00 00 02 01

KEY_MEDIA


> App Launcher
> Apr 28 16:22:11 vmr45 kernel: [61631.225629] intf1 decoded packet: 29 b7 
> 15 b7 00 00 02 01
> Apr 28 16:22:11 vmr45 kernel: [61631.297572] intf1 decoded packet: 29 b7 
> 55 b7 00 00 02 01

KEY_DASHBOARD


> Mid-Eject
> Apr 28 16:22:36 vmr45 kernel: [61656.111939] intf1 decoded packet: 29 93 
> 95 b7 00 00 02 01
> Apr 28 16:22:36 vmr45 kernel: [61656.199874] intf1 decoded packet: 29 93 
> d5 b7 00 00 02 01

KEY_EJECTCLOSECD

<snip>

These all appear to be mapped. Not quite sure where things are falling
down. Can you try building your kernel with the keymaps, see if it
works better then? (They're all tiny modules, most of which won't load,
all they do is use a smidgen of disk space, there's really no reason
not to build them unless you're doing embedded systems work, imo...)

-- 
Jarod Wilson
ja...@wi...