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@xxxxxxxxx> > > 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 <dtor@xxxxxxx> Seems like a very good idea to me, code looks sane. Acked-by: Jarod Wilson <jarod@xxxxxxxxxx> -- Jarod Wilson jarod@xxxxxxxxxx -- 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
