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]

Message-ID: <20100326112755.GB5387@hardeman.nu>
Date:	Fri, 26 Mar 2010 12:27:55 +0100
From:	David Härdeman <david@...deman.nu>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Jon Smirl <jonsmirl@...il.com>, Pavel Machek <pavel@....cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	hermann pitton <hermann-pitton@...or.de>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
	kraxel@...hat.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?

On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
> >        10) extend keycode table replacement to support big/variable 
> >        sized scancodes;
> 
> Pending.
> 
> The current limit here is the scancode ioctl's are defined as:
> 
> #define EVIOCGKEYCODE           _IOR('E', 0x04, int[2])                 /* get keycode */
> #define EVIOCSKEYCODE           _IOW('E', 0x04, int[2])                 /* set keycode */
> 
> As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes, associated
> with a keycode, there's not enough bits there for IR.
> 
> The better approach seems to create an struct with an arbitrary long size, like:
> 
> struct keycode_table_entry {
> 	unsigned keycode;
> 	char scancode[32];	/* 32 is just an arbitrary long array - maybe shorter */
> 	int len;
> }
>
> and re-define the ioctls. For example we might be doing:
> 
> #define EVIOCGKEYCODEBIG           _IOR('E', 0x04, struct keycode_table_entry)
> #define EVIOCSKEYCODEBIG           _IOW('E', 0x04, struct keycode_table_entry)
> #define EVIOCLEARKEYCODEBIG        _IOR('E', 0x04, void)
> 
> Provided that the size for struct keycode_table_entry is different, _IO will generate
> a different magic number for those.
> 
> Or, instead of using 0x04, just use another sequential number at the 'E' namespace.
> 
> An specific function to clear the table is needed with big scancode space,
> as already discussed.
> 

I'd suggest:

struct keycode_table_entry {
	unsigned keycode;
	unsigned index;
	unsigned len;
	char scancode[];
};

Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are 
ignored), that way no special function to clear the table is necessary, 
instead you do a loop with:

EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
		  keycode = KEY_RESERVED)

until EVIOCGKEYCODEBIG returns an error.

This also allows you to get all the current mappings from the kernel 
without having to blindly search through an arbitrarily large keyspace.

Also, EVIOCLEARKEYCODEBIG should be:

#define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)

That way a user space application can simply call EVIOCLEARKEYCODEBIG, 
ask the user for an appropriate keycode, fill in the keycode member of 
the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.

On a related note, I really think the interface would benefit from 
allowing more than one keytable per irrcv device with an input device 
created per keytable. That way you can have one input device per remote 
control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an 
evdev IOCTL since there's an N-1 mapping between input devices and irrcv 
devices.

ioctl's to set/get keycodes for ir should also take a flag parameter in 
the struct to allow special properties to be set/returned for a given 
keycode mapping (I'm thinking of keycodes which powers on the computer 
for instance, that should be exposed to userspace somehow).

With all of that, the struct might need to be something like:

struct keycode_table_entry {
	unsigned keycode; /* e.g. KEY_A */
	unsigned table;   /* Table index, for multiple keytables */
	unsigned index;   /* Index in the given keytable */
	unsigned flags;   /* For additional functionality */
	unsigned len;     /* Of the struct */
	char scancode[];  /* Per-protocol scancode data follows */
};

Finally, I think irrcv should create a chardev of its own with ioctl's 
like EVIOCLEARKEYCODEBIG (and RX/TX parameter setting ioctl's).  The 
same chardev can be used for IR blasting (by writing data to it once TX 
parameters have been set).

-- 
David Härdeman
--
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/