Messages in this thread | | | Date | Wed, 31 Mar 2010 03:01:56 -0300 | From | Mauro Carvalho Chehab <> | Subject | Re: [RFC] What are the goals for the architecture of an in-kernel IR system? |
| |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |