On 15/09/10 16:58, 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...
This is fine with me, if that matters. However, I'm not sure it could be
a catch-all solution. For example, the five numbered keys on these
Microsoft keyboards put the key number in the value field (rather than
usage->hid). Maybe you could reduce the number of sub-drivers needed by
using the vendor id alone for at least some of the quirks.
Jonathan
--
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
