Re: [RFC] What are the goals for the architecture of an in-kernelIR system?

[Dmitry Torokhov]

On Sun, Nov 29, 2009 at 01:17:03PM +1030, Mike Lampard wrote:
> On Sat, 28 Nov 2009 02:27:59 am Jon Smirl wrote:
> > On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> > 
> > <christoph@xxxxxxxxxxxx> wrote:
> > > Hi Mauro,
> > >
> > > on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
> > >> Christoph Bartelmus wrote:
> > >
> > > [...]
> > >
> > >>> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's
> > >>> just because I'm not familiar at all with input layer toolset.
> > >
> > > [...]
> > >
> > >> I hope it helps for you to better understand how this works.
> > >
> > > So the plan is to have two ways of using IR in the future which are
> > > incompatible to each other, the feature-set of one being a subset of the
> > > other?
> > 
> > Take advantage of the fact that we don't have a twenty year old legacy
> > API already in the kernel. Design an IR API that uses current kernel
> > systems. Christoph, ignore the code I wrote and make a design proposal
> > that addresses these goals...
> > 
> > 1) Unified input in Linux using evdev. IR is on equal footing with
> > mouse and keyboard.
> 
> I think this a case where automating setup can be over-emphasised (in the 
> remote-as-keyboard case).
> 
> Apologies in advance if I've misunderstood the idea of utilising the 'input 
> subsystem' for IR.  If the plan is to offer dedicated IR events via a yet-to-
> be-announced input event subsystem and to optionally disallow acting as a 
> keyboard via a module option or similar then please ignore the following.
> 
> Whilst having remotes come through the input subsystem might be 'the correct 
> thing' from a purely technical standpoint, as an end-user I find the use-case 
> for remotes completely different in one key aspect:  Keyboards and mice are 
> generally foreground-app input devices, whereas remotes are often controlling 
> daemons sitting in the background piping media through dedicated devices.  As 
> 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?
>

Why would that be different really? On my keyboard there is a key for
e-mail application (and many others) - what HID calls Application Launch
keys IIRC. There also application control keys and system control keys,
KEY_COFFEE aka KEY_SCREENLOCK. Those are not to be consumed by
foreground application but by daemons/session-wide application.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/