Re: HID: Allow changing not-yet-mapped usages

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

On Wed, Sep 15, 2010 at 06:51:11PM +1200, Jonathan Conder wrote:
>  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.
> 

Yeah, it obviously won't cover every "interesting" way vendors come up
with... Still should cover some.

-- 
Dmitry