On 02.10.2013 15:59, David Herrmann wrote: >>> Or maybe even replace it by "u32 angle;". That should always be safe. >>> Once you make use of this field, you can reconsider whether it's worth >>> doing FP in the kernel. But as long as it's unused, I'd vote for >>> avoiding "float" entirely. >> >> I was indeed planning to use this for orientation (as intended) in the >> next iteration, what macros would I have to use for proper float handling? > > Archived from 2003 but afaik his last paragraph still applies today: > http://yarchive.net/comp/linux/kernel_fp.html > > So what you should do is forward the raw angle data to user-space and > let them deal with it. We usually don't apply policy in the kernel but > instead forward the given data to the user and let them do the > orientation computations. Any specific reason why you want to do that > in the kernel? I think it would be more consistent to have an EV_ABS value for orientation, ranging e.g. from 0 to 359 (or rather from 0 to e.g. 90, as described in multi-touch-protocol.txt). For pass-through to work, I would probably have to set min and max to 0 and __UINT32_MAX__? Alternatively, I think it should be possible to perform the required conversion using integer arithmetic and bit operations alone. However, for the time being, I'd suggest to simply leave the float alone, use just a 0/1 value for orientation and deal with this in a later patch, agreed? One additional question: is there any provision in the multitouch protocol for differentiation between various types of objects, e.g. "finger" and "palm"? BTW, what's the best practice for resubmitting a patch? I've used "git commit --amend" on my previous commit, and would now just use "git send-email" again, creating a new thread? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL
Attachment:
signature.asc
Description: OpenPGP digital signature
