Re: 3.9.2 kernel - IR / em28xx_rc broken?

["Frank Schäfer" <fschaefer.oss@googlemail.com>]

Am 20.05.2013 15:01, schrieb Chris Rankin:
> ----- Original Message -----
>
>>> And this is me calling ir-keytable:
>>>
>>> [ 2183.812407] em28xx #0: Changing protocol: rc_type=1
>> So with 3.8 the same happens as with 3.9.
> Yes, that does appear to be part of the RC core ABI.
>
>> Well, if ir-keycode / the RC core requests RC_BIT_UNKNOWN, they get RC_BIT_UNKNOWN. ;)
>> If you expect the device to be configured for another protocol (RC5 ?),
>> you need to find out what's going wrong in the RC core and/or ir-keycode.
> Are other RCs affected by this? I have difficulty blaming RC core when its behaviour hasn't changed.

If I had to guess, I would say you should check your rc_maps.cfg /
keytable. ;)

>
>> The point is that 3.8 ignores rc_type=1, whereas 3.9 uses it to update a new ir->rc_type field - which in turn controls how em2874_polling_getkey() encodes its scancode.
>> Indeed, since 3.9
>> 1.) em2874_polling_getkey() cares about the rc_type
>> 2.) the new rc_type is saved back to ir->rc_type
>>
>> AFAICS both changes are correct.
> Except that given the current ABI, these changes break my RC.

No, the change that actually broke your RC is the third change.

>
>> But there was a third change:
>> 3.) the scancode passed to the RC core with rc_keypress() in case of
>> RC_BIT_UNKNOWN changed from a 16 bit value to 32 bit value (e.g.: old: 00 00 ab cd => new: ab cd xx xx).
>>
>> Hmm... isn't this an ABI break !?
> em28xx only used to support RC5 in 3.8, by the looks of things.

... and NEC.

>  The behaviour when configured for "RC_BIT_UNKNOWN" would therefore have been "undefined"... ;-).

With both kernels (3.8 and 3.9), the hardware is configured for RC5 when
RC_BIT_UNKNOWN is selected.
The only thing that changed in the configuration part (apart from the
new ir->rc_type field and RC& support) is,
that em28xx_ir_change_protocol() used to return -EINVAL for
RC_NIT_UNKNOWN and 3.9 now returns 0.
But that seems to be no issue here.

Regards,
Frank

>
> Cheers,
> Chris