linux-kernel - Re: [RFC v2] Another approach to IR

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: <20091201201158.GA20335@core.coreip.homeip.net>
Date:	Tue, 1 Dec 2009 12:11:58 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Jon Smirl <jonsmirl@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jarod@...sonet.com, khc@...waw.pl,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, lirc-list@...ts.sourceforge.net,
	superm1@...ntu.com, Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC v2] Another approach to IR

On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
> >> For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
> >> to change the protocol in runtime.
> >>
> > 
> > Mauro,
> > 
> > I think this kind of confuguration belongs to lirc device space,
> > not input/evdev. This is the same as protocol selection for psmouse
> > module: while it is normally auto-detected we have sysfs attribute to
> > force one or another and it is tied to serio device, not input
> > device.
> 
> Dmitry,
> 
> This has nothing to do with the raw interface nor with lirc. This problem 
> happens with the evdev interface and already affects the in-kernel drivers.
> 
> In this case, psmouse is not a good example. With a mouse, when a movement
> occurs, you'll receive some data from its port. So, a software can autodetect
> the protocol. The same principle can be used also with a raw pulse/space
> interface, where software can autodetect the protocol.

Or, in certain cases, it can not.

> 
[... skipped rationale for adding a way to control protocol (with which
I agree) ...]

> 
> To solve this, we really need to extend evdev API to do 3 things: enumberate the
> supported protocols, get the current protocol(s), and select the protocol(s) that
> will be used by a newer table.
> 

And here we start disagreeing. My preference would be for adding this
API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
since it only applicable to IR, not to input devices in general.

Once you selected proper protocol(s) and maybe instantiated several
input devices then udev (by examining input device capabilities and
optionally looking up at the parent device properties) would use
input evdev API to load proper keymap. Because translation of
driver-specific codes into standard key definitions is in the input
realm. Reading these driver-specific codes from hardware is outside of
input layer domain.

Just as psmouse ability to specify protocol is not shoved into evdev;
just as atkbd quirks (force release key list and other driver-specific
options) are not in evdev either; we should not overload evdev interface
with IR-specific items.

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