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 -- 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
