[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B12EEC2.3030207@gmail.com>
Date: Sun, 29 Nov 2009 22:59:30 +0100
From: Artur Skawina <art.08.09@...il.com>
To: mike@...ambier.net
CC: Jon Smirl <jonsmirl@...il.com>,
Christoph Bartelmus <christoph@...telmus.de>,
jarod@...sonet.com, awalls@...ix.net, dmitry.torokhov@...il.com,
j@...nau.net, jarod@...hat.com, khc@...waw.pl,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
IR system?
Mike Lampard wrote:
> an example I have a VDR instance running in the background on my desktop
> machine outputting to a TV in another room via a pci mpeg decoder - I
> certainly don't want the VDR remote control interacting with my X11 desktop in
> any way unless I go out of my way to set it up to do so, nor do I want it
> interacting with other applications (such as MPD piping music around the
> house) that are controlled via other remotes in other rooms unless specified.
>
> Setting this up with Lircd was easy, how would a kernel-based proposal handle
> this?
eg
EV="/dev/input/"$( cd "/sys/class/input" &&
( grep -l 'X10' event*/device/name || grep -l 'X10' event*/device/manufacturer ) |
sed -e 's,/.*,,' )
./vdr [...] -P "remote -i $EV"
This is how it has worked for years, so there's no reason it wouldn't work w/ any
future scheme. The remote buttons normally arrive as normal kbd keys; once an app
grabs the input device corresponding to a remote, it receives the events exclusively.
artur
--
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