Re: Input driver for Twinhan USB 6253:0100 remote control

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Sun, Jul 12, 2009 at 06:20:26PM +0200, Bruno Prémont wrote:
> On Thu, 16 April 2009 Jiri Kosina <jkosina@suse.cz> wrote:
> > On Wed, 15 Apr 2009, Mark Lord wrote:
> > > > Yes, hid-belking is a good example of trivial driver that sits on
> > > > a HID bus for you, as it utilizes the ->input_mapping() callback,
> > > > which is probably the only callback from HID core you'd need.
> > > Actually, the input-mapping() alone won't do the job here.
> > > This Twinhan remote control sends single-byte codes for most
> > > buttons, but some buttons send multi-byte codes, and we have to
> > > discard the extraneous bytes somehow.
> > 
> > If the usages make it through the generic HID layer (depends on the
> > report descriptor of the device), then just registering hid_driver
> > with ->event() set to your callback and fixing this on the fly could
> > be enough.
> 
> I do have such a remote around.
> 
> I wrote the below patch to adjust it's key mappings, though I'm not
> sure if/how I should deal with the number keys (0..9) with regard to
> keyboard layout and/or numlock key.
> 
> I tried with KEY_0..KEY_9 (default) as well as KEY_KP0..KEY_KP9 but
> neither produces optimal results on my machine (laptop with numlock
> disabled and belgian keyboard layout, e.g. KEY_1 => '&' unless shift
> is down)
> i

That was the reason KEY_NUMERIC_* keycodes were intriduced - they
shuppsed to be unaffected by labuguage keymap or numlock state.

> KEY_NUMERIC_0..KEY_NUMERIC_9 are not recognized by Linux console (don't
> know if/how userspace understands them)
> 

They just probably missing from the installed keymap, that's all.

-- 
Dmitry