Messages in this thread | | | Date | Mon, 07 Dec 2009 22:00:20 -0200 | From | Mauro Carvalho Chehab <> | Subject | Re: [RFC] What are the goals for the architecture of an in-kernel IR system? |
| |
Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab@redhat.com> 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.
| |