Re: em28xx: msi Digivox ATSC board id [0db0:8810]

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

Am 10.12.2012 16:46, schrieb Devin Heitmueller:
> On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
>>> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>>>> Forget this sh... (never do multiple things at the same time ;) )
>>>>
>>>> Reg 0x50 is set to according to rc_type specified in the selected remote
>>>> control map.
>>>> So if the correct map is selected, everything should be fine (as long as
>>>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>>>>
>>>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
>>>> the stick seems to use no NEC protocol.
>>>>
>>>> Matthew, insert a line
>>>>
>>>>          ir_config = 0x01;
>>>>
>>>> before
>>>>
>>>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>>>>
>>>> in em28xx-input.c and see if something shows up in the dmesg output.
>>>>
>>>> Regards,
>>>> Frank
>>> That seems to be a bit more successful!
>>>
>>> Here is the dmesg output:
>>>
>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>>> key 0x61d6
>>> I pressed all the buttons on the remote (40 buttons).
>> Did you cut the dmesg output ? Or do you really get these messages for
>> key 0x61d6 only ?
>>
>> It seems like things are working different with reg 0x50 = 0x01. Taking
>> a look into the datasheet might help, but I don't have it. ;)
> Setting that bit turns off NEC parity checking.  I don't think we've
> ever had a need for it before, which is why it isn't exposed as
> configurable functionality in the driver.
>
> No clear answer on how this should be fixed, if that's what is really
> required.  I guess in theory we could introduce some new board config
> option, but that would likely interfere with the ability to
> reconfigure the RC protocol at runtime.  An alternative would be a new
> property of the RC profile, but that would pollute the definition of
> the struct presumably to work around some bug in a crappy remote
> control.

Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols have paritiy checking ? Otherwise we could add a new
type RC_TYPE_NEC_NO_PARITY.
OTOH, introducing a new bitfield in struct rc_map might be usefull for
other flags, too, in the future...

Regards,
Frank
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com