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: <4B119A36.8020903@s5r6.in-berlin.de>
Date:	Sat, 28 Nov 2009 22:46:30 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Jon Smirl <jonsmirl@...il.com>
CC:	Christoph Bartelmus <lirc@...telmus.de>, khc@...waw.pl,
	awalls@...ix.net, dmitry.torokhov@...il.com, j@...nau.net,
	jarod@...hat.com, jarod@...sonet.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	maximlevitsky@...il.com, mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR 	system?

Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter
> <stefanr@...6.in-berlin.de> wrote:
>> Jon Smirl wrote:
>>> We have one IR receiver device and multiple remotes. How does the
>>> input system know how many devices to create corresponding to how many
>>> remotes you have?
>> If several remotes are to be used on the same receiver, then they
>> necessarily need to generate different scancodes, don't they?  Otherwise
                                          ^^^^^^^^^
I referred to scancodes, not keycodes.

>> the input driver wouldn't be able to route their events to the
>> respective subdevice.  But if they do generate different scancodes,
>> there is no need to create subdevices just for EVIOCSKEYCODE's sake. (It
>> might still be desirable to have subdevices for other reasons perhaps.)
> 
> Multiple remotes will have duplicate buttons (1, 2 ,3, power, mute,
> etc) these should get mapped into the standard keycodes. You need to
> devices to key things straight.
> 
> Push button 1 on Remote A. That should generate a KP_1 on the evdev
> interface for that remote.
> Push button 1 on Remote B. That should generate a KP_1 on the evdev
> interface for that remote.
> 
> Scenario for this - a mutifunction remote that is controlling two
> different devices/apps. In one mode the 1 might be a channel number,
> in the other mode it might be a telephone number.
> 
> The user may chose to make button 1 on both remote A/B map to KP_1 on
> a single interface.
> 
> Scenario for this - I want to use two different remotes to control a
> single device.
> 
> ---------------------
> 
> I handled that in configds like this:
> /configfs - mount the basic configfs
> /configfs/remotes (created by loading IR support)
> mkdir /configfs/remotes/remote_A  - this causes the input subdevice to
> be created, the name of it appears in the created directory.
[...]

I'm lost.  If there are two remotes sending to a single receiver, and
their sets of scancodes do not overlap, then all is fine.  You can map
either set of scancodes to keycodes independently.  But if their ranges
of scancodes do overlap, then even the creation of subdevices does not
help --- the driver has no way to tell which of the remotes sent the
signal in order to select the corresponding input subdevice, does it?
-- 
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ