Messages in this thread | | | Date | Thu, 02 Sep 2010 11:28:06 +0200 | From | Jiri Slaby <> | Subject | Re: [PATCH 1/7 v3] HID: magicmouse: don't allow hidinput to initialize the device |
| |
On 09/02/2010 01:57 AM, Michael Poole wrote: > Jiri Slaby wrote: >> This looks weird. Is there any past discussion about why you cannot use >> hidinput and you have to do all the input bits yourself while cheating >> this very weird way? > > The Magic Mouse and Magic Trackpad do not publish HID descriptors for > the multitouch reports. Given the variable-length report packets -- > and especially the Magic Trackpad's new, mutant DOUBLE_REPORT_ID > packets -- it would be non-trivial to write accurate descriptors that > the HID core can use. (Someone wrote a patch to try that a few months > ago. It ended up adding significantly more lines to hid-magicmouse.c > than it removed, and it was not obvious to me that it got the Report > Count fields correct.)
Ok, makes sense. The proper solution is to call a driver hook in hidinput_connect to do the mapping instead of report parsing done there, right? (And not setting [gs]etkeycode in that case.)
Then the part of magicmouse_setup_input starting at the first __set_bit will be exactly the hook.
Otherwise this hack looks like a hard cross-layer breakage.
/me wonders how HID issuers are creative in breaking standards.
regards, -- js
| |