Re: [RFC PATCH 0/2] Apple remote support

[Jarod Wilson <jarod@redhat.com>]

On Wed, Nov 17, 2010 at 12:26:36AM +0100, David Härdeman wrote:
> On Tue, Nov 16, 2010 at 10:08:29AM -0200, Mauro Carvalho Chehab wrote:
...
> >Also, changing the current tables to 32 bits will break userspace API, as all
> >userspace keytables for NEC will stop working, all due to a few vendors that 
> >decided to abuse on the NEC protocol. This doesn't sound fair.
> 
> The NEC protocol is hardly a standard. There's lot's of variations out
> there. And intentionally throwing away information inside the kernel
> doesn't sound fair either.
> 
> >Considering that the new setkeycode/getkeycode ioctls support a variable
> >size for scancodes, it seems to me that the proper solution is properly
> >add support for variable-size scancode tables. By doing this, one of the
> >properties for a scancode table is the size of the scancode. The NEC decoding
> >logic can take the scancode size into account, when deciding to check checksum
> >or not.
> 
> With that approach you'd have to have the same scancode mangling code in
> each driver which generates NEC scancodes as well as in the nec raw
> decoder.
> 
> One suggestion would be to use a full 32-bit scancode table, but use the
> size from the ioctl to determine how to generate the scancode to be
> inserted into the table. So if the ioctl was called with a 2 byte
> scancode, assume NEC with addr(8 bits) + cmd(8 bits); 3 byte -> NEC
> Extended with addr(16 bits) + cmd(8 bits); 4 byte -> 32 bit scancode.
> 
> That way the nec decoder and other scancode drivers can be kept simple,
> the scancode table has a full 32 bit scancode for all keys and userspace
> won't see the difference (though I still think we should use the new
> large scancode API to let userspace properly indicate the protocol along
> with the scancode in the future).

I hacked together a semi-nasty variant of this, which I already know Mauro
isn't too keen on, but its perhaps a step in the right direction. At
least, its hopefully better than a modparam approach... ;)

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=commitdiff;h=a2eabcb44fa72e98a912c05a23659d0c946a17e5
http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=commitdiff;h=164dc9cf5dec582bda5f7a059957ac2da2b0c1aa

Mauro's suggestion, iirc, was that max scancode size should be a property
of the keytable uploaded, and something set at load time (and probably
exposed as a sysfs node, similar to protocols). However, the one issue I
see there is that if someone loads a 16-bit keytable, then does a single
scancode replacement with something much larger, how are we going to
handle that?

-- 
Jarod Wilson
jarod@redhat.com