On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer <fschaefer....@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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
