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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 06 Dec 2009 21:19:06 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Gerd Hoffmann <kraxel@...hat.com>,
	Jarod Wilson <jarod@...sonet.com>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jonsmirl@...il.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR  system?

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