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

["David Härdeman" <david@hardeman.nu>]

On Tue, Nov 16, 2010 at 10:08:29AM -0200, Mauro Carvalho Chehab wrote:
>Em 15-11-2010 02:11, Jarod Wilson escreveu:
>> Gives us support for using the full 32-bit codes right now w/o having
>> to change any tables yet, but does require a modparam to skip the
>> checksum checks, unless its an apple remote which we already know the
>> vendor bytes for. I do think I'm ultimately leaning towards just
>> doing the full 32 bits for all nec extended though -- optionally, we
>> might include a modparam to *enable* the checksum check for those
>> that want strict compliance (but I'd still say use the full 32 bits).
>> The only issue I see with going to the full 32 right now is that we
>> have all these nec tables with only 24 bits, and we don't know ...
>> oh, wait, no, nevermind... We *do* know the missing 8 bits, since
>> they have to fulfill the checksum check for command ^ not_command. So
>> yeah, I'd say 32-bit scancodes for all nec extended, don't enforce
>> the checksum by default with a module option (or sysfs knob) to
>> enable checksum compliance.
>
>A modprobe parameter for it doesn't seem right. Users should not need to
>do any manual hack for ther RC to work, if the keycode table is ok.

Agreed. There are already too many weird driver-specific modparams in
use as is.

>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).


-- 
David Härdeman