Mauro Carvalho Chehab wrote:

Dmitry Torokhov wrote:

[scancode-to-keycode map size]

quoted

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/