Hi Florian
On Wed, Oct 2, 2013 at 10:01 AM, Florian Echtler <floe@xxxxxxxxxxxxxx> wrote:
>>> +struct sur40_blob {
>>> +
>>> + uint16_t blob_id;
>>> +
>>> + uint8_t action; /* 0x02 = enter/exit, 0x03 = update (?) */
>>> + uint8_t unknown; /* always 0x01 or 0x02 (no idea what this is?) */
>>> +
>>> + uint16_t bb_pos_x; /* upper left corner of bounding box */
>>> + uint16_t bb_pos_y;
>>> +
>>> + uint16_t bb_size_x; /* size of bounding box */
>>> + uint16_t bb_size_y;
>>> +
>>> + uint16_t pos_x; /* finger tip position */
>>> + uint16_t pos_y;
>>> +
>>> + uint16_t ctr_x; /* centroid position */
>>> + uint16_t ctr_y;
>>> +
>>> + uint16_t axis_x; /* somehow related to major/minor axis, mostly: */
>>> + uint16_t axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
>>> +
>>> + float angle; /* orientation in radians relative to x axis */
>>
>> float is unusual in the kernel - is it actually ieee 754 encoded?
>
> Yes - was also surprised to see this directly from the hardware.
How about renaming this to "__angle" or "angle_dont_use" or something
like that. Thing is, we don't restore FP registers in the kernel so if
there's a float somewhere around, we should never access it as float
(who knows what the compiler generates..). There might be FP macros to
save/restore the registers, but I haven't seen them used.
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.
Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
