Am 10.12.2012 16:46, schrieb Devin Heitmueller: > On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer > <fschaefer.oss@xxxxxxxxxxxxxx> 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 -- 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
