From: Jarod W. <ja...@wi...> - 2010-11-07 23:26:41
|
On Nov 7, 2010, at 5:16 PM, Jon Davies wrote: > On 6 November 2010 04:02, Jarod Wilson <ja...@wi...> wrote: > [...] > >> The remotes all wind up ultimately as input > >> devices > > This got me thinking about something I've been scratching my head about: > > I'm one of those people who have a MS MCE keyboard (one of the infra-red ones) and use it for occasional things on my media box. I run it using lirc-mod-mce at the moment, which with some help I've got as far as porting to lirc 0.8.6 (yeah, it's a bit behind, but that's what I need for ubuntu 10.04 ;). The code is all a bit of a frig at the moment, and I was wondering how it ought to fit into the architecture of lirc. It shouldn't fit into lirc at all. It should fit into the input subsystem, exactly the same way the mce remotes do -- in-kernel decode, key events passed along through the input layer. Keyboard input coming in through any other means is bananas. > The thing this thread got me wondering about is that if the repeat stuff gets fixed in some form in lirc itself, then is an infra-red keyboard just yet another remote? Given time I could probably work this out, but I don't know anything like enough about lirc to answer it at the moment. Any suggestions? It should look to the system like a keyboard and mouse. I've already got plans (and the hardware) to address this, just working on too many other things at the moment. You're welcome to take a crack at it too though, of course. But it needs to go upstream in the kernel, as a pluggable module, probably under drivers/media/IR/, which can be loaded by any of the raw IR device drivers to handle mce keyboard/mouse input. It would be a special-case IR decoder that actually sets up its own keyboard and mouse event devices, rather than using the IR device driver's remote input device. The raw IR data would be passed to the decoder, and parsed and handled entirely within the decoder, rather than handing scancodes back to the IR layer to match against keycode tables. At least, that's how I'm currently envisioning it. -- Jarod Wilson ja...@wi... |