Mauro Carvalho Chehab <> 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
> 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

> 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
More majordomo info at

Reply via email to