Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: [scancode-to-keycode map size] >> Hmm, why can't you just resize it when you get EVIOCSKEYCODE for >> scancode that would be out of bounds for the current table (if using >> table approach)? [...] > Let's suppose, for example that instead of using a 49 keys > IR, they want to use some programable IR with 55 keys, with different > scancodes. This means that they'll need to delete all 49 scancodes from the old IR > and add 55 new scancodes. As there's no explicit call to delete a scan code, the solution > I found with the current API is to read the current scancode table and replace them with > KEY_UNKNOWN, allowing its re-use (this is what the driver currently does) or deleting > that scancode from the table. After deleting 49 keys, you'll need to add the 55 new keys. > If we do dynamic table resize for each operation, we'll do 104 sequences of kmalloc/kfree > for replacing one table. It is not a performance sensitive task, is it? If you can trade ABI simplicity for performance (which shouldn't actually matter), that'd be a better deal. Besides, some of the necessary kernel-internal house-keeping can also be deferred until close(). > IMO, it would be better to have an ioctl to do the keycode table resize. An optional flag > at the ioctl (or a separate one) can be used to ask the driver to clean the current > keymap table and allocate a new one with the specified size. > This will avoid playing with memory allocation for every new key and will provide a simple > way to say to the driver to discard the current keybable, since a new one will be used. OTOH, an additional "forget all current mappings" ioctl sounds like an ABI simplification. -- Stefan Richter -=====-==--= =-== ===-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
