Re: 3.9.2 kernel - IR / em28xx_rc broken?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

> 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. The behaviour when configured for "RC_BIT_UNKNOWN" would therefore have been "undefined"... ;-).

Cheers,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux