Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> writes:
>
>> struct input_keytable_entry {
>> u16 index;
>> u64 scancode;
>> u32 keycode;
>> } __attribute__ ((packed));
>>
>> (the attribute packed avoids needing a compat for 64 bits)
>
> Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
> bit better, no alignment problems and we could eventually change
> "reserved" into something useful.
>
> But I think, if we are going to redesign it, we better use scancodes of
> arbitrary length (e.g. protocol-dependent length). It should be opaque
> except for the protocol handler.
Yes, an opaque type for scancode at the userspace API can be better, but
passing a pointer to kernel will require some compat32 logic (as pointer
size is different on 32 and 64 bits).
We may use something like an u8[] with an arbitrary large number of bytes.
In this case, we need to take some care to avoid LSB/MSB troubles.
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
