On Tue, Sep 14, 2010 at 09:58:22PM -0700, Dmitry Torokhov wrote:

Jiri,

Currently HID only allows re-mapping of usages that have already been
mapped by hid-input or one of the sub-drivers as keys. This,
unfortunately, leads to sub-drivers multiplying by the hour and many
of them only do initial setup of usages and waste memory once that is
done.

How about we also allow EVIOCSKEYCODE to establish mapping for
not-yet-unmapped usages (usage->type == 0)? Then we could offload the
task of setting up keymaps to udev.

This depends on the large keycode handling patches that are in my tree
in 'next' branch. Not tested past booting...

-- 
Dmitry

Input: hid-input - allow mapping unknown usages

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Currently HID layer only allows to remap keycodes for known usages,
and responds with -EINVAL when user tries to map new usage code.
This precludes us form relying on udev/keymap for establishing correct
mappings and forces us to write dummy HID drivers responsible only for
setting up keymaps.

Let's allow remapping not only usages that have been set up as keys
(usage->type == EV_KEY) but also yet-unmapped usages (usage->type == 0).

Signed-off-by: Dmitry Torokhov <redacted>

Seems like a very good idea to me, code looks sane.

Acked-by: Jarod Wilson <redacted>

-- 
Jarod Wilson
jarod@redhat.com