[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B11881B.7000204@s5r6.in-berlin.de>
Date: Sat, 28 Nov 2009 21:29:15 +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 2:45 PM, Stefan Richter
> <stefanr@...6.in-berlin.de> wrote:
>> Jon Smirl wrote:
>>> Also, how do you create the devices for each remote? You would need to
>>> create these devices before being able to do EVIOCSKEYCODE to them.
>> The input subsystem creates devices on behalf of input drivers. (Kernel
>> drivers, that is. Userspace drivers are per se not affected.)
>
> 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
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.)
--
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