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:	Fri, 26 Mar 2010 09:01:50 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Jon Smirl <jonsmirl@...il.com>, Pavel Machek <pavel@....cz>,
	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 Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
> David Härdeman wrote:
> > 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.
> 
> Makes sense.

Yes, I think so too. Just need a nice way to handle transition, I'd
like in the end to have drivers implement only the improved methods and
map legacy methods in evdev.

> 
> > 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.
> 
> By using the index concept, I don't think we need another ioctl. Also,
> there's no way for kernel to handle it, as it will be using the same
> magic number of EVIOCGKEYCODEBIG.
> 
> > 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.
> 
> I don't think that an ioctl over one /dev/input/event should be the proper way
> to ask kernel to create another filtered /dev/input/event. As it were commented
> that the multimedia keys on some keyboards could benefit on having a filter
> capability, maybe we may have a sysfs node at class input that would allow
> the creation/removal of the filtered event interface.

No, if you want separate event devices just create a new instance of
input device for every keymap and have driver/irrcv class route events
to proper input device.

Thanks.

-- 
Dmitry
--
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/