David Härdeman wrote: > On Sun, Mar 28, 2010 at 09:51:17PM -0300, Mauro Carvalho Chehab wrote: >> I spoke too soon... removing the index causes a problem at the read ioctl: there's no way >> to retrieve just the non-sparsed values. >> >> There's one solution that would allow both read/write and compat to work nicely, >> but the API would become somewhat asymmetrical: >> >> At get (EVIOCGKEYCODEBIG): >> use index/len as input and keycode/scancode as output; >> >> At set (EVIOCSKEYCODEBIG): >> use scancode/keycode/len as input (and, optionally, index as output). >> > > This was exactly the approach I had in mind when I suggested using > indexes. Doesn't work perfectly. The asymmetry has a side effect on the internal logic: EVIOCGKEYCODEBIG should be implemented with a pseudo-code like: kt_entry = getkeycodebig_from_index(index); EVIOCSKEYCODEBIG should be implemented with a pseudo-code like: kt_entry = getkeycodebig_from_scan(scan, len); old_key = kt_entry->keycode; kt_entry->keycode = newkey; if (setkeycodebig(kt_entry) == 0) keyup(old_key); As you see, the input parameters for the getkeycodebig*() are different. So, this approach requires 3 ops instead of 2. Yet, as scancode->keycode is needed anyway, this doesn't actually hurts. I just added the patches that implement those two ioctls on my IR development tree. I tested only the original EVIOCGKEYCODE/EVIOSGKEYCODE and calling a clear_table function using EVIOCSKEYCODEBIG via emulation. My next step is to test the remaining ir-keytable functions via emulation, and then implement the *BIG ioctls at ir-core, for testing. I haven't test yet the *keycode*default methods. After having it fully tested, I'll submit the complete input ioctl patch via ML. -- Cheers, Mauro -- 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
