Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Krzysztof Halasa]

Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/