[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BDodb$iHqgB@lirc>
Date: 29 Nov 2009 12:24:00 +0100
From: lirc@...telmus.de (Christoph Bartelmus)
To: stefanr@...6.in-berlin.de
Cc: superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Stefan,
on 28 Nov 09 at 21:29, Stefan Richter wrote:
> 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.
Consider this case:
Two remotes use different protocols. The scancodes after decoding happen
to overlap.
Just using the scancodes you cannot distinguish between the remotes.
You'll need to add the protocol information to be able to solve this which
complicates the setup.
In LIRC this is solved by having protocol parameters and scancode mapping
in one place.
Christoph
--
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