On Sun, Jul 12, 2009 at 06:20:26PM +0200, Bruno Prémont wrote: > On Thu, 16 April 2009 Jiri Kosina <jkosina@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
