Mauro Carvalho Chehab <mche...@redhat.com> writes:
> All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC
> extended protocol).
> However, currently, the drivers were getting only 7 bits, due to the old way
> to implement
> EVIO[S|G]KEYCODE.
>
> I know, however, one i2c chip that returns a 5 byte scancode when you press a
> key.
> We're currently just discarding the remaining bits, so I'm not really sure
> what's there.
Right. This will have to be investigated by owners of the exact hardware
in question. What we can do is to try to make it easy for them.
There is no hurry, though - it can and will continue to work the current
way.
> In general, the scancode contains 8 or 16 bits for address, and 8 bits for
> command.
Right. I think the kernel shouldn't differentiate between address and
command too much.
> at include/linux/input.h, we'll add a code like:
>
> 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.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
