On Thu, Nov 18, 2010 at 04:18:03AM +0000, Bastien Nocera wrote: > On Thu, 2010-10-07 at 20:39 -0400, Jarod Wilson wrote: > > On Thu, Sep 30, 2010 at 04:51:30PM +0100, Bastien Nocera wrote: > > > On Thu, 2010-09-30 at 08:47 -0700, Dmitry Torokhov wrote: > > > > Bastien, > > ... > > > > I'll try > > > > to get the driver in .37 but after that we should probably move it > > > > over to the new IR infrastructure... > > > > > > I'm not sure what that would bring us, nor do I have any experience in > > > using the ir-core. From what I understood, it still needed fleshing out. > > > > There are a few things that still need fleshing out, but nothing really > > that should have any major impact on a potential port of this driver. > > > > Off the top of my head, the main thing it would give you is the ability to > > upload your own keymap for the receiver. > > You could already change the keymap... You could change the mapping for the 6 buttons, but new scancode to keycode mappings wouldn't be possible. That's assuming the driver actually does raw IR decode -- the scancodes I see in the key tables in the driver definitely match decoded NEC that I get when using the Apple remote with another raw IR receiver (mceusb). Reading through the code though, it appears the IR signal is decoded in hardware and only the resulting scancodes are passed along... I wonder if it passes along scancodes for all NEC signals or if its doing filtering... I have sufficiently equipped Apple hardware of my own that I suppose I really ought to prod. > > Then someone wanting to use more > > than 6 buttons > > But only for the 6 buttons supported. > > > or whatever it is might still be able to get the benefits > > of in-kernel decoding with everything coming through the input layer, > > rather than using lirc or the like. > > I see very little benefits myself (I mean, unless you're adamant that > you want to use a remote that's not intended for that computer, but we > already have lirc user-space driver for doing that), I don't see why we shouldn't be able to do it in-kernel too, without the need for any userspace daemon. The bigger win though is probably de-duplication of keyup/keydown/timer logic. I had similar duplication in the imon driver (which is also scancode-based), and the code is smaller and cleaner after being adapted to use ir/rc-core functions. > and it would remove > metadata from the events, so we couldn't do "remote filtering" (each > remote has a semi-random UID, which gets passed in with the events). No it wouldn't. The lsb of the decoded NEC pulse train contains the ID, I'm able to see it just fine with other raw IR receivers and some experimental patches we're kicking around on linux-media. > When the appleir patch was finally accepted (which means I need to get > off my arse and do the changes Oliver mentioned), working on UID > filtering is next on my list of TODOs. I've got an implementation here using the in-kernel NEC decoder, an Apple remote any an mceusb transceiver that works. Its not terribly *elegant*, but it does work. (Executive summary: if not doing pairing, zero out the pair ID and use the full 32-bit scancode with a default keytable that has 0x00 in the pair ID position. If doing pairing, pass that byte unmodified, and upload a keymap that matches). -- Jarod Wilson jarod@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
