On Sun, Jul 12, 2009 at 06:20:26PM +0200, Bruno Prémont wrote:

On Thu, 16 April 2009 Jiri Kosina [off-list ref] wrote:

quoted

On Wed, 15 Apr 2009, Mark Lord wrote:

quoted

quoted

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