* Can I expect in-kernel decoding to work out of box?
@ 2010-07-27 22:33 Maxim Levitsky
2010-07-27 23:32 ` Maxim Levitsky
0 siblings, 1 reply; 33+ messages in thread
From: Maxim Levitsky @ 2010-07-27 22:33 UTC (permalink / raw)
To: Jarod Wilson; +Cc: Jon Smirl, linux-input, Mauro Carvalho Chehab
[-- Attachment #1: Type: text/plain, Size: 92525 bytes --]
Hi,
I ported my ene driver to in-kernel decoding.
It isn't yet ready to be released, but in few days it will be.
Now, knowing about wonders of in-kernel decoding, I try to use it, but
it just doesn't work.
Mind you that lircd works with this remote.
(I attach my lircd.conf)
Here is the output of mode2 for a single keypress:
maxim@maxim-laptop:~$ mode2 -m
2147483
8850 4350 525 1575 525 1575
525 450 525 450 525 450
525 450 525 1575 525 450
525 1575 525 450 525 1575
525 450 525 450 525 1575
525 450 525 450 525 23625
600 1575 525 1575 525 450
525 450 525 450 525 450
525 1575 525 450 525 1575
525 450 525 1575 525 450
525 450 525 1575 525 450
525 450 525 23475 600 1575
525 1575 525 450 525 450
525 450 525 450 525 1575
525 450 525 1575 525 450
525 1575 525 450 525 450
525 1575 525 450 525 450
525
(Hardware isn't very accurate though, it shows that on all protocols).
According to tests I did in the past this is NEC protocol.
NEC is very popular protocol.
(Remote itself is from old JVC VCR, and it also a multifunction remote)
Now output from the uber-cool in-kernel decoding:
"ene_ir: RX:" means sample given by hardware
"IR: raw sample:" means sample given to ir_raw_event_store
[ 4765.446424] ene_ir: RX: 8850 (pulse)
[ 4765.446439] exit idle mode
[ 4765.446451] IR: raw sample: 2147483 us (space)
[ 4765.446464] IR: raw sample: 0 us (space)
[ 4765.446484] ene_ir: disabling idle mode
[ 4765.446514] ene_ir: RX: 4350 (space)
[ 4765.446525] IR: raw sample: 8850 us (pulse)
[ 4765.446545] ene_ir: RX: 525 (pulse)
[ 4765.446557] IR: raw sample: 4350 us (space)
[ 4765.446576] ene_ir: RX: 1575 (space)
[ 4765.446588] IR: raw sample: 525 us (pulse)
[ 4765.446612] ir_nec_decode: NEC decode started at state 0 (4292819813us space)
[ 4765.446633] ir_nec_decode: NEC decode failed at state 0 (4292819813us space)
[ 4765.446653] ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
[ 4765.446673] ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
[ 4765.446694] ir_rc6_decode: RC6 decode started at state 0 (4292819813us space)
[ 4765.446714] ir_rc6_decode: RC6 decode failed at state 0 (4292819813us space)
[ 4765.446734] ir_jvc_decode: JVC decode started at state 0 (4292819813us space)
[ 4765.446754] ir_jvc_decode: JVC decode failed at state 0 (4292819813us space)
[ 4765.446774] ir_sony_decode: Sony decode started at state 0 (4292819813us space)
[ 4765.446794] ir_sony_decode: Sony decode failed at state 0 (4292819813us space)
[ 4765.446814] ir_lirc_decode: LIRC data transfer started (4292819813us space)
[ 4765.446842] ir_nec_decode: NEC decode started at state 0 (8850us pulse)
[ 4765.446862] ir_rc5_decode: RC5(x) decode started at state 0 (8850us pulse)
[ 4765.446882] ir_rc5_decode: RC5(x) decode started at state 1 (7961us pulse)
[ 4765.446902] ir_rc5_decode: RC5(x) decode failed at state 1 (7961us pulse)
[ 4765.446922] ir_rc6_decode: RC6 decode started at state 0 (8850us pulse)
[ 4765.446941] ir_rc6_decode: RC6 decode failed at state 0 (8850us pulse)
[ 4765.446960] ir_jvc_decode: JVC decode started at state 0 (8850us pulse)
[ 4765.446979] ir_jvc_decode: JVC decode failed at state 0 (8850us pulse)
[ 4765.446998] ir_sony_decode: Sony decode started at state 0 (8850us pulse)
[ 4765.447017] ir_sony_decode: Sony decode failed at state 0 (8850us pulse)
[ 4765.447036] ir_lirc_decode: LIRC data transfer started (8850us pulse)
[ 4765.447059] ir_nec_decode: NEC decode started at state 1 (4350us space)
[ 4765.447078] ir_rc5_decode: RC5(x) decode started at state 0 (4350us space)
[ 4765.447097] ir_rc5_decode: RC5(x) decode failed at state 0 (4350us space)
[ 4765.447117] ir_rc6_decode: RC6 decode started at state 0 (4350us space)
[ 4765.447135] ir_rc6_decode: RC6 decode failed at state 0 (4350us space)
[ 4765.447153] ir_jvc_decode: JVC decode started at state 0 (4350us space)
[ 4765.447172] ir_jvc_decode: JVC decode failed at state 0 (4350us space)
[ 4765.447190] ir_sony_decode: Sony decode started at state 0 (4350us space)
[ 4765.447209] ir_sony_decode: Sony decode failed at state 0 (4350us space)
[ 4765.447228] ir_lirc_decode: LIRC data transfer started (4350us space)
[ 4765.447250] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.447269] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.447288] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.447307] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.447326] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.447344] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.447362] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.447380] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.447399] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.447417] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.449591] ene_ir: RX: 525 (pulse)
[ 4765.449602] IR: raw sample: 1575 us (space)
[ 4765.449622] ene_ir: RX: 1575 (space)
[ 4765.449633] IR: raw sample: 525 us (pulse)
[ 4765.449653] ene_ir: RX: 525 (pulse)
[ 4765.449664] IR: raw sample: 1575 us (space)
[ 4765.449684] ene_ir: RX: 450 (space)
[ 4765.449695] IR: raw sample: 525 us (pulse)
[ 4765.449721] ir_nec_decode: NEC decode started at state 3 (1575us space)
[ 4765.449740] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.449759] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.449778] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.449797] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.449815] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.449833] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.449852] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.449870] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.449889] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.449912] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.449930] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.449950] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.449969] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.449987] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.450005] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.450024] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.450043] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.450063] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.450081] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.450106] ir_nec_decode: NEC decode started at state 3 (1575us space)
[ 4765.450125] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.450146] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.450166] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.450185] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.450204] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.450223] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.450242] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.450261] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.450280] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.450302] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.450320] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.450340] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.450358] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.450377] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.450395] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.450413] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.450431] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.450450] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.450468] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.451755] ene_ir: RX: 525 (pulse)
[ 4765.451766] IR: raw sample: 450 us (space)
[ 4765.451786] ene_ir: RX: 450 (space)
[ 4765.451797] IR: raw sample: 525 us (pulse)
[ 4765.451817] ene_ir: RX: 525 (pulse)
[ 4765.451828] IR: raw sample: 450 us (space)
[ 4765.451848] ene_ir: RX: 450 (space)
[ 4765.451859] IR: raw sample: 525 us (pulse)
[ 4765.451885] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.451904] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.451923] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.451942] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.451961] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.451979] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.451998] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.452017] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.452036] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.452058] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.452077] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.452097] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.452116] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.452135] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.452153] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.452172] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.452190] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.452209] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.452228] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.452250] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.452270] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.452289] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.452308] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.452327] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.452345] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.452364] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.452383] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.452402] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.452424] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.452443] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.452463] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.452482] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.452545] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.452565] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.452588] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.452614] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.452645] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.452664] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.454857] ene_ir: RX: 525 (pulse)
[ 4765.454869] IR: raw sample: 450 us (space)
[ 4765.454898] ene_ir: RX: 450 (space)
[ 4765.454910] IR: raw sample: 525 us (pulse)
[ 4765.454931] ene_ir: RX: 525 (pulse)
[ 4765.454943] IR: raw sample: 450 us (space)
[ 4765.454964] ene_ir: RX: 1575 (space)
[ 4765.454976] IR: raw sample: 525 us (pulse)
[ 4765.457583] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.457605] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.457627] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.457650] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.457670] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.457696] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.457721] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.457742] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.457762] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.457788] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.457808] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.457828] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.457851] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.457876] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.457900] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.457931] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.457950] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.457970] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.458026] ene_ir: RX: 525 (pulse)
[ 4765.458038] IR: raw sample: 1575 us (space)
[ 4765.458059] ene_ir: RX: 450 (space)
[ 4765.458071] IR: raw sample: 525 us (pulse)
[ 4765.458100] ene_ir: RX: 525 (pulse)
[ 4765.458118] IR: raw sample: 450 us (space)
[ 4765.458147] ene_ir: RX: 1575 (space)
[ 4765.458166] IR: raw sample: 525 us (pulse)
[ 4765.458184] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.458209] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.458228] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.458249] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.458269] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.458291] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.458313] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.458338] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.458358] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.458383] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.458408] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.458427] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.458448] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.458471] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.458492] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.458511] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.458531] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.458550] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.458571] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.458593] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.458623] ir_nec_decode: NEC decode started at state 3 (1575us space)
[ 4765.458642] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.458663] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.458685] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.458712] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.458736] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.458767] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.458787] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.458808] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.458827] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.458859] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.458878] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.458898] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.458923] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.458948] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.458967] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.458986] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.459006] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.459027] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.459046] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.459071] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.459090] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.459110] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.459137] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.459156] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.459176] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.459196] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.459217] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.459240] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.459304] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.459323] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.459343] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.459363] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.459382] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.459402] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.459421] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.459440] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.459460] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.459479] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.461169] ene_ir: RX: 525 (pulse)
[ 4765.461177] IR: raw sample: 1575 us (space)
[ 4765.461192] ene_ir: RX: 450 (space)
[ 4765.461198] IR: raw sample: 525 us (pulse)
[ 4765.461213] ene_ir: RX: 525 (pulse)
[ 4765.461225] IR: raw sample: 450 us (space)
[ 4765.461246] ene_ir: RX: 1575 (space)
[ 4765.461257] IR: raw sample: 525 us (pulse)
[ 4765.461285] ir_nec_decode: NEC decode started at state 3 (1575us space)
[ 4765.461294] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.461304] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.461313] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.461322] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.461330] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.461340] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.461348] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.461357] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.461367] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.461382] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.461391] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.461400] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.461409] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.461418] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.461426] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.461435] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.461444] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.461453] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.461461] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.461476] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.461485] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.461494] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.461502] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.461511] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.461520] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.461529] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.461537] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.461546] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.461557] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.461566] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.461575] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.461584] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.461593] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.461602] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.461610] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.461619] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.461628] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.461637] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.463270] ene_ir: RX: 525 (pulse)
[ 4765.463277] IR: raw sample: 1575 us (space)
[ 4765.463291] ene_ir: RX: 450 (space)
[ 4765.463297] IR: raw sample: 525 us (pulse)
[ 4765.463310] ene_ir: RX: 525 (pulse)
[ 4765.463316] IR: raw sample: 450 us (space)
[ 4765.463329] ene_ir: RX: 450 (space)
[ 4765.463335] IR: raw sample: 525 us (pulse)
[ 4765.463495] ir_nec_decode: NEC decode started at state 3 (1575us space)
[ 4765.463516] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.463537] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.463558] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.463578] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.463597] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.463617] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.463636] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.463656] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.463676] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.463740] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.463760] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.463780] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.463800] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.463819] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.463838] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.463858] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.463877] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.463897] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.463917] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.463965] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.463985] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.464005] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.464025] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.464044] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.464064] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.464082] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.464103] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.464122] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.464169] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.464189] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.464209] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.464230] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.464250] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.464269] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.464293] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.464319] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.464345] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.464364] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.466444] ene_ir: RX: 525 (pulse)
[ 4765.466457] IR: raw sample: 450 us (space)
[ 4765.466478] ene_ir: RX: 1575 (space)
[ 4765.466490] IR: raw sample: 525 us (pulse)
[ 4765.466511] ene_ir: RX: 525 (pulse)
[ 4765.466523] IR: raw sample: 1575 us (space)
[ 4765.466547] ene_ir: RX: 450 (space)
[ 4765.466559] IR: raw sample: 525 us (pulse)
[ 4765.466586] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.466606] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.466629] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.466649] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.466668] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.466688] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.466707] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.466728] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.466747] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.466802] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.466821] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.466841] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.466861] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.466880] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.466899] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.466918] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.466937] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.466958] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.466977] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.467023] ir_nec_decode: NEC decode started at state 3 (1575us space)
[ 4765.467043] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.467063] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.467083] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.467102] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.467121] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.467141] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.467160] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.467180] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.467199] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.467249] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.467268] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.467289] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.467310] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.467329] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.467347] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.467366] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.467385] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.467404] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.467423] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.477130] ene_ir: RX: 525 (pulse)
[ 4765.477136] IR: raw sample: 450 us (space)
[ 4765.477147] ene_ir: RX: 450 (space)
[ 4765.477150] IR: raw sample: 525 us (pulse)
[ 4765.477161] ene_ir: RX: 525 (pulse)
[ 4765.477169] IR: raw sample: 450 us (space)
[ 4765.477185] ene_ir: RX: 9525 (space)
[ 4765.477193] IR: raw sample: 525 us (pulse)
[ 4765.477213] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.477218] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.477223] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.477228] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.477233] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.477238] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.477243] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.477248] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.477253] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.477262] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.477267] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.477272] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.477277] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.477282] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.477287] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.477292] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.477297] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.477302] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.477307] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.477315] ir_nec_decode: NEC decode started at state 3 (450us space)
[ 4765.477320] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.477324] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.477329] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.477334] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.477339] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.477343] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.477348] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.477353] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.477359] ir_nec_decode: NEC decode started at state 2 (525us pulse)
[ 4765.477364] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.477368] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.477373] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.477378] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.477383] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.477387] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.477392] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.477397] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.477401] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.486337] ene_ir: RX: 9525 (space)
[ 4765.493452] ene_ir: RX: 4575 (space)
[ 4765.493468] ene_ir: RX: 600 (pulse)
[ 4765.493476] IR: raw sample: 23625 us (space)
[ 4765.493492] ene_ir: RX: 1575 (space)
[ 4765.493495] IR: raw sample: 600 us (pulse)
[ 4765.493505] ene_ir: RX: 525 (pulse)
[ 4765.493508] IR: raw sample: 1575 us (space)
[ 4765.493521] ir_nec_decode: NEC decode started at state 3 (23625us space)
[ 4765.493527] ir_nec_decode: NEC decode failed at state 3 (23625us space)
[ 4765.493532] ir_rc5_decode: RC5(x) decode started at state 1 (23625us space)
[ 4765.493537] ir_rc5_decode: RC5(x) decode failed at state 1 (23625us space)
[ 4765.493542] ir_rc6_decode: RC6 decode started at state 0 (23625us space)
[ 4765.493547] ir_rc6_decode: RC6 decode failed at state 0 (23625us space)
[ 4765.493552] ir_jvc_decode: JVC decode started at state 0 (23625us space)
[ 4765.493557] ir_jvc_decode: JVC decode failed at state 0 (23625us space)
[ 4765.493562] ir_sony_decode: Sony decode started at state 0 (23625us space)
[ 4765.493567] ir_sony_decode: Sony decode failed at state 0 (23625us space)
[ 4765.493572] ir_lirc_decode: LIRC data transfer started (23625us space)
[ 4765.493581] ir_nec_decode: NEC decode started at state 0 (600us pulse)
[ 4765.493586] ir_nec_decode: NEC decode failed at state 0 (600us pulse)
[ 4765.493591] ir_rc5_decode: RC5(x) decode started at state 0 (600us pulse)
[ 4765.493595] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.493601] ir_rc6_decode: RC6 decode started at state 0 (600us pulse)
[ 4765.493605] ir_rc6_decode: RC6 decode failed at state 0 (600us pulse)
[ 4765.493610] ir_jvc_decode: JVC decode started at state 0 (600us pulse)
[ 4765.493615] ir_jvc_decode: JVC decode failed at state 0 (600us pulse)
[ 4765.493620] ir_sony_decode: Sony decode started at state 0 (600us pulse)
[ 4765.493625] ir_sony_decode: Sony decode failed at state 0 (600us pulse)
[ 4765.493630] ir_lirc_decode: LIRC data transfer started (600us pulse)
[ 4765.493638] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.493643] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.493648] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.493653] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.493658] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.493663] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.493667] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.493672] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.493677] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.493682] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.493687] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.496593] ene_ir: RX: 1575 (space)
[ 4765.496596] IR: raw sample: 525 us (pulse)
[ 4765.496607] ene_ir: RX: 525 (pulse)
[ 4765.496610] IR: raw sample: 1575 us (space)
[ 4765.496620] ene_ir: RX: 450 (space)
[ 4765.496623] IR: raw sample: 525 us (pulse)
[ 4765.496633] ene_ir: RX: 525 (pulse)
[ 4765.496636] IR: raw sample: 450 us (space)
[ 4765.496648] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.496653] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.496657] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.496662] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.496667] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.496672] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.496676] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.496681] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.496686] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.496690] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.496695] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.496703] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.496708] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.496713] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.496718] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.496723] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.496728] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.496732] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.496737] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.496742] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.496747] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.496752] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.496759] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.496764] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.496768] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.496773] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.496778] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.496783] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.496793] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.496793] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.496797] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.496802] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.496806] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.496814] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.496819] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.496823] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.496828] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.496833] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.496837] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.496842] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.496847] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.496852] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.496856] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.498706] ene_ir: RX: 450 (space)
[ 4765.498715] IR: raw sample: 525 us (pulse)
[ 4765.498731] ene_ir: RX: 525 (pulse)
[ 4765.498739] IR: raw sample: 450 us (space)
[ 4765.498754] ene_ir: RX: 450 (space)
[ 4765.498761] IR: raw sample: 525 us (pulse)
[ 4765.498777] ene_ir: RX: 525 (pulse)
[ 4765.498784] IR: raw sample: 450 us (space)
[ 4765.498801] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.498814] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.498826] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.498839] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.498852] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.498865] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.498878] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.498890] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.498903] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.498915] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.498928] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.498944] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.498956] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.498969] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.498982] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.498987] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.498992] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.498997] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.499001] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.499006] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.499010] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.499018] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.499023] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.499028] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.499033] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.499037] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.499042] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.499047] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.499052] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.499056] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.499061] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.499065] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.499072] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.499076] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.499081] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.499086] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.499090] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.499095] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.499100] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.499105] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.499110] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.499114] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.501866] ene_ir: RX: 450 (space)
[ 4765.501870] IR: raw sample: 525 us (pulse)
[ 4765.501881] ene_ir: RX: 525 (pulse)
[ 4765.501884] IR: raw sample: 450 us (space)
[ 4765.501896] ene_ir: RX: 1575 (space)
[ 4765.501904] IR: raw sample: 525 us (pulse)
[ 4765.501920] ene_ir: RX: 525 (pulse)
[ 4765.501927] IR: raw sample: 1575 us (space)
[ 4765.501944] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.501949] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.501953] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.501958] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.501963] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.501968] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.501973] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.501977] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.501982] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.501987] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.501991] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.501999] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.502004] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.502009] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.502014] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.502018] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.502023] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.502028] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.502032] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.502037] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.502042] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.502048] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.502053] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.502057] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.502062] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.502067] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.502072] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.502076] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.502081] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.502086] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.502091] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.502096] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.502103] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.502108] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.502113] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.502118] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.502123] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.502128] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.502132] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.502137] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.502142] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.502147] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.502151] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.505026] ene_ir: RX: 450 (space)
[ 4765.505039] IR: raw sample: 525 us (pulse)
[ 4765.505051] ene_ir: RX: 525 (pulse)
[ 4765.505055] IR: raw sample: 450 us (space)
[ 4765.505066] ene_ir: RX: 1575 (space)
[ 4765.505070] IR: raw sample: 525 us (pulse)
[ 4765.505082] ene_ir: RX: 525 (pulse)
[ 4765.505086] IR: raw sample: 1575 us (space)
[ 4765.505144] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.505150] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.505156] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.505163] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.505169] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.505175] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.505180] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.505186] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.505192] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.505198] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.505204] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.505216] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.505222] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.505227] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.505233] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.505239] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.505245] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.505251] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.505257] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.505263] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.505269] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.505279] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.505284] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.505290] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.505296] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.505302] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.505308] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.505315] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.505321] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.505327] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.505333] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.505339] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.505348] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.505354] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.505360] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.505367] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.505373] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.505380] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.505386] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.505392] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.505398] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.505405] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.505411] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.508194] ene_ir: RX: 450 (space)
[ 4765.508209] IR: raw sample: 525 us (pulse)
[ 4765.508232] ene_ir: RX: 525 (pulse)
[ 4765.508241] IR: raw sample: 450 us (space)
[ 4765.508258] ene_ir: RX: 1575 (space)
[ 4765.508268] IR: raw sample: 525 us (pulse)
[ 4765.508290] ene_ir: RX: 525 (pulse)
[ 4765.508299] IR: raw sample: 1575 us (space)
[ 4765.508599] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.508619] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.508635] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.508650] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.508665] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.508680] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.508695] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.508710] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.508724] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.508740] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.508755] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.508776] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.508792] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.508807] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.508825] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.508842] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.508860] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.508875] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.508890] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.508905] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.508919] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.508938] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.508952] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.508967] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.508982] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.508997] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.509013] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.509027] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.509042] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.509057] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.509072] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.509087] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.509116] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.509131] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.509147] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.509165] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.509181] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.509196] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.509211] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.509226] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.509244] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.509262] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.509277] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.510293] ene_ir: RX: 450 (space)
[ 4765.510297] IR: raw sample: 525 us (pulse)
[ 4765.510308] ene_ir: RX: 525 (pulse)
[ 4765.510311] IR: raw sample: 450 us (space)
[ 4765.510321] ene_ir: RX: 450 (space)
[ 4765.510324] IR: raw sample: 525 us (pulse)
[ 4765.510335] ene_ir: RX: 525 (pulse)
[ 4765.510338] IR: raw sample: 450 us (space)
[ 4765.510350] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.510355] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.510360] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.510365] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.510370] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.510374] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.510379] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.510384] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.510389] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.510393] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.510398] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.510407] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.510411] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.510416] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.510421] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.510426] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.510430] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.510435] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.510440] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.510444] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.510449] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.510456] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.510461] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.510465] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.510470] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.510475] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.510480] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.510484] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.510489] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.510494] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.510499] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.510503] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.510511] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.510516] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.510520] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.510525] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.510530] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.510534] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.510539] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.510544] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.510548] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.510553] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.513450] ene_ir: RX: 1575 (space)
[ 4765.513459] IR: raw sample: 525 us (pulse)
[ 4765.513476] ene_ir: RX: 525 (pulse)
[ 4765.513484] IR: raw sample: 1575 us (space)
[ 4765.513501] ene_ir: RX: 450 (space)
[ 4765.513510] IR: raw sample: 525 us (pulse)
[ 4765.513526] ene_ir: RX: 525 (pulse)
[ 4765.513535] IR: raw sample: 450 us (space)
[ 4765.513552] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.513566] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.513579] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.513593] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.513606] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.513620] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.513634] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.513647] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.513660] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.513674] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.513688] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.513704] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.513719] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.513732] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.513746] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.513759] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.513773] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.513787] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.513800] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.513814] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.513827] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.513841] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.513856] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.513869] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.513881] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.513895] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.513908] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.513922] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.513934] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.513949] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.513962] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.513976] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.513990] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.514005] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.514018] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.514031] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.514045] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.514058] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.514071] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.514085] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.514098] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.514111] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.514124] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.524666] ene_ir: RX: 450 (space)
[ 4765.524670] IR: raw sample: 525 us (pulse)
[ 4765.524682] ene_ir: RX: 525 (pulse)
[ 4765.524685] IR: raw sample: 450 us (space)
[ 4765.524697] ene_ir: RX: 9525 (space)
[ 4765.524700] IR: raw sample: 525 us (pulse)
[ 4765.524726] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.524731] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.524736] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.524741] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.524747] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.524752] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.524758] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.524763] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.524768] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.524773] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.524779] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.524787] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.524792] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.524797] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.524802] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.524807] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.524812] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.524817] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.524822] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.524827] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.524832] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.524839] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.524844] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.524849] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.524854] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.524859] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.524863] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.524869] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.524874] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.524879] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.524883] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.524888] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.532792] ene_ir: RX: 9525 (space)
[ 4765.539803] ene_ir: RX: 4425 (space)
[ 4765.539814] ene_ir: RX: 600 (pulse)
[ 4765.539818] IR: raw sample: 23475 us (space)
[ 4765.539828] ene_ir: RX: 1575 (space)
[ 4765.539831] IR: raw sample: 600 us (pulse)
[ 4765.539842] ene_ir: RX: 525 (pulse)
[ 4765.539845] IR: raw sample: 1575 us (space)
[ 4765.539858] ir_nec_decode: NEC decode started at state 0 (23475us space)
[ 4765.539863] ir_nec_decode: NEC decode failed at state 0 (23475us space)
[ 4765.539868] ir_rc5_decode: RC5(x) decode started at state 1 (23475us space)
[ 4765.539873] ir_rc5_decode: RC5(x) decode failed at state 1 (23475us space)
[ 4765.539878] ir_rc6_decode: RC6 decode started at state 0 (23475us space)
[ 4765.539883] ir_rc6_decode: RC6 decode failed at state 0 (23475us space)
[ 4765.539888] ir_jvc_decode: JVC decode started at state 0 (23475us space)
[ 4765.539893] ir_jvc_decode: JVC decode failed at state 0 (23475us space)
[ 4765.539897] ir_sony_decode: Sony decode started at state 0 (23475us space)
[ 4765.539902] ir_sony_decode: Sony decode failed at state 0 (23475us space)
[ 4765.539907] ir_lirc_decode: LIRC data transfer started (23475us space)
[ 4765.539915] ir_nec_decode: NEC decode started at state 0 (600us pulse)
[ 4765.539920] ir_nec_decode: NEC decode failed at state 0 (600us pulse)
[ 4765.539925] ir_rc5_decode: RC5(x) decode started at state 0 (600us pulse)
[ 4765.539930] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.539935] ir_rc6_decode: RC6 decode started at state 0 (600us pulse)
[ 4765.539940] ir_rc6_decode: RC6 decode failed at state 0 (600us pulse)
[ 4765.539945] ir_jvc_decode: JVC decode started at state 0 (600us pulse)
[ 4765.539950] ir_jvc_decode: JVC decode failed at state 0 (600us pulse)
[ 4765.539955] ir_sony_decode: Sony decode started at state 0 (600us pulse)
[ 4765.539960] ir_sony_decode: Sony decode failed at state 0 (600us pulse)
[ 4765.539965] ir_lirc_decode: LIRC data transfer started (600us pulse)
[ 4765.539978] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.539978] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.539982] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.539987] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.539992] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.539997] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.540002] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.540007] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.540013] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.540018] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.540023] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.542972] ene_ir: RX: 1575 (space)
[ 4765.542982] IR: raw sample: 525 us (pulse)
[ 4765.542998] ene_ir: RX: 525 (pulse)
[ 4765.543002] IR: raw sample: 1575 us (space)
[ 4765.543012] ene_ir: RX: 450 (space)
[ 4765.543015] IR: raw sample: 525 us (pulse)
[ 4765.543025] ene_ir: RX: 525 (pulse)
[ 4765.543028] IR: raw sample: 450 us (space)
[ 4765.543041] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.543046] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.543051] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.543056] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.543061] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.543066] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.543070] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.543075] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.543080] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.543085] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.543090] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.543097] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.543103] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.543107] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.543113] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.543118] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.543122] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.543127] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.543132] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.543137] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.543142] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.543147] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.543153] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.543158] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.543163] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.543168] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.543173] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.543177] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.543182] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.543187] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.543191] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.543196] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.543201] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.543207] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.543212] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.543217] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.543222] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.543226] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.543231] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.543236] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.543240] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.543245] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.543250] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.545075] ene_ir: RX: 450 (space)
[ 4765.545084] IR: raw sample: 525 us (pulse)
[ 4765.545100] ene_ir: RX: 525 (pulse)
[ 4765.545108] IR: raw sample: 450 us (space)
[ 4765.545125] ene_ir: RX: 450 (space)
[ 4765.545134] IR: raw sample: 525 us (pulse)
[ 4765.545151] ene_ir: RX: 525 (pulse)
[ 4765.545159] IR: raw sample: 450 us (space)
[ 4765.545177] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.545190] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.545203] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.545217] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.545231] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.545244] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.545257] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.545270] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.545283] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.545297] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.545310] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.545328] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.545341] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.545355] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.545369] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.545382] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.545395] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.545409] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.545424] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.545439] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.545452] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.545468] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.545481] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.545494] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.545508] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.545521] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.545535] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.545548] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.545561] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.545574] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.545588] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.545602] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.545618] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.545630] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.545644] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.545658] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.545671] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.545684] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.545698] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.545711] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.545725] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.545738] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.548248] ene_ir: RX: 450 (space)
[ 4765.548256] IR: raw sample: 525 us (pulse)
[ 4765.548272] ene_ir: RX: 525 (pulse)
[ 4765.548280] IR: raw sample: 450 us (space)
[ 4765.548295] ene_ir: RX: 1575 (space)
[ 4765.548299] IR: raw sample: 525 us (pulse)
[ 4765.548309] ene_ir: RX: 525 (pulse)
[ 4765.548312] IR: raw sample: 1575 us (space)
[ 4765.548325] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.548329] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.548334] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.548339] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.548344] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.548349] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.548354] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.548359] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.548363] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.548368] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.548373] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.548380] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.548385] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.548390] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.548395] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.548400] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.548404] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.548409] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.548414] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.548418] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.548423] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.548429] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.548434] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.548439] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.548444] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.548449] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.548453] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.548458] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.548463] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.548467] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.548472] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.548477] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.548483] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.548488] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.548493] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.548498] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.548503] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.548507] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.548512] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.548517] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.548522] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.548527] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.548532] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.551393] ene_ir: RX: 450 (space)
[ 4765.551402] IR: raw sample: 525 us (pulse)
[ 4765.551418] ene_ir: RX: 525 (pulse)
[ 4765.551421] IR: raw sample: 450 us (space)
[ 4765.551432] ene_ir: RX: 1575 (space)
[ 4765.551435] IR: raw sample: 525 us (pulse)
[ 4765.551445] ene_ir: RX: 525 (pulse)
[ 4765.551449] IR: raw sample: 1575 us (space)
[ 4765.551459] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.551464] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.551469] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.551474] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.551479] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.551483] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.551488] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.551493] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.551498] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.551503] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.551507] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.551515] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.551519] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.551524] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.551529] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.551534] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.551538] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.551543] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.551548] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.551552] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.551557] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.551563] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.551568] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.551573] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.551578] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.551582] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.551587] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.551592] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.551596] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.551601] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.551606] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.551611] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.551617] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.551622] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.551627] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.551631] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.551636] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.551641] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.551646] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.551651] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.551655] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.551660] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.551665] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.554572] ene_ir: RX: 450 (space)
[ 4765.554576] IR: raw sample: 525 us (pulse)
[ 4765.554586] ene_ir: RX: 525 (pulse)
[ 4765.554594] IR: raw sample: 450 us (space)
[ 4765.554610] ene_ir: RX: 1575 (space)
[ 4765.554617] IR: raw sample: 525 us (pulse)
[ 4765.554633] ene_ir: RX: 525 (pulse)
[ 4765.554636] IR: raw sample: 1575 us (space)
[ 4765.554648] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.554653] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.554658] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.554663] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.554668] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.554673] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.554677] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.554682] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.554687] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.554691] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.554696] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.554704] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.554709] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.554713] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.554718] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.554723] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.554728] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.554732] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.554737] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.554742] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.554746] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.554753] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.554757] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.554762] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.554767] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.554772] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.554777] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.554781] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.554786] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.554790] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.554795] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.554800] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.554806] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.554811] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.554816] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.554820] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.554826] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.554830] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.554835] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.554840] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.554844] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.554849] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.554854] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.556660] ene_ir: RX: 450 (space)
[ 4765.556668] IR: raw sample: 525 us (pulse)
[ 4765.556683] ene_ir: RX: 525 (pulse)
[ 4765.556691] IR: raw sample: 450 us (space)
[ 4765.556706] ene_ir: RX: 450 (space)
[ 4765.556714] IR: raw sample: 525 us (pulse)
[ 4765.556729] ene_ir: RX: 525 (pulse)
[ 4765.556737] IR: raw sample: 450 us (space)
[ 4765.556753] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.556766] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.556779] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.556792] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.556805] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.556817] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.556830] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.556842] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.556855] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.556868] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.556881] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.556896] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.556909] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.556922] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.556937] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.556951] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.556965] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.556979] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.556994] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.557009] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.557025] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.557042] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.557057] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.557071] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.557085] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.557100] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.557115] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.557129] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.557142] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.557157] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.557172] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.557185] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.557199] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.557215] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.557229] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.557245] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.557261] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.557274] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.557290] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.557305] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.557319] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.557333] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.559814] ene_ir: RX: 1575 (space)
[ 4765.559823] IR: raw sample: 525 us (pulse)
[ 4765.559839] ene_ir: RX: 525 (pulse)
[ 4765.559847] IR: raw sample: 1575 us (space)
[ 4765.559862] ene_ir: RX: 450 (space)
[ 4765.559870] IR: raw sample: 525 us (pulse)
[ 4765.559885] ene_ir: RX: 525 (pulse)
[ 4765.559893] IR: raw sample: 450 us (space)
[ 4765.559911] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.559924] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.559937] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.559950] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.559963] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.559976] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.559989] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.560002] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.560016] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.560031] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.560045] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.560062] ir_nec_decode: NEC decode started at state 0 (1575us space)
[ 4765.560076] ir_nec_decode: NEC decode failed at state 0 (1575us space)
[ 4765.560089] ir_rc5_decode: RC5(x) decode started at state 1 (1575us space)
[ 4765.560104] ir_rc5_decode: RC5(x) decode failed at state 1 (1575us space)
[ 4765.560118] ir_rc6_decode: RC6 decode started at state 0 (1575us space)
[ 4765.560132] ir_rc6_decode: RC6 decode failed at state 0 (1575us space)
[ 4765.560146] ir_jvc_decode: JVC decode started at state 0 (1575us space)
[ 4765.560159] ir_jvc_decode: JVC decode failed at state 0 (1575us space)
[ 4765.560173] ir_sony_decode: Sony decode started at state 0 (1575us space)
[ 4765.560186] ir_sony_decode: Sony decode failed at state 0 (1575us space)
[ 4765.560200] ir_lirc_decode: LIRC data transfer started (1575us space)
[ 4765.560217] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.560229] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.560243] ir_rc5_decode: RC5(x) decode started at state 0 (525us pulse)
[ 4765.560256] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.560271] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.560284] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.560297] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.560311] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.560324] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.560338] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.560351] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.560368] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.560381] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.560394] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.560407] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.560422] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.560435] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.560449] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.560463] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.560477] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.560491] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.569966] ene_ir: RX: 450 (space)
[ 4765.569971] IR: raw sample: 525 us (pulse)
[ 4765.569981] ene_ir: RX: 525 (pulse)
[ 4765.569985] IR: raw sample: 450 us (space)
[ 4765.569995] ene_ir: RX: 9525 (space)
[ 4765.569998] IR: raw sample: 525 us (pulse)
[ 4765.570020] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.570025] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.570031] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.570036] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.570042] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.570047] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.570052] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.570057] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.570061] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.570066] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.570071] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.570079] ir_nec_decode: NEC decode started at state 0 (450us space)
[ 4765.570084] ir_nec_decode: NEC decode failed at state 0 (450us space)
[ 4765.570089] ir_rc5_decode: RC5(x) decode started at state 1 (450us space)
[ 4765.570094] ir_rc6_decode: RC6 decode started at state 0 (450us space)
[ 4765.570099] ir_rc6_decode: RC6 decode failed at state 0 (450us space)
[ 4765.570104] ir_jvc_decode: JVC decode started at state 0 (450us space)
[ 4765.570109] ir_jvc_decode: JVC decode failed at state 0 (450us space)
[ 4765.570114] ir_sony_decode: Sony decode started at state 0 (450us space)
[ 4765.570119] ir_sony_decode: Sony decode failed at state 0 (450us space)
[ 4765.570124] ir_lirc_decode: LIRC data transfer started (450us space)
[ 4765.570139] ir_nec_decode: NEC decode started at state 0 (525us pulse)
[ 4765.570139] ir_nec_decode: NEC decode failed at state 0 (525us pulse)
[ 4765.570141] ir_rc5_decode: RC5(x) decode started at state 2 (525us pulse)
[ 4765.570146] ir_rc5_decode: RC5(x) decode started at state 1 (0us pulse)
[ 4765.570151] ir_rc6_decode: RC6 decode started at state 0 (525us pulse)
[ 4765.570156] ir_rc6_decode: RC6 decode failed at state 0 (525us pulse)
[ 4765.570160] ir_jvc_decode: JVC decode started at state 0 (525us pulse)
[ 4765.570173] ir_jvc_decode: JVC decode failed at state 0 (525us pulse)
[ 4765.570173] ir_sony_decode: Sony decode started at state 0 (525us pulse)
[ 4765.570175] ir_sony_decode: Sony decode failed at state 0 (525us pulse)
[ 4765.570179] ir_lirc_decode: LIRC data transfer started (525us pulse)
[ 4765.579139] ene_ir: RX: 9525 (space)
[ 4765.588297] ene_ir: RX: 9525 (space)
[ 4765.597542] ene_ir: RX: 9525 (space)
[ 4765.606647] ene_ir: RX: 9525 (space)
[ 4765.615862] ene_ir: RX: 9525 (space)
[ 4765.625014] ene_ir: RX: 9525 (space)
[ 4765.634185] ene_ir: RX: 9525 (space)
[ 4765.643345] ene_ir: RX: 9525 (space)
[ 4765.652497] ene_ir: RX: 9525 (space)
[ 4765.661656] ene_ir: RX: 9525 (space)
[ 4765.670812] ene_ir: RX: 9525 (space)
[ 4765.679968] ene_ir: RX: 9525 (space)
[ 4765.689125] ene_ir: RX: 9525 (space)
[ 4765.698284] ene_ir: RX: 9525 (space)
[ 4765.707421] ene_ir: RX: 9525 (space)
[ 4765.716601] ene_ir: RX: 9525 (space)
[ 4765.725751] ene_ir: RX: 9525 (space)
[ 4765.734908] ene_ir: RX: 9525 (space)
[ 4765.744067] ene_ir: RX: 9525 (space)
[ 4765.755883] ene_ir: RX: 9525 (space)
[ 4765.762364] ene_ir: RX: 9525 (space)
[ 4765.771535] ene_ir: RX: 9525 (space)
[ 4765.780695] ene_ir: RX: 9525 (space)
[ 4765.789846] ene_ir: RX: 9525 (space)
[ 4765.799005] ene_ir: RX: 9525 (space)
[ 4765.808163] ene_ir: RX: 9525 (space)
[ 4765.808177] enter idle mode
[ 4765.808188] ene_ir: enabling idle mode
[ 4765.817306] ene_ir: RX: 9525 (space)
[-- Attachment #2: lircd.conf --]
[-- Type: text/plain, Size: 2527 bytes --]
# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.8.5(default) on Sun Aug 9 02:33:55 2009
#
# contributed by Maxim Levitsky
#
# brand: JVC
# model no. of remote control: LP20878-008
# devices being controlled by this remote: JVC VCR
#
begin remote
name JVC
bits 8
flags SPACE_ENC|NO_HEAD_REP|CONST_LENGTH
eps 30
aeps 100
header 8800 4416
one 565 1583
zero 565 485
ptrail 563
pre_data_bits 8
pre_data 0xC2
gap 44600
min_repeat 3
suppress_repeat 3
begin codes
# first and second row
KEY_POWER 0xD0
KEY_ESCAPE 0xC3
KEY_TV 0xC8
KEY_MUTE 0xE8
KEY_BACKSPACE 0x1C
# numbers - remapped to mouse
MOUSE_1 0x84
MOUSE_2 0x44
MOUSE_3 0xC4
MOUSE_4 0x24
MOUSE_5 0xA4
MOUSE_6 0x64
MOUSE_7 0xE4
MOUSE_8 0x14
MOUSE_9 0x94
MOUSE_X 0x6C
MOUSE_0 0xCC
MOUSE_CLOCK 0xAC
# start +-
MOUSE_DOWN 0x93
MOUSE_UP 0x13
# stop +-
KEY_VOLUMEDOWN 0xD3
KEY_VOLUMEUP 0x53
# date +-
KEY_BRIGHTNESSDOWN 0xE3
KEY_BRIGHTNESSUP 0x63
# row above play button - TODO
KEY_PROGRAM 0x83
KEY_SETUP 0xBC
KEY_SWITCHVIDEOMODE 0x8C
KEY_NEXT 0x69
# play block
KEY_PREVIOUSSONG 0xE0
KEY_PLAY 0x30
KEY_NEXTSONG 0x60
KEY_RECORD 0x33
KEY_STOP 0xC0
KEY_PAUSE 0xB0
# setup row
KEY_TAB 0xEC
KEY_ENTER 0x3C
# large bottom button
KEY_UP 0x98
KEY_DOWN 0x18
KEY_LEFT 0xA8
KEY_RIGHT 0x28
end codes
end remote
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-27 22:33 Can I expect in-kernel decoding to work out of box? Maxim Levitsky
@ 2010-07-27 23:32 ` Maxim Levitsky
2010-07-28 1:29 ` Jon Smirl
0 siblings, 1 reply; 33+ messages in thread
From: Maxim Levitsky @ 2010-07-27 23:32 UTC (permalink / raw)
To: Jarod Wilson; +Cc: Jon Smirl, linux-input, Mauro Carvalho Chehab
On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote:
> Hi,
>
> I ported my ene driver to in-kernel decoding.
> It isn't yet ready to be released, but in few days it will be.
>
> Now, knowing about wonders of in-kernel decoding, I try to use it, but
> it just doesn't work.
>
> Mind you that lircd works with this remote.
> (I attach my lircd.conf)
>
> Here is the output of mode2 for a single keypress:
Just want to add that I tested it with many different modes of my
remotes, and all but one fail (one mode is detected as NEC).
Don't get me wrong.
Although I opposed to idea of in-kernel decoding, lately I began to
think that this isn't such a bad idea.
Especially if number of users for whom it will work out of box.
So, I am very disappointed.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-27 23:32 ` Maxim Levitsky
@ 2010-07-28 1:29 ` Jon Smirl
2010-07-28 2:33 ` Jarod Wilson
0 siblings, 1 reply; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 1:29 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Jarod Wilson, linux-input, Mauro Carvalho Chehab
On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote:
>> Hi,
>>
>> I ported my ene driver to in-kernel decoding.
>> It isn't yet ready to be released, but in few days it will be.
>>
>> Now, knowing about wonders of in-kernel decoding, I try to use it, but
>> it just doesn't work.
>>
>> Mind you that lircd works with this remote.
>> (I attach my lircd.conf)
>>
>> Here is the output of mode2 for a single keypress:
8850 4350 525 1575 525 1575
525 450 525 450 525 450
525 450 525 1575 525 450
525 1575 525 450 525 1575
525 450 525 450 525 1575
525 450 525 450 525 23625
That decodes as:
1100 0010 1010 0100
In the NEC protocol the second word is supposed to be the inverse of
the first word and it isn't. The timing is too short for NEC protocol
too.
Valid NEC...
1100 0011 1010 0101
Maybe JVC protocol but it is longer than normal.
The JVC decoder was unable to get started decoding it. I don't think
the JVC decoder has been tested much. Take a look at it and see why it
couldn't get out of state 0.
>
> Just want to add that I tested it with many different modes of my
> remotes, and all but one fail (one mode is detected as NEC).
>
> Don't get me wrong.
> Although I opposed to idea of in-kernel decoding, lately I began to
> think that this isn't such a bad idea.
> Especially if number of users for whom it will work out of box.
>
> So, I am very disappointed.
>
> Best regards,
> Maxim Levitsky
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 1:29 ` Jon Smirl
@ 2010-07-28 2:33 ` Jarod Wilson
2010-07-28 6:30 ` Maxim Levitsky
0 siblings, 1 reply; 33+ messages in thread
From: Jarod Wilson @ 2010-07-28 2:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: Maxim Levitsky, linux-input, Mauro Carvalho Chehab, linux-media
On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote:
>>> Hi,
>>>
>>> I ported my ene driver to in-kernel decoding.
>>> It isn't yet ready to be released, but in few days it will be.
>>>
>>> Now, knowing about wonders of in-kernel decoding, I try to use it, but
>>> it just doesn't work.
>>>
>>> Mind you that lircd works with this remote.
>>> (I attach my lircd.conf)
>>>
>>> Here is the output of mode2 for a single keypress:
>
> 8850 4350 525 1575 525 1575
> 525 450 525 450 525 450
> 525 450 525 1575 525 450
> 525 1575 525 450 525 1575
> 525 450 525 450 525 1575
> 525 450 525 450 525 23625
>
> That decodes as:
> 1100 0010 1010 0100
>
> In the NEC protocol the second word is supposed to be the inverse of
> the first word and it isn't. The timing is too short for NEC protocol
> too.
>
> Valid NEC...
> 1100 0011 1010 0101
>
> Maybe JVC protocol but it is longer than normal.
>
> The JVC decoder was unable to get started decoding it. I don't think
> the JVC decoder has been tested much. Take a look at it and see why it
> couldn't get out of state 0.
Personally, I haven't really tried much of anything but RC-6(A) and
RC-5 while working on mceusb, so they're the only ones I can really
vouch for myself at the moment. It seems that I don't have many
remotes that aren't an RC-x variant, outside of universals, which I
have yet to get around to programming for various other modes to test
any of the protocol decoders. I assume that David Hardeman already did
that much before submitting each of the ir protocol decoders with his
name one them (which were, if I'm not mistaken, based at least
partially on Jon's earlier work), but its entirely possible there are
slight variants of each that aren't handled properly just yet. That
right there is one of the major reasons I saw for writing the lirc
bridge driver plugin in the first place -- the lirc userspace decoder
has been around for a LOT longer, and thus is likely to know how to
handle more widely varying IR signals.
--
Jarod Wilson
jarod@wilsonet.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 2:33 ` Jarod Wilson
@ 2010-07-28 6:30 ` Maxim Levitsky
2010-07-28 6:59 ` Maxim Levitsky
2010-07-28 10:40 ` Jon Smirl
0 siblings, 2 replies; 33+ messages in thread
From: Maxim Levitsky @ 2010-07-28 6:30 UTC (permalink / raw)
To: Jarod Wilson; +Cc: Jon Smirl, linux-input, Mauro Carvalho Chehab, linux-media
On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >> On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote:
> >>> Hi,
> >>>
> >>> I ported my ene driver to in-kernel decoding.
> >>> It isn't yet ready to be released, but in few days it will be.
> >>>
> >>> Now, knowing about wonders of in-kernel decoding, I try to use it, but
> >>> it just doesn't work.
> >>>
> >>> Mind you that lircd works with this remote.
> >>> (I attach my lircd.conf)
> >>>
> >>> Here is the output of mode2 for a single keypress:
> >
> > 8850 4350 525 1575 525 1575
> > 525 450 525 450 525 450
> > 525 450 525 1575 525 450
> > 525 1575 525 450 525 1575
> > 525 450 525 450 525 1575
> > 525 450 525 450 525 23625
> >
> > That decodes as:
> > 1100 0010 1010 0100
> >
> > In the NEC protocol the second word is supposed to be the inverse of
> > the first word and it isn't. The timing is too short for NEC protocol
> > too.
No its not, its just extended NEC.
This lirc generic config matches that output quite well:
NEC-short-pulse.conf:
begin remote
name NEC
bits 16
flags SPACE_ENC|CONST_LENGTH
eps 30
aeps 100
header 9000 4500
one 563 1687
zero 563 562
ptrail 563
pre_data_bits 16
# just a guess
gap 108000
repeat 9000 2250
frequency 38000
duty_cycle 33
begin codes
end codes
end remote
> >
> > Valid NEC...
> > 1100 0011 1010 0101
> >
> > Maybe JVC protocol but it is longer than normal.
> >
> > The JVC decoder was unable to get started decoding it. I don't think
> > the JVC decoder has been tested much. Take a look at it and see why it
> > couldn't get out of state 0.
>
> Personally, I haven't really tried much of anything but RC-6(A) and
> RC-5 while working on mceusb, so they're the only ones I can really
> vouch for myself at the moment. It seems that I don't have many
> remotes that aren't an RC-x variant, outside of universals, which I
> have yet to get around to programming for various other modes to test
> any of the protocol decoders. I assume that David Hardeman already did
> that much before submitting each of the ir protocol decoders with his
> name one them (which were, if I'm not mistaken, based at least
> partially on Jon's earlier work), but its entirely possible there are
> slight variants of each that aren't handled properly just yet. That
> right there is one of the major reasons I saw for writing the lirc
> bridge driver plugin in the first place -- the lirc userspace decoder
> has been around for a LOT longer, and thus is likely to know how to
> handle more widely varying IR signals.
In fact its dead easy to test a lot of remotes, by using an universal
remote. These remotes are designed to tech literate persons for a
reason....
On my remote, all I have to do is press TV + predefined number + OK to
make remote mimic a random remote.
Unill now, kernel decoding couldn't pick anything but one mode....
Here is a table I created long ago on my remote showing all kinds of
protocols there:
Heck, hardware isn't very accurate, I know, but streamzap receiver
according to what I have heard it even worse...
Best regards,
Maxim Levitsky
08 - NEC short pulse / SANYO (38 khz), [15 - NEC]
9440 4640 620 550 620 550 620 550 620 550 620 550
620 550 620 1720 610 550 610 1720 620 1720 620 1720
620 1720 610 1730 610 1720 620 550 620 1720 620 550
620 550 620 550 620 550 620 550 620 550 610 550
610 550 610 1720 620 1720 620 1720 620 1720 620 1720
610 1720 620 1720 620 1720 620 41540 9440 2300 620 100110
(9440 2300 610 100110)
---------------------------------------------------------------------------------------------------------------
02 - Philips (RC5): (36 khz)
990 890 970 890 1920 890 970 890 970 890 970 890
970 890 970 890 970 890 970 890 970 890 970 890
970 94190
---------------------------------------------------------------------------------------------------------------
25 - Philips (RECS-80): (38 khz)
200 7720 170 7720 170 7700 200 7690 200 7720 170 5090
160 7730 170 5090 170 5090 160 5090 170 5090 170
---------------------------------------------------------------------------------------------------------------
01 - JVC: (38 khz)
8840 4370 590 1600 590 1600 590 500 590 500 590 500
590 500 590 510 590 510 590 500 590 500 590 500
590 1600 590 500 590 1600 590 500 590 500 590 25730
---------------------------------------------------------------------------------------------------------------
07 - Sony (SIRC): (40 khz)
2550 600 1260 600 630 600 630 600 1260 600 630 600
630 600 630 600 1260 600 630 600 630 600 630 600
630 27450 <rep>
---------------------------------------------------------------------------------------------------------------
19 - MOTOROLLA:
610 2730 550 550 580 520 580 520 580 490 600 520
580 520 580 520 580 520 580 520 580 21240
(600 2720 580 1070 580 520 580 520 580 520 1130 1070
580 490 580 540 550 540 580 126890)
---------------------------------------------------------------------------------------------------------------
06 - Sharp (denon): (38 khz)
370 1870 340 750 340 760 340 750 340 750 340 750
340 1870 340 750 340 1870 340 760 340 760 340 760
340 760 340 1870 340 750 340 48940
370 1870 340 750 340 760 340 760 340 750 340 1870
340 750 340 1870 340 760 340 1870 340 1870 340 1870
340 1870 340 760 340 1870 340 44610
---------------------------------------------------------------------------------------------------------------
30 - Nokia NRC17:
580 2590 550 990 1100 490 550 480 550 480 550 480
550 480 550 490 550 480 550 480 550 490 550 480
550 490 550 480 550 480 550 480 550 20230
580 2580 560 990 550 490 1100 480 550 990 550 480
550 490 550 480 550 480 1100 990 1100 490 550 990
1100 990 550 84380
580 2580 550 990 550 490 1100 480 550 990 550 490
550 480 550 480 550 480 1100 990 1100 480 550 990
1100 990 550 84380
---------------------------------------------------------------------------------------------------------------
03 - Mitsubishi:
350 2220 320 2220 320 2220 320 950 320 950 340 920
320 2220 320 950 320 2220 320 950 350 920 320 2220
320 950 320 950 320 950 320 950 320 27630 <rep>
---------------------------------------------------------------------------------------------------------------
04 - Panasonic:
3600 3460 950 820 960 820 950 820 950 820 950 820
960 2570 960 820 950 820 950 2580 950 2580 950 820
950 2580 950 2580 950 2580 950 2580 950 2580 950 820
950 2580 950 2580 960 820 960 820 950 2570 960 39070
<rep>
---------------------------------------------------------------------------------------------------------------
11 - Panasonic:
3700 1780 490 410 500 1320 490 410 490 410 490 410
500 410 490 410 490 410 500 410 490 410 490 410
490 410 490 410 490 1320 490 410 500 410 490 410
490 410 490 410 500 410 490 410 490 410 500 410
490 1320 490 410 490 410 500 410 490 410 490 410
490 410 490 410 490 410 490 1320 500 410 490 410
490 1320 500 1310 500 410 490 410 490 410 490 1320
490 410 490 410 490 1320 490 1320 490 410 490 410
490 1320 500 <rep>
---------------------------------------------------------------------------------------------------------------
05 - unknown:
20950 4110 620 1990 590 2020 580 2020 580 2020 590 980
580 980 580 2020 590 2020 580 980 580 980 590 980
590 980 580 980 580 980 580 980 580 980 580 2020
580 2020 590 980 580 980 580 2020 590 2020 580 2020
580 2020 1070
---------------------------------------------------------------------------------------------------------------
09 - unknown:
590 480 560 4230 560 480 560 4230 560 5260 560 5260
560 480 560 4230 560 5260 560 480 560 4220 560 5260
560 480 560 4220 560 5260 560 480 560 126450 <rep>
---------------------------------------------------------------------------------------------------------------
12 - RCA?
4740 4650 620 1720 620 1720 620 1720 620 550 610 550
610 550 610 550 620 550 620 1720 620 1720 620 1720
620 550 620 550 620 550 620 550 620 550 620 1720
620 550 620 550 610 550 610 1730 610 550 610 550
610 550 620 550 620 1720 620 1720 620 1720 620 550
620 1720 620 1720 620 1720 620
---------------------------------------------------------------------------------------------------------------
26 - junk -(thomson) - unsuppored/no carrier
27 - junk -(unknown) - unsuppored/no carrier
28 - junk -ITT - unsuppored/no carrier
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 6:30 ` Maxim Levitsky
@ 2010-07-28 6:59 ` Maxim Levitsky
2010-07-28 10:40 ` Jon Smirl
1 sibling, 0 replies; 33+ messages in thread
From: Maxim Levitsky @ 2010-07-28 6:59 UTC (permalink / raw)
To: Jarod Wilson; +Cc: Jon Smirl, linux-input, Mauro Carvalho Chehab, linux-media
On Wed, 2010-07-28 at 09:30 +0300, Maxim Levitsky wrote:
> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
> > On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > >> On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote:
> > >>> Hi,
> > >>>
> > >>> I ported my ene driver to in-kernel decoding.
> > >>> It isn't yet ready to be released, but in few days it will be.
> > >>>
> > >>> Now, knowing about wonders of in-kernel decoding, I try to use it, but
> > >>> it just doesn't work.
> > >>>
> > >>> Mind you that lircd works with this remote.
> > >>> (I attach my lircd.conf)
> > >>>
> > >>> Here is the output of mode2 for a single keypress:
> > >
> > > 8850 4350 525 1575 525 1575
> > > 525 450 525 450 525 450
> > > 525 450 525 1575 525 450
> > > 525 1575 525 450 525 1575
> > > 525 450 525 450 525 1575
> > > 525 450 525 450 525 23625
> > >
> > > That decodes as:
> > > 1100 0010 1010 0100
> > >
> > > In the NEC protocol the second word is supposed to be the inverse of
> > > the first word and it isn't. The timing is too short for NEC protocol
> > > too.
> No its not, its just extended NEC.
>
> This lirc generic config matches that output quite well:
> NEC-short-pulse.conf:
>
> begin remote
>
> name NEC
> bits 16
> flags SPACE_ENC|CONST_LENGTH
> eps 30
> aeps 100
>
> header 9000 4500
> one 563 1687
> zero 563 562
> ptrail 563
> pre_data_bits 16
> # just a guess
> gap 108000
>
> repeat 9000 2250
>
> frequency 38000
> duty_cycle 33
>
> begin codes
> end codes
>
> end remote
>
>
>
> > >
> > > Valid NEC...
> > > 1100 0011 1010 0101
> > >
> > > Maybe JVC protocol but it is longer than normal.
> > >
> > > The JVC decoder was unable to get started decoding it. I don't think
> > > the JVC decoder has been tested much. Take a look at it and see why it
> > > couldn't get out of state 0.
Its not JVC I am sure.
> >
> > Personally, I haven't really tried much of anything but RC-6(A) and
> > RC-5 while working on mceusb, so they're the only ones I can really
> > vouch for myself at the moment. It seems that I don't have many
> > remotes that aren't an RC-x variant, outside of universals, which I
> > have yet to get around to programming for various other modes to test
> > any of the protocol decoders. I assume that David Hardeman already did
> > that much before submitting each of the ir protocol decoders with his
> > name one them (which were, if I'm not mistaken, based at least
> > partially on Jon's earlier work), but its entirely possible there are
> > slight variants of each that aren't handled properly just yet. That
> > right there is one of the major reasons I saw for writing the lirc
> > bridge driver plugin in the first place -- the lirc userspace decoder
> > has been around for a LOT longer, and thus is likely to know how to
> > handle more widely varying IR signals.
>
> In fact its dead easy to test a lot of remotes, by using an universal
> remote. These remotes are designed to tech literate persons for a
> reason....
I mean illiterate.
>
> On my remote, all I have to do is press TV + predefined number + OK to
> make remote mimic a random remote.
> Unill now, kernel decoding couldn't pick anything but one mode....
It does pick RC-5... it figures...
>
>
> Here is a table I created long ago on my remote showing all kinds of
> protocols there:
>
> Heck, hardware isn't very accurate, I know, but streamzap receiver
> according to what I have heard it even worse...
>
> Best regards,
> Maxim Levitsky
>
>
> 08 - NEC short pulse / SANYO (38 khz), [15 - NEC]
> 9440 4640 620 550 620 550 620 550 620 550 620 550
> 620 550 620 1720 610 550 610 1720 620 1720 620 1720
> 620 1720 610 1730 610 1720 620 550 620 1720 620 550
> 620 550 620 550 620 550 620 550 620 550 610 550
> 610 550 610 1720 620 1720 620 1720 620 1720 620 1720
> 610 1720 620 1720 620 1720 620 41540 9440 2300 620 100110
> (9440 2300 610 100110)
> ---------------------------------------------------------------------------------------------------------------
> 02 - Philips (RC5): (36 khz)
> 990 890 970 890 1920 890 970 890 970 890 970 890
> 970 890 970 890 970 890 970 890 970 890 970 890
> 970 94190
> ---------------------------------------------------------------------------------------------------------------
> 25 - Philips (RECS-80): (38 khz)
> 200 7720 170 7720 170 7700 200 7690 200 7720 170 5090
> 160 7730 170 5090 170 5090 160 5090 170 5090 170
> ---------------------------------------------------------------------------------------------------------------
> 01 - JVC: (38 khz)
> 8840 4370 590 1600 590 1600 590 500 590 500 590 500
> 590 500 590 510 590 510 590 500 590 500 590 500
> 590 1600 590 500 590 1600 590 500 590 500 590 25730
> ---------------------------------------------------------------------------------------------------------------
> 07 - Sony (SIRC): (40 khz)
> 2550 600 1260 600 630 600 630 600 1260 600 630 600
> 630 600 630 600 1260 600 630 600 630 600 630 600
> 630 27450 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 19 - MOTOROLLA:
> 610 2730 550 550 580 520 580 520 580 490 600 520
> 580 520 580 520 580 520 580 520 580 21240
>
> (600 2720 580 1070 580 520 580 520 580 520 1130 1070
> 580 490 580 540 550 540 580 126890)
> ---------------------------------------------------------------------------------------------------------------
> 06 - Sharp (denon): (38 khz)
> 370 1870 340 750 340 760 340 750 340 750 340 750
> 340 1870 340 750 340 1870 340 760 340 760 340 760
> 340 760 340 1870 340 750 340 48940
>
> 370 1870 340 750 340 760 340 760 340 750 340 1870
> 340 750 340 1870 340 760 340 1870 340 1870 340 1870
> 340 1870 340 760 340 1870 340 44610
> ---------------------------------------------------------------------------------------------------------------
> 30 - Nokia NRC17:
> 580 2590 550 990 1100 490 550 480 550 480 550 480
> 550 480 550 490 550 480 550 480 550 490 550 480
> 550 490 550 480 550 480 550 480 550 20230
>
> 580 2580 560 990 550 490 1100 480 550 990 550 480
> 550 490 550 480 550 480 1100 990 1100 490 550 990
> 1100 990 550 84380
>
> 580 2580 550 990 550 490 1100 480 550 990 550 490
> 550 480 550 480 550 480 1100 990 1100 480 550 990
> 1100 990 550 84380
> ---------------------------------------------------------------------------------------------------------------
> 03 - Mitsubishi:
> 350 2220 320 2220 320 2220 320 950 320 950 340 920
> 320 2220 320 950 320 2220 320 950 350 920 320 2220
> 320 950 320 950 320 950 320 950 320 27630 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 04 - Panasonic:
> 3600 3460 950 820 960 820 950 820 950 820 950 820
> 960 2570 960 820 950 820 950 2580 950 2580 950 820
> 950 2580 950 2580 950 2580 950 2580 950 2580 950 820
> 950 2580 950 2580 960 820 960 820 950 2570 960 39070
> <rep>
> ---------------------------------------------------------------------------------------------------------------
> 11 - Panasonic:
> 3700 1780 490 410 500 1320 490 410 490 410 490 410
> 500 410 490 410 490 410 500 410 490 410 490 410
> 490 410 490 410 490 1320 490 410 500 410 490 410
> 490 410 490 410 500 410 490 410 490 410 500 410
> 490 1320 490 410 490 410 500 410 490 410 490 410
> 490 410 490 410 490 410 490 1320 500 410 490 410
> 490 1320 500 1310 500 410 490 410 490 410 490 1320
> 490 410 490 410 490 1320 490 1320 490 410 490 410
> 490 1320 500 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 05 - unknown:
> 20950 4110 620 1990 590 2020 580 2020 580 2020 590 980
> 580 980 580 2020 590 2020 580 980 580 980 590 980
> 590 980 580 980 580 980 580 980 580 980 580 2020
> 580 2020 590 980 580 980 580 2020 590 2020 580 2020
> 580 2020 1070
> ---------------------------------------------------------------------------------------------------------------
> 09 - unknown:
> 590 480 560 4230 560 480 560 4230 560 5260 560 5260
> 560 480 560 4230 560 5260 560 480 560 4220 560 5260
> 560 480 560 4220 560 5260 560 480 560 126450 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 12 - RCA?
> 4740 4650 620 1720 620 1720 620 1720 620 550 610 550
> 610 550 610 550 620 550 620 1720 620 1720 620 1720
> 620 550 620 550 620 550 620 550 620 550 620 1720
> 620 550 620 550 610 550 610 1730 610 550 610 550
> 610 550 620 550 620 1720 620 1720 620 1720 620 550
> 620 1720 620 1720 620 1720 620
> ---------------------------------------------------------------------------------------------------------------
> 26 - junk -(thomson) - unsuppored/no carrier
> 27 - junk -(unknown) - unsuppored/no carrier
> 28 - junk -ITT - unsuppored/no carrier
>
>
>
>
>
> >
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 6:30 ` Maxim Levitsky
2010-07-28 6:59 ` Maxim Levitsky
@ 2010-07-28 10:40 ` Jon Smirl
2010-07-28 13:13 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 10:40 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Jarod Wilson, linux-input, Mauro Carvalho Chehab, linux-media
On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> >> On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote:
>> >>> Hi,
>> >>>
>> >>> I ported my ene driver to in-kernel decoding.
>> >>> It isn't yet ready to be released, but in few days it will be.
>> >>>
>> >>> Now, knowing about wonders of in-kernel decoding, I try to use it, but
>> >>> it just doesn't work.
>> >>>
>> >>> Mind you that lircd works with this remote.
>> >>> (I attach my lircd.conf)
>> >>>
>> >>> Here is the output of mode2 for a single keypress:
>> >
>> > 8850 4350 525 1575 525 1575
>> > 525 450 525 450 525 450
>> > 525 450 525 1575 525 450
>> > 525 1575 525 450 525 1575
>> > 525 450 525 450 525 1575
>> > 525 450 525 450 525 23625
>> >
>> > That decodes as:
>> > 1100 0010 1010 0100
>> >
>> > In the NEC protocol the second word is supposed to be the inverse of
>> > the first word and it isn't. The timing is too short for NEC protocol
>> > too.
> No its not, its just extended NEC.
http://www.sbprojects.com/knowledge/ir/nec.htm
Says the last two bytes should be the complement of each other.
So for extended NEC it would need to be:
1100 0010 1010 0101 instead of 1100 0010 1010 0100
The last bit is wrong.
From the debug output it is decoding as NEC, but then it fails a
consistency check. Maybe we need to add a new protocol that lets NEC
commands through even if they fail the error checks. It may also be
that the NEC machine rejected it because the timing was so far off
that it concluded that it couldn't be a NEC messages. The log didn't
include the exact reason it got rejected. Add some printks at the end
of the NEC machine to determine the exact reason for rejection.
The current state machines enforce protocol compliance so there are
probably a lot of older remotes that won't decode right. We can use
some help in adjusting the state machines to let out of spec codes
through.
The timing of those pulses is exactly right for JVC. Maybe there is an
extended 4 byte version of the JVC protocol. JVC doesn't have the
error checks like NEC. The question here is, why didn't the JVC
machine get started?
User space lirc is much older. Bugs like this have been worked out of
it. It will take some time to get the kernel implementation up to the
same level.
>
> This lirc generic config matches that output quite well:
> NEC-short-pulse.conf:
>
> begin remote
>
> name NEC
> bits 16
> flags SPACE_ENC|CONST_LENGTH
> eps 30
> aeps 100
>
> header 9000 4500
> one 563 1687
> zero 563 562
> ptrail 563
> pre_data_bits 16
> # just a guess
> gap 108000
>
> repeat 9000 2250
>
> frequency 38000
> duty_cycle 33
>
> begin codes
> end codes
>
> end remote
>
>
>
>> >
>> > Valid NEC...
>> > 1100 0011 1010 0101
>> >
>> > Maybe JVC protocol but it is longer than normal.
>> >
>> > The JVC decoder was unable to get started decoding it. I don't think
>> > the JVC decoder has been tested much. Take a look at it and see why it
>> > couldn't get out of state 0.
>>
>> Personally, I haven't really tried much of anything but RC-6(A) and
>> RC-5 while working on mceusb, so they're the only ones I can really
>> vouch for myself at the moment. It seems that I don't have many
>> remotes that aren't an RC-x variant, outside of universals, which I
>> have yet to get around to programming for various other modes to test
>> any of the protocol decoders. I assume that David Hardeman already did
>> that much before submitting each of the ir protocol decoders with his
>> name one them (which were, if I'm not mistaken, based at least
>> partially on Jon's earlier work), but its entirely possible there are
>> slight variants of each that aren't handled properly just yet. That
>> right there is one of the major reasons I saw for writing the lirc
>> bridge driver plugin in the first place -- the lirc userspace decoder
>> has been around for a LOT longer, and thus is likely to know how to
>> handle more widely varying IR signals.
>
> In fact its dead easy to test a lot of remotes, by using an universal
> remote. These remotes are designed to tech literate persons for a
> reason....
>
> On my remote, all I have to do is press TV + predefined number + OK to
> make remote mimic a random remote.
> Unill now, kernel decoding couldn't pick anything but one mode....
>
>
> Here is a table I created long ago on my remote showing all kinds of
> protocols there:
>
> Heck, hardware isn't very accurate, I know, but streamzap receiver
> according to what I have heard it even worse...
>
> Best regards,
> Maxim Levitsky
>
>
> 08 - NEC short pulse / SANYO (38 khz), [15 - NEC]
> 9440 4640 620 550 620 550 620 550 620 550 620 550
> 620 550 620 1720 610 550 610 1720 620 1720 620 1720
> 620 1720 610 1730 610 1720 620 550 620 1720 620 550
> 620 550 620 550 620 550 620 550 620 550 610 550
> 610 550 610 1720 620 1720 620 1720 620 1720 620 1720
> 610 1720 620 1720 620 1720 620 41540 9440 2300 620 100110
> (9440 2300 610 100110)
> ---------------------------------------------------------------------------------------------------------------
> 02 - Philips (RC5): (36 khz)
> 990 890 970 890 1920 890 970 890 970 890 970 890
> 970 890 970 890 970 890 970 890 970 890 970 890
> 970 94190
> ---------------------------------------------------------------------------------------------------------------
> 25 - Philips (RECS-80): (38 khz)
> 200 7720 170 7720 170 7700 200 7690 200 7720 170 5090
> 160 7730 170 5090 170 5090 160 5090 170 5090 170
> ---------------------------------------------------------------------------------------------------------------
> 01 - JVC: (38 khz)
> 8840 4370 590 1600 590 1600 590 500 590 500 590 500
> 590 500 590 510 590 510 590 500 590 500 590 500
> 590 1600 590 500 590 1600 590 500 590 500 590 25730
> ---------------------------------------------------------------------------------------------------------------
> 07 - Sony (SIRC): (40 khz)
> 2550 600 1260 600 630 600 630 600 1260 600 630 600
> 630 600 630 600 1260 600 630 600 630 600 630 600
> 630 27450 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 19 - MOTOROLLA:
> 610 2730 550 550 580 520 580 520 580 490 600 520
> 580 520 580 520 580 520 580 520 580 21240
>
> (600 2720 580 1070 580 520 580 520 580 520 1130 1070
> 580 490 580 540 550 540 580 126890)
> ---------------------------------------------------------------------------------------------------------------
> 06 - Sharp (denon): (38 khz)
> 370 1870 340 750 340 760 340 750 340 750 340 750
> 340 1870 340 750 340 1870 340 760 340 760 340 760
> 340 760 340 1870 340 750 340 48940
>
> 370 1870 340 750 340 760 340 760 340 750 340 1870
> 340 750 340 1870 340 760 340 1870 340 1870 340 1870
> 340 1870 340 760 340 1870 340 44610
> ---------------------------------------------------------------------------------------------------------------
> 30 - Nokia NRC17:
> 580 2590 550 990 1100 490 550 480 550 480 550 480
> 550 480 550 490 550 480 550 480 550 490 550 480
> 550 490 550 480 550 480 550 480 550 20230
>
> 580 2580 560 990 550 490 1100 480 550 990 550 480
> 550 490 550 480 550 480 1100 990 1100 490 550 990
> 1100 990 550 84380
>
> 580 2580 550 990 550 490 1100 480 550 990 550 490
> 550 480 550 480 550 480 1100 990 1100 480 550 990
> 1100 990 550 84380
> ---------------------------------------------------------------------------------------------------------------
> 03 - Mitsubishi:
> 350 2220 320 2220 320 2220 320 950 320 950 340 920
> 320 2220 320 950 320 2220 320 950 350 920 320 2220
> 320 950 320 950 320 950 320 950 320 27630 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 04 - Panasonic:
> 3600 3460 950 820 960 820 950 820 950 820 950 820
> 960 2570 960 820 950 820 950 2580 950 2580 950 820
> 950 2580 950 2580 950 2580 950 2580 950 2580 950 820
> 950 2580 950 2580 960 820 960 820 950 2570 960 39070
> <rep>
> ---------------------------------------------------------------------------------------------------------------
> 11 - Panasonic:
> 3700 1780 490 410 500 1320 490 410 490 410 490 410
> 500 410 490 410 490 410 500 410 490 410 490 410
> 490 410 490 410 490 1320 490 410 500 410 490 410
> 490 410 490 410 500 410 490 410 490 410 500 410
> 490 1320 490 410 490 410 500 410 490 410 490 410
> 490 410 490 410 490 410 490 1320 500 410 490 410
> 490 1320 500 1310 500 410 490 410 490 410 490 1320
> 490 410 490 410 490 1320 490 1320 490 410 490 410
> 490 1320 500 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 05 - unknown:
> 20950 4110 620 1990 590 2020 580 2020 580 2020 590 980
> 580 980 580 2020 590 2020 580 980 580 980 590 980
> 590 980 580 980 580 980 580 980 580 980 580 2020
> 580 2020 590 980 580 980 580 2020 590 2020 580 2020
> 580 2020 1070
> ---------------------------------------------------------------------------------------------------------------
> 09 - unknown:
> 590 480 560 4230 560 480 560 4230 560 5260 560 5260
> 560 480 560 4230 560 5260 560 480 560 4220 560 5260
> 560 480 560 4220 560 5260 560 480 560 126450 <rep>
> ---------------------------------------------------------------------------------------------------------------
> 12 - RCA?
> 4740 4650 620 1720 620 1720 620 1720 620 550 610 550
> 610 550 610 550 620 550 620 1720 620 1720 620 1720
> 620 550 620 550 620 550 620 550 620 550 620 1720
> 620 550 620 550 610 550 610 1730 610 550 610 550
> 610 550 620 550 620 1720 620 1720 620 1720 620 550
> 620 1720 620 1720 620 1720 620
> ---------------------------------------------------------------------------------------------------------------
> 26 - junk -(thomson) - unsuppored/no carrier
> 27 - junk -(unknown) - unsuppored/no carrier
> 28 - junk -ITT - unsuppored/no carrier
>
>
>
>
>
>>
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 10:40 ` Jon Smirl
@ 2010-07-28 13:13 ` Mauro Carvalho Chehab
2010-07-28 13:46 ` Jon Smirl
2010-07-28 14:24 ` Maxim Levitsky
0 siblings, 2 replies; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 13:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: Maxim Levitsky, Jarod Wilson, linux-input, linux-media
Em 28-07-2010 07:40, Jon Smirl escreveu:
> On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
>>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> No its not, its just extended NEC.
>
> http://www.sbprojects.com/knowledge/ir/nec.htm
> Says the last two bytes should be the complement of each other.
>
> So for extended NEC it would need to be:
> 1100 0010 1010 0101 instead of 1100 0010 1010 0100
> The last bit is wrong.
>
> From the debug output it is decoding as NEC, but then it fails a
> consistency check. Maybe we need to add a new protocol that lets NEC
> commands through even if they fail the error checks.
Assuming that Maxim's IR receiver is not causing some bad decode at the
NEC code, it seems simpler to add a parameter at sysfs to relax the NEC
detection. We should add some way, at the userspace table for those RC's
that uses a NEC-like code.
There's another alternative: currently, the NEC decoder produces a 16 bits
code for NEC and a 24 bits for NEC-extended code. The decoder may return a
32 bits code when none of the checksum's match the NEC or NEC-extended standard.
Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so
there's no risk of generating a wrong keycode, if the wrong consistent check
is due to a reception error.
Btw, we still need to port rc core to use the new tables ioctl's, as cleaning
all keycodes on a 32 bits table would take forever with the current input
events ioctls.
> It may also be
> that the NEC machine rejected it because the timing was so far off
> that it concluded that it couldn't be a NEC messages. The log didn't
> include the exact reason it got rejected. Add some printks at the end
> of the NEC machine to determine the exact reason for rejection.
The better is to discard the possibility of a timing issue before changing
the decoder to accept NEC-like codes without consistency checks.
> The current state machines enforce protocol compliance so there are
> probably a lot of older remotes that won't decode right. We can use
> some help in adjusting the state machines to let out of spec codes
> through.
Yes, but we should take some care to avoid having another protocol decoder to
interpret badly a different protocol. So, I think that the decoders may have
some sysfs nodes to tweak the decoders to accept those older remotes.
We'll need a consistent way to add some logic at the remotes keycodes used by
ir-keycode, in order to allow it to tweak the decoder when a keycode table for
such remote is loaded into the driver.
> User space lirc is much older. Bugs like this have been worked out of
> it. It will take some time to get the kernel implementation up to the
> same level.
True.
Cheers,
Mauro
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 13:13 ` Mauro Carvalho Chehab
@ 2010-07-28 13:46 ` Jon Smirl
2010-07-28 14:38 ` Andy Walls
2010-07-28 14:24 ` Maxim Levitsky
1 sibling, 1 reply; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 13:46 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Maxim Levitsky, Jarod Wilson, linux-input, linux-media
Let's be really sure it is NEC and not JVC.
> > 8850 4350 525 1575 525 1575
> > 525 450 525 450 525 450
> > 525 450 525 1575 525 450
> > 525 1575 525 450 525 1575
> > 525 450 525 450 525 1575
> > 525 450 525 450 525 23625
NEC timings are 9000 4500 560 1680 560 560 etc
JVC timings are 8400 4200 525 1575 525 525
It is a closer match to the JVC timing. But neither protocol uses a
different mark/space timing -- 450 vs 525
Also look at the repeats. This is repeating at about 25ms. NEC repeat
spacing is 110ms. JVC is supposed to be at 50-60ms. NEC does not
repeat the entire command and JVC does. The repeats are closer to
following the JVC model.
I'd say this is a JVC command. So the question is, why didn't JVC
decoder get out of state zero?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 13:13 ` Mauro Carvalho Chehab
2010-07-28 13:46 ` Jon Smirl
@ 2010-07-28 14:24 ` Maxim Levitsky
2010-07-28 14:41 ` Jon Smirl
2010-07-28 21:01 ` Maxim Levitsky
1 sibling, 2 replies; 33+ messages in thread
From: Maxim Levitsky @ 2010-07-28 14:24 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Jon Smirl, Jarod Wilson, linux-input, linux-media
On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote:
> Em 28-07-2010 07:40, Jon Smirl escreveu:
> > On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
> >>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> >> No its not, its just extended NEC.
> >
> > http://www.sbprojects.com/knowledge/ir/nec.htm
> > Says the last two bytes should be the complement of each other.
> >
> > So for extended NEC it would need to be:
> > 1100 0010 1010 0101 instead of 1100 0010 1010 0100
> > The last bit is wrong.
> >
> > From the debug output it is decoding as NEC, but then it fails a
> > consistency check. Maybe we need to add a new protocol that lets NEC
> > commands through even if they fail the error checks.
>
> Assuming that Maxim's IR receiver is not causing some bad decode at the
> NEC code, it seems simpler to add a parameter at sysfs to relax the NEC
> detection. We should add some way, at the userspace table for those RC's
> that uses a NEC-like code.
>
> There's another alternative: currently, the NEC decoder produces a 16 bits
> code for NEC and a 24 bits for NEC-extended code. The decoder may return a
> 32 bits code when none of the checksum's match the NEC or NEC-extended standard.
>
> Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so
> there's no risk of generating a wrong keycode, if the wrong consistent check
> is due to a reception error.
>
> Btw, we still need to port rc core to use the new tables ioctl's, as cleaning
> all keycodes on a 32 bits table would take forever with the current input
> events ioctls.
>
> > It may also be
> > that the NEC machine rejected it because the timing was so far off
> > that it concluded that it couldn't be a NEC messages. The log didn't
> > include the exact reason it got rejected. Add some printks at the end
> > of the NEC machine to determine the exact reason for rejection.
>
> The better is to discard the possibility of a timing issue before changing
> the decoder to accept NEC-like codes without consistency checks.
>
> > The current state machines enforce protocol compliance so there are
> > probably a lot of older remotes that won't decode right. We can use
> > some help in adjusting the state machines to let out of spec codes
> > through.
>
> Yes, but we should take some care to avoid having another protocol decoder to
> interpret badly a different protocol. So, I think that the decoders may have
> some sysfs nodes to tweak the decoders to accept those older remotes.
>
> We'll need a consistent way to add some logic at the remotes keycodes used by
> ir-keycode, in order to allow it to tweak the decoder when a keycode table for
> such remote is loaded into the driver.
>
> > User space lirc is much older. Bugs like this have been worked out of
> > it. It will take some time to get the kernel implementation up to the
> > same level.
>
> True.
I more or less got to the bottom of this.
It turns out that ENE reciever has a non linear measurement error.
That is the longer sample is, the larger error it contains.
Substracting around 4% from the samples makes the output look much more
standard compliant.
You are right that my remote has JVC protocol. (at least I am sure now
it hasn't NEC, because repeat looks differently).
My remote now actually partially works with JVC decoder, it decodes
every other keypress.
Still, no repeat is supported.
However, all recievers (and transmitters) aren't perfect.
Thats why I prefer lirc, because it makes no assumptions about protocol,
so it can be 'trained' to work with any remote, and under very large
range of error tolerances.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 13:46 ` Jon Smirl
@ 2010-07-28 14:38 ` Andy Walls
2010-07-28 14:53 ` Jon Smirl
0 siblings, 1 reply; 33+ messages in thread
From: Andy Walls @ 2010-07-28 14:38 UTC (permalink / raw)
To: Jon Smirl
Cc: Mauro Carvalho Chehab, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
> Let's be really sure it is NEC and not JVC.
>
> > > 8850 4350 525 1575 525 1575
> > > 525 450 525 450 525 450
> > > 525 450 525 1575 525 450
> > > 525 1575 525 450 525 1575
> > > 525 450 525 450 525 1575
> > > 525 450 525 450 525 23625
>
>
> NEC timings are 9000 4500 560 1680 560 560 etc
>
> JVC timings are 8400 4200 525 1575 525 525
>
> It is a closer match to the JVC timing. But neither protocol uses a
> different mark/space timing -- 450 vs 525
I assume you mean "different mark/space timing for the symbol for which
they are the same length" (in NEC that's the '0' symbol IIRC).
I've noticed different mark/space timings for the '0' symbol from NEC
remotes and with some RC-5 remotes. I usually attribute it to cheap
remote designs, weak batteries, capacitive effects, receiver pulse
measurement technique, etc.
Here's an example of NEC remote from a DTV STB remote as measured by the
CX23888 IR receiver on an HVR-1850:
8257296 ns mark
4206185 ns space
leader
482926 ns mark
545296 ns space
0
481296 ns mark
1572259 ns space
1
481148 ns mark
546333 ns space
0
479963 ns mark
551815 ns space
0
454333 ns mark
1615519 ns space
1
435074 ns mark
591370 ns space
[...]
I don't know the source of the error. I would have to check the same
remote against my MCE USB receiver to try and determine any receiver
induced measurement errors.
But, in Maxim's case, the difference isn't bad: 450/525 ~= 86%. I would
hope a 15% difference would still be recognizable.
> Also look at the repeats. This is repeating at about 25ms. NEC repeat
> spacing is 110ms. JVC is supposed to be at 50-60ms. NEC does not
> repeat the entire command and JVC does. The repeats are closer to
> following the JVC model.
>
> I'd say this is a JVC command. So the question is, why didn't JVC
> decoder get out of state zero?
Is JVC enabled by default? I recall analyzing that it could generate
false positives on NEC codes.
Regards,
Andy
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 14:24 ` Maxim Levitsky
@ 2010-07-28 14:41 ` Jon Smirl
2010-07-28 15:18 ` Jarod Wilson
2010-07-28 15:56 ` Mauro Carvalho Chehab
2010-07-28 21:01 ` Maxim Levitsky
1 sibling, 2 replies; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 14:41 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Mauro Carvalho Chehab, Jarod Wilson, linux-input, linux-media
On Wed, Jul 28, 2010 at 10:24 AM, Maxim Levitsky
<maximlevitsky@gmail.com> wrote:
> On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote:
>> Em 28-07-2010 07:40, Jon Smirl escreveu:
>> > On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> >> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
>> >>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>
>> >> No its not, its just extended NEC.
>> >
>> > http://www.sbprojects.com/knowledge/ir/nec.htm
>> > Says the last two bytes should be the complement of each other.
>> >
>> > So for extended NEC it would need to be:
>> > 1100 0010 1010 0101 instead of 1100 0010 1010 0100
>> > The last bit is wrong.
>> >
>> > From the debug output it is decoding as NEC, but then it fails a
>> > consistency check. Maybe we need to add a new protocol that lets NEC
>> > commands through even if they fail the error checks.
>>
>> Assuming that Maxim's IR receiver is not causing some bad decode at the
>> NEC code, it seems simpler to add a parameter at sysfs to relax the NEC
>> detection. We should add some way, at the userspace table for those RC's
>> that uses a NEC-like code.
>>
>> There's another alternative: currently, the NEC decoder produces a 16 bits
>> code for NEC and a 24 bits for NEC-extended code. The decoder may return a
>> 32 bits code when none of the checksum's match the NEC or NEC-extended standard.
>>
>> Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so
>> there's no risk of generating a wrong keycode, if the wrong consistent check
>> is due to a reception error.
>>
>> Btw, we still need to port rc core to use the new tables ioctl's, as cleaning
>> all keycodes on a 32 bits table would take forever with the current input
>> events ioctls.
>>
>> > It may also be
>> > that the NEC machine rejected it because the timing was so far off
>> > that it concluded that it couldn't be a NEC messages. The log didn't
>> > include the exact reason it got rejected. Add some printks at the end
>> > of the NEC machine to determine the exact reason for rejection.
>>
>> The better is to discard the possibility of a timing issue before changing
>> the decoder to accept NEC-like codes without consistency checks.
>>
>> > The current state machines enforce protocol compliance so there are
>> > probably a lot of older remotes that won't decode right. We can use
>> > some help in adjusting the state machines to let out of spec codes
>> > through.
>>
>> Yes, but we should take some care to avoid having another protocol decoder to
>> interpret badly a different protocol. So, I think that the decoders may have
>> some sysfs nodes to tweak the decoders to accept those older remotes.
>>
>> We'll need a consistent way to add some logic at the remotes keycodes used by
>> ir-keycode, in order to allow it to tweak the decoder when a keycode table for
>> such remote is loaded into the driver.
>>
>> > User space lirc is much older. Bugs like this have been worked out of
>> > it. It will take some time to get the kernel implementation up to the
>> > same level.
>>
>> True.
>
>
> I more or less got to the bottom of this.
>
>
> It turns out that ENE reciever has a non linear measurement error.
> That is the longer sample is, the larger error it contains.
> Substracting around 4% from the samples makes the output look much more
> standard compliant.
Most of the protocols are arranged using power of two timings.
For example 562.5, 1125, 2250, 4500, 9000 -- NEC
525, 1050, 2100, 4200, 8400 - JVC
The decoders are designed to be much more sensitive to the power of
two relationship than the exact timing. Your non-linear error messed
up the relationship.
>
> You are right that my remote has JVC protocol. (at least I am sure now
> it hasn't NEC, because repeat looks differently).
>
> My remote now actually partially works with JVC decoder, it decodes
> every other keypress.
>
> Still, no repeat is supported.
It probably isn't implemented yet. Jarod has been focusing more on
getting the basic decoders to work.
> However, all recievers (and transmitters) aren't perfect.
> Thats why I prefer lirc, because it makes no assumptions about protocol,
> so it can be 'trained' to work with any remote, and under very large
> range of error tolerances.
It's possible to build a Linux IR decoder engine that can be loaded
with the old LIRC config files. But before doing this we should work
on getting all of the errors out of the standard decoders.
>
> Best regards,
> Maxim Levitsky
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 14:38 ` Andy Walls
@ 2010-07-28 14:53 ` Jon Smirl
2010-07-28 15:42 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 14:53 UTC (permalink / raw)
To: Andy Walls
Cc: Mauro Carvalho Chehab, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
>> Let's be really sure it is NEC and not JVC.
>>
>> > > 8850 4350 525 1575 525 1575
>> > > 525 450 525 450 525 450
>> > > 525 450 525 1575 525 450
>> > > 525 1575 525 450 525 1575
>> > > 525 450 525 450 525 1575
>> > > 525 450 525 450 525 23625
>>
>>
>> NEC timings are 9000 4500 560 1680 560 560 etc
>>
>> JVC timings are 8400 4200 525 1575 525 525
>>
>> It is a closer match to the JVC timing. But neither protocol uses a
>> different mark/space timing -- 450 vs 525
>
> I assume you mean "different mark/space timing for the symbol for which
> they are the same length" (in NEC that's the '0' symbol IIRC).
>
>
> I've noticed different mark/space timings for the '0' symbol from NEC
> remotes and with some RC-5 remotes. I usually attribute it to cheap
> remote designs, weak batteries, capacitive effects, receiver pulse
> measurement technique, etc.
>
> Here's an example of NEC remote from a DTV STB remote as measured by the
> CX23888 IR receiver on an HVR-1850:
>
> 8257296 ns mark
> 4206185 ns space
> leader
> 482926 ns mark
> 545296 ns space
> 0
> 481296 ns mark
> 1572259 ns space
> 1
> 481148 ns mark
> 546333 ns space
> 0
> 479963 ns mark
> 551815 ns space
> 0
> 454333 ns mark
> 1615519 ns space
> 1
> 435074 ns mark
> 591370 ns space
> [...]
>
> I don't know the source of the error. I would have to check the same
> remote against my MCE USB receiver to try and determine any receiver
> induced measurement errors.
>
> But, in Maxim's case, the difference isn't bad: 450/525 ~= 86%. I would
> hope a 15% difference would still be recognizable.
The error can't exceed 50% of a bit time. Bit time in JVC is 525us.
The error in the first 1 was 8850 - 8400 = 450us. That's almost a
whole bit.
You have to have the 50% of bit time rule. That's the rule that lets
you tell JVC from NEC. The 450us error in the 8850us number was enough
to switch the engine from JVC to NEC. NEC bits are longer, the leading
1 triggered the NEC engine instead of the JVC one.
450/525us didn't disrupt the decode process it is under a 50% bit error.
>
>
>> Also look at the repeats. This is repeating at about 25ms. NEC repeat
>> spacing is 110ms. JVC is supposed to be at 50-60ms. NEC does not
>> repeat the entire command and JVC does. The repeats are closer to
>> following the JVC model.
>>
>> I'd say this is a JVC command. So the question is, why didn't JVC
>> decoder get out of state zero?
>
> Is JVC enabled by default? I recall analyzing that it could generate
> false positives on NEC codes.
Hopefully the engines should differentiate the two. If the signal is
really messed up it may trigger a response from both engines. That
shouldn't be fatal at the higher layers, the wrong protocol would just
be ignored.
I recommend that all decoders initially follow the strict protocol
rules. That will let us find bugs like this one in the ENE driver.
After we get everything possible working under the strict rules we can
loosen then up to allow out of spec devices. We might even end up with
an IR-quirk driver that supports broken remotes.
>
> Regards,
> Andy
>
>
--
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 14:41 ` Jon Smirl
@ 2010-07-28 15:18 ` Jarod Wilson
2010-07-28 15:56 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 33+ messages in thread
From: Jarod Wilson @ 2010-07-28 15:18 UTC (permalink / raw)
To: Jon Smirl
Cc: Maxim Levitsky, Mauro Carvalho Chehab, Jarod Wilson, linux-input,
linux-media
On Wed, Jul 28, 2010 at 10:41:27AM -0400, Jon Smirl wrote:
> On Wed, Jul 28, 2010 at 10:24 AM, Maxim Levitsky
...
> > You are right that my remote has JVC protocol. (at least I am sure now
> > it hasn't NEC, because repeat looks differently).
> >
> > My remote now actually partially works with JVC decoder, it decodes
> > every other keypress.
> >
> > Still, no repeat is supported.
>
> It probably isn't implemented yet. Jarod has been focusing more on
> getting the basic decoders to work.
More specifically, getting the basic decoders to work with very specific
hardware -- i.e., the mceusb transceivers, and primarily focused only on
RC-6(A) decode w/the mceusb bundled remotes. That, and getting the lirc
bridge driver working for both rx and tx.
Basically, my plan of attack has been to get enough bits in place that we
have a "reference implementation", if you will, of a driver that supports
all in-kernel decoders and the lirc interface, complete with the ability
to do tx[*], and from there, then we can really dig into the in-kernel
decoders and/or work on porting additional drivers to ir-core. I'm more
focused on porting additional drivers to ir-core at the moment than I am
on testing all of the protocol decoders right now.
[*] we still don't have an ir-core "native" tx method, but tx on the
mceusb works quite well using the lirc bridge plugin
--
Jarod Wilson
jarod@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 14:53 ` Jon Smirl
@ 2010-07-28 15:42 ` Mauro Carvalho Chehab
2010-07-28 17:02 ` Andy Walls
0 siblings, 1 reply; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 15:42 UTC (permalink / raw)
To: Jon Smirl
Cc: Andy Walls, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
Em 28-07-2010 11:53, Jon Smirl escreveu:
> On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
>> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
>> Is JVC enabled by default? I recall analyzing that it could generate
>> false positives on NEC codes.
>
> Hopefully the engines should differentiate the two. If the signal is
> really messed up it may trigger a response from both engines. That
> shouldn't be fatal at the higher layers, the wrong protocol would just
> be ignored.
By default, both decoders are enabled, but if you're using the ir-keycode
userspace program at udev, it will disable all protocols but the ones associated
with the RC keytable loaded for that specific device.
Even if both JVC and NEC decoders generate scancodes, it is very unlikely that
the scancode generated by the wrong decoder would produce a valid scancode at
the RC keycode space.
> I recommend that all decoders initially follow the strict protocol
> rules. That will let us find bugs like this one in the ENE driver.
Agreed.
> After we get everything possible working under the strict rules we can
> loosen then up to allow out of spec devices. We might even end up with
> an IR-quirk driver that supports broken remotes.
I think that the better is to add some parameters, via sysfs, to relax the
rules at the current decoders, if needed.
Cheers,
Mauro
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 14:41 ` Jon Smirl
2010-07-28 15:18 ` Jarod Wilson
@ 2010-07-28 15:56 ` Mauro Carvalho Chehab
2010-07-28 17:04 ` Jon Smirl
1 sibling, 1 reply; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 15:56 UTC (permalink / raw)
To: Jon Smirl; +Cc: Maxim Levitsky, Jarod Wilson, linux-input, linux-media
Em 28-07-2010 11:41, Jon Smirl escreveu:
> It's possible to build a Linux IR decoder engine that can be loaded
> with the old LIRC config files.
I think it is a good idea to have a decoder that works with such files anyway.
There are some good reasons for that, as it would allow in-kernel support for
protocols that may have some patent restrictions on a few countries that allow
patents on software.
We'll need to discuss the API requirements for such decoder, in order to load
the RC decoding code into it.
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 15:42 ` Mauro Carvalho Chehab
@ 2010-07-28 17:02 ` Andy Walls
2010-07-28 17:35 ` Jon Smirl
2010-07-28 18:29 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 33+ messages in thread
From: Andy Walls @ 2010-07-28 17:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jon Smirl, Maxim Levitsky, Jarod Wilson, linux-input, linux-media
On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
> Em 28-07-2010 11:53, Jon Smirl escreveu:
> > On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> >> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
> > I recommend that all decoders initially follow the strict protocol
> > rules. That will let us find bugs like this one in the ENE driver.
>
> Agreed.
Well...
I'd possibly make an exception for the protocols that have long-mark
leaders. The actual long mark measurement can be far off from the
protocol's specification and needs a larger tolerance (IMO).
Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
protocol element that is 8 to 16 protocol time units long, doesn't make
too much sense to me. If the remote has the basic protocol time unit
off from our expectation, the error will likely be amplified in a long
protocol elements and very much off our expectation.
> I think that the better is to add some parameters, via sysfs, to relax the
> rules at the current decoders, if needed.
Is that worth the effort? It seems like only going half-way to an
ultimate end state.
<crazy idea>
If you go through the effort of implementing fine grained controls
(tweaking tolerances for this pulse type here or there), why not just
implement a configurable decoding engine that takes as input:
symbol definitions
(pulse and space length specifications and tolerances)
pulse train states
allowed state transitions
gap length
decoded output data length
and instantiates a decoder that follows a user-space provided
specification?
The user can write his own decoding engine specification in a text file,
feed it into the kernel, and the kernel can implement it for him.
</crazy idea>
OK, maybe that is a little too much time and effort. ;)
Regards,
Andy
> Cheers,
> Mauro
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 15:56 ` Mauro Carvalho Chehab
@ 2010-07-28 17:04 ` Jon Smirl
2010-07-28 17:21 ` Andy Walls
2010-07-28 18:08 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 17:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Maxim Levitsky, Jarod Wilson, linux-input, linux-media
On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 28-07-2010 11:41, Jon Smirl escreveu:
>
>> It's possible to build a Linux IR decoder engine that can be loaded
>> with the old LIRC config files.
>
> I think it is a good idea to have a decoder that works with such files anyway.
The recorder should use the Linux IR system to record the data. It
would confusing to mix the systems. Users need to be really sure that
the standard protocol decoders don't understand their protocol before
resorting to this. Any one in this situation should post their
recorded data so we can check for driver implementation errors.
An example: if you use irrecord on Sony remotes lirc always records
them in raw mode. The true problem here is that irrecord doesn't
understand that Sony remotes mix different flavors of the Sony
protocol on a single remote. This leads you to think that the Sony
protocol engine is broken when it really isn't. It's the irrecord tool
that is broken. The kernel IR system will decode these remotes
correctly without resorting to raw mode.
> There are some good reasons for that, as it would allow in-kernel support for
> protocols that may have some patent restrictions on a few countries that allow
> patents on software.
Are there any IR protocols less than 20 (or 17) years old? If they are
older than that the patents have expired. I expect IR use to decline
in the future, it will be replaced with RF4CE radio remotes.
>
> We'll need to discuss the API requirements for such decoder, in order to load
> the RC decoding code into it.
>
> Cheers,
> Mauro.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 17:04 ` Jon Smirl
@ 2010-07-28 17:21 ` Andy Walls
2010-07-28 17:38 ` Jon Smirl
2010-07-28 18:08 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 33+ messages in thread
From: Andy Walls @ 2010-07-28 17:21 UTC (permalink / raw)
To: Jon Smirl
Cc: Mauro Carvalho Chehab, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
On Wed, 2010-07-28 at 13:04 -0400, Jon Smirl wrote:
> On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> > Em 28-07-2010 11:41, Jon Smirl escreveu:
>
> Are there any IR protocols less than 20 (or 17) years old? If they are
> older than that the patents have expired. I expect IR use to decline
> in the future, it will be replaced with RF4CE radio remotes.
UEI's XMP protocol for one, IIRC.
UEI are the folks that sell/make "OneForALL" branded remotes.
You can read about their patents' remaining lifetimes in this March 2010
SEC filing:
http://www.faqs.org/sec-filings/100315/UNIVERSAL-ELECTRONICS-INC_10-K/
1 to 18 years - that includes the ones they just bought from Zilog.
That is not to say that all those patents cover protocols.
Regards,
Andy
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 17:02 ` Andy Walls
@ 2010-07-28 17:35 ` Jon Smirl
2010-07-28 18:18 ` Andy Walls
2010-07-28 18:29 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 17:35 UTC (permalink / raw)
To: Andy Walls
Cc: Mauro Carvalho Chehab, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
>> Em 28-07-2010 11:53, Jon Smirl escreveu:
>> > On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
>> >> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
>
>> > I recommend that all decoders initially follow the strict protocol
>> > rules. That will let us find bugs like this one in the ENE driver.
>>
>> Agreed.
>
> Well...
>
> I'd possibly make an exception for the protocols that have long-mark
> leaders. The actual long mark measurement can be far off from the
> protocol's specification and needs a larger tolerance (IMO).
>
> Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
> protocol element that is 8 to 16 protocol time units long, doesn't make
> too much sense to me. If the remote has the basic protocol time unit
> off from our expectation, the error will likely be amplified in a long
> protocol elements and very much off our expectation.
Do you have a better way to differentiate JVC and NEC protocols? They
are pretty similar except for the timings. What happened in this case
was that the first signals matched the NEC protocol. Then we shifted
to bits that matched JVC protocol.
The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5%
error in the initial bit you can't separate the protocols.
In general the decoders are pretty lax and the closest to the correct
one with decode the stream. The 50% rule only comes into play between
two very similar protocols.
One solution would be to implement NEC/JVC in the same engine. Then
apply the NEC consistency checks. If the consistency check pass
present the event on the NEC interface. And then always present the
event on the JVC interface.
>> I think that the better is to add some parameters, via sysfs, to relax the
>> rules at the current decoders, if needed.
>
> Is that worth the effort? It seems like only going half-way to an
> ultimate end state.
>
> <crazy idea>
> If you go through the effort of implementing fine grained controls
> (tweaking tolerances for this pulse type here or there), why not just
> implement a configurable decoding engine that takes as input:
>
> symbol definitions
> (pulse and space length specifications and tolerances)
> pulse train states
> allowed state transitions
> gap length
> decoded output data length
>
> and instantiates a decoder that follows a user-space provided
> specification?
>
> The user can write his own decoding engine specification in a text file,
> feed it into the kernel, and the kernel can implement it for him.
> </crazy idea>
>
> OK, maybe that is a little too much time and effort. ;)
>
> Regards,
> Andy
>
>
>> Cheers,
>> Mauro
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 17:21 ` Andy Walls
@ 2010-07-28 17:38 ` Jon Smirl
2010-07-28 18:35 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 33+ messages in thread
From: Jon Smirl @ 2010-07-28 17:38 UTC (permalink / raw)
To: Andy Walls
Cc: Mauro Carvalho Chehab, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
On Wed, Jul 28, 2010 at 1:21 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Wed, 2010-07-28 at 13:04 -0400, Jon Smirl wrote:
>> On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>> > Em 28-07-2010 11:41, Jon Smirl escreveu:
>
>>
>> Are there any IR protocols less than 20 (or 17) years old? If they are
>> older than that the patents have expired. I expect IR use to decline
>> in the future, it will be replaced with RF4CE radio remotes.
>
> UEI's XMP protocol for one, IIRC.
The beauty of LIRC is that you can use any remote for input. If one
remote's protocols are patented, just use another remote.
Only in the case where we have to xmit the protocol is the patent
conflict unavoidable. In that case we could resort to sending a raw
pulse timing string that comes from user space.
>
> UEI are the folks that sell/make "OneForALL" branded remotes.
>
> You can read about their patents' remaining lifetimes in this March 2010
> SEC filing:
>
> http://www.faqs.org/sec-filings/100315/UNIVERSAL-ELECTRONICS-INC_10-K/
>
> 1 to 18 years - that includes the ones they just bought from Zilog.
> That is not to say that all those patents cover protocols.
>
>
> Regards,
> Andy
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 18:08 ` Mauro Carvalho Chehab
@ 2010-07-28 18:05 ` Jarod Wilson
2010-07-28 18:40 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 33+ messages in thread
From: Jarod Wilson @ 2010-07-28 18:05 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jon Smirl, Maxim Levitsky, Jarod Wilson, linux-input, linux-media
On Wed, Jul 28, 2010 at 03:08:13PM -0300, Mauro Carvalho Chehab wrote:
> Em 28-07-2010 14:04, Jon Smirl escreveu:
> > On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
> > <mchehab@redhat.com> wrote:
> >> Em 28-07-2010 11:41, Jon Smirl escreveu:
> >>
> >>> It's possible to build a Linux IR decoder engine that can be loaded
> >>> with the old LIRC config files.
> >>
> >> I think it is a good idea to have a decoder that works with such files anyway.
> >
> > The recorder should use the Linux IR system to record the data. It
> > would confusing to mix the systems. Users need to be really sure that
> > the standard protocol decoders don't understand their protocol before
> > resorting to this. Any one in this situation should post their
> > recorded data so we can check for driver implementation errors.
> >
> > An example: if you use irrecord on Sony remotes lirc always records
> > them in raw mode. The true problem here is that irrecord doesn't
> > understand that Sony remotes mix different flavors of the Sony
> > protocol on a single remote. This leads you to think that the Sony
> > protocol engine is broken when it really isn't. It's the irrecord tool
> > that is broken. The kernel IR system will decode these remotes
> > correctly without resorting to raw mode.
>
> A decoder like that should be a last-resort decoder, only in the
> cases where there's no other option.
>
> >> There are some good reasons for that, as it would allow in-kernel support for
> >> protocols that may have some patent restrictions on a few countries that allow
> >> patents on software.
> >
> > Are there any IR protocols less than 20 (or 17) years old?
>
> Yes. This protocol is brand new:
> https://www.smkusa.com/usa/technologies/qp/
>
> And several new devices are starting to accept it.
The US patent appears to have been filed in 1995 and granted in 1997, so
"brand new" is relative. ;)
http://www.freepatentsonline.com/5640160.html
We do have a few more years of being encumbered by it here in the US
though. :(
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 17:04 ` Jon Smirl
2010-07-28 17:21 ` Andy Walls
@ 2010-07-28 18:08 ` Mauro Carvalho Chehab
2010-07-28 18:05 ` Jarod Wilson
1 sibling, 1 reply; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 18:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: Maxim Levitsky, Jarod Wilson, linux-input, linux-media
Em 28-07-2010 14:04, Jon Smirl escreveu:
> On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em 28-07-2010 11:41, Jon Smirl escreveu:
>>
>>> It's possible to build a Linux IR decoder engine that can be loaded
>>> with the old LIRC config files.
>>
>> I think it is a good idea to have a decoder that works with such files anyway.
>
> The recorder should use the Linux IR system to record the data. It
> would confusing to mix the systems. Users need to be really sure that
> the standard protocol decoders don't understand their protocol before
> resorting to this. Any one in this situation should post their
> recorded data so we can check for driver implementation errors.
>
> An example: if you use irrecord on Sony remotes lirc always records
> them in raw mode. The true problem here is that irrecord doesn't
> understand that Sony remotes mix different flavors of the Sony
> protocol on a single remote. This leads you to think that the Sony
> protocol engine is broken when it really isn't. It's the irrecord tool
> that is broken. The kernel IR system will decode these remotes
> correctly without resorting to raw mode.
A decoder like that should be a last-resort decoder, only in the
cases where there's no other option.
>> There are some good reasons for that, as it would allow in-kernel support for
>> protocols that may have some patent restrictions on a few countries that allow
>> patents on software.
>
> Are there any IR protocols less than 20 (or 17) years old?
Yes. This protocol is brand new:
https://www.smkusa.com/usa/technologies/qp/
And several new devices are starting to accept it.
> If they are
> older than that the patents have expired. I expect IR use to decline
> in the future, it will be replaced with RF4CE radio remotes.
I expect so, but it will take some time until this transition happens.
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 17:35 ` Jon Smirl
@ 2010-07-28 18:18 ` Andy Walls
2010-07-28 20:13 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 33+ messages in thread
From: Andy Walls @ 2010-07-28 18:18 UTC (permalink / raw)
To: Jon Smirl
Cc: Mauro Carvalho Chehab, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote:
> On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> > On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
> >> Em 28-07-2010 11:53, Jon Smirl escreveu:
> >> > On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> >> >> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
> >
> >> > I recommend that all decoders initially follow the strict protocol
> >> > rules. That will let us find bugs like this one in the ENE driver.
> >>
> >> Agreed.
> >
> > Well...
> >
> > I'd possibly make an exception for the protocols that have long-mark
> > leaders. The actual long mark measurement can be far off from the
> > protocol's specification and needs a larger tolerance (IMO).
> >
> > Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
> > protocol element that is 8 to 16 protocol time units long, doesn't make
> > too much sense to me. If the remote has the basic protocol time unit
> > off from our expectation, the error will likely be amplified in a long
> > protocol elements and very much off our expectation.
>
> Do you have a better way to differentiate JVC and NEC protocols? They
> are pretty similar except for the timings.
Yes: Invoke the 80/20 rule and don't try. Enable NEC and disable JVC by
default. Let the users know so as to properly manage user expectations.
(Maxim's original question was about expectation.)
When the user knows NEC isn't working, or he suspects JVC may work, he
can bind that protocol to the particular IR receiver.
Trying to solve the discrimination problem with blindly parallel
decoding all the possible protocols is a big waste of effort IMO:
a. Many remotes are sloppy and out of spec, and get worse with weak
batteries.
b. The IR receiver driver knows what remotes possibly came bundled with
the hardware. (For the case of the MCE USB, it's almost always an RC-6
6A remote.)
c. The user can tell the kernel about his remote unambiguously.
There's no burning need to wear a blindfold, AFAICT, so let's not.
Why bother to solve a hard problem (discrimination of protocols from out
of spec remotes), when it raises the error rate of solving the simple
one (properly decoding a single protocol)?
Doing many things poorly is worse than doing one thing well.
Non-adaptive protocol discovery (i.e. blind parallel decoding) should
not be the default if it leads to problems or inflated expectations for
the user.
> What happened in this case
> was that the first signals matched the NEC protocol. Then we shifted
> to bits that matched JVC protocol.
>
> The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5%
> error in the initial bit you can't separate the protocols.
>
> In general the decoders are pretty lax and the closest to the correct
> one with decode the stream. The 50% rule only comes into play between
> two very similar protocols.
>
> One solution would be to implement NEC/JVC in the same engine. Then
> apply the NEC consistency checks. If the consistency check pass
> present the event on the NEC interface. And then always present the
> event on the JVC interface.
It's just too simple to have the user:
a. Try NEC
b. Try JVC
c. Make a judgment and stick with the one he perceives works.
To have reliable discrimination in the general case between two
protocols, given the variables out of our control (i.e. the remote
control implementation) would require some sort of data collection and
adaptive algorithm to go on inside the kernel. I don't think you can
get reliable discrimination in one key press. Maybe by looking at the
key press and the repeats together might up the probability of correct
discrimination (that's one criterion you examined to make a
determination in your earlier email).
Regards,
Andy
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 17:02 ` Andy Walls
2010-07-28 17:35 ` Jon Smirl
@ 2010-07-28 18:29 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 18:29 UTC (permalink / raw)
To: Andy Walls
Cc: Jon Smirl, Maxim Levitsky, Jarod Wilson, linux-input, linux-media
Em 28-07-2010 14:02, Andy Walls escreveu:
> On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
>> Em 28-07-2010 11:53, Jon Smirl escreveu:
>>> On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
>>>> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
>
>>> I recommend that all decoders initially follow the strict protocol
>>> rules. That will let us find bugs like this one in the ENE driver.
>>
>> Agreed.
>
> Well...
>
> I'd possibly make an exception for the protocols that have long-mark
> leaders. The actual long mark measurement can be far off from the
> protocol's specification and needs a larger tolerance (IMO).
>
> Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
> protocol element that is 8 to 16 protocol time units long, doesn't make
> too much sense to me. If the remote has the basic protocol time unit
> off from our expectation, the error will likely be amplified in a long
> protocol elements and very much off our expectation.
We may adjust it as we note problems on it, but relaxing rules may cause
bad effects, so the better is to be more strict.
>> I think that the better is to add some parameters, via sysfs, to relax the
>> rules at the current decoders, if needed.
>
> Is that worth the effort? It seems like only going half-way to an
> ultimate end state.
Well, let's see first if this is needed. Then, we take the decisions case by case.
> <crazy idea>
> If you go through the effort of implementing fine grained controls
> (tweaking tolerances for this pulse type here or there), why not just
> implement a configurable decoding engine that takes as input:
>
> symbol definitions
> (pulse and space length specifications and tolerances)
> pulse train states
> allowed state transitions
> gap length
> decoded output data length
>
> and instantiates a decoder that follows a user-space provided
> specification?
>
> The user can write his own decoding engine specification in a text file,
> feed it into the kernel, and the kernel can implement it for him.
> </crazy idea>
It is not a crazy idea, and perhaps this is the only way to work with certain
protocols, like Quatro Pulse (see my previous email).
But I think that we should still have the proper decoders for common
protocols and that we won't have any legal restriction to implement
a decoder. A generic decoder will be less efficient than
> OK, maybe that is a little too much time and effort. ;)
Good point. Well, we'll need some volunteer to write such driver ;)
Cheers,
Mauro
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 17:38 ` Jon Smirl
@ 2010-07-28 18:35 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 18:35 UTC (permalink / raw)
To: Jon Smirl
Cc: Andy Walls, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
Em 28-07-2010 14:38, Jon Smirl escreveu:
> On Wed, Jul 28, 2010 at 1:21 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> On Wed, 2010-07-28 at 13:04 -0400, Jon Smirl wrote:
>>> On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Em 28-07-2010 11:41, Jon Smirl escreveu:
>>
>>>
>>> Are there any IR protocols less than 20 (or 17) years old? If they are
>>> older than that the patents have expired. I expect IR use to decline
>>> in the future, it will be replaced with RF4CE radio remotes.
>>
>> UEI's XMP protocol for one, IIRC.
>
> The beauty of LIRC is that you can use any remote for input. If one
> remote's protocols are patented, just use another remote.
>
> Only in the case where we have to xmit the protocol is the patent
> conflict unavoidable. In that case we could resort to sending a raw
> pulse timing string that comes from user space.
Well, software patents are valid only on very few Countries. People that live
on a software-patent-free Country can keep using those protocols, if they
can just upload a set of rules for a generic driver. On the other hand,
a rule-hardcoded codec for a patented protocol cannot be inside Kernel, as
this would restrict kernel distribution on those non-software-patent-free
Countries.
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 18:05 ` Jarod Wilson
@ 2010-07-28 18:40 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 18:40 UTC (permalink / raw)
To: Jarod Wilson
Cc: Jon Smirl, Maxim Levitsky, Jarod Wilson, linux-input, linux-media
Em 28-07-2010 15:05, Jarod Wilson escreveu:
> On Wed, Jul 28, 2010 at 03:08:13PM -0300, Mauro Carvalho Chehab wrote:
>> Em 28-07-2010 14:04, Jon Smirl escreveu:
>>> On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> Em 28-07-2010 11:41, Jon Smirl escreveu:
>>>>
>>>>> It's possible to build a Linux IR decoder engine that can be loaded
>>>>> with the old LIRC config files.
>>>>
>>>> I think it is a good idea to have a decoder that works with such files anyway.
>>>
>>> The recorder should use the Linux IR system to record the data. It
>>> would confusing to mix the systems. Users need to be really sure that
>>> the standard protocol decoders don't understand their protocol before
>>> resorting to this. Any one in this situation should post their
>>> recorded data so we can check for driver implementation errors.
>>>
>>> An example: if you use irrecord on Sony remotes lirc always records
>>> them in raw mode. The true problem here is that irrecord doesn't
>>> understand that Sony remotes mix different flavors of the Sony
>>> protocol on a single remote. This leads you to think that the Sony
>>> protocol engine is broken when it really isn't. It's the irrecord tool
>>> that is broken. The kernel IR system will decode these remotes
>>> correctly without resorting to raw mode.
>>
>> A decoder like that should be a last-resort decoder, only in the
>> cases where there's no other option.
>>
>>>> There are some good reasons for that, as it would allow in-kernel support for
>>>> protocols that may have some patent restrictions on a few countries that allow
>>>> patents on software.
>>>
>>> Are there any IR protocols less than 20 (or 17) years old?
>>
>> Yes. This protocol is brand new:
>> https://www.smkusa.com/usa/technologies/qp/
>>
>> And several new devices are starting to accept it.
>
> The US patent appears to have been filed in 1995 and granted in 1997, so
> "brand new" is relative. ;)
Yes, I saw the patent timestamps too ;) Yet, AFAIK, they're starting to use this protocol
on newer IR devices, so, we'll probably see some new devices using it.
>
> http://www.freepatentsonline.com/5640160.html
>
> We do have a few more years of being encumbered by it here in the US
> though. :(
>
:(
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 18:18 ` Andy Walls
@ 2010-07-28 20:13 ` Mauro Carvalho Chehab
2010-07-28 20:27 ` Maxim Levitsky
2010-07-29 2:36 ` Andy Walls
0 siblings, 2 replies; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 20:13 UTC (permalink / raw)
To: Andy Walls
Cc: Jon Smirl, Maxim Levitsky, Jarod Wilson, linux-input, linux-media
Andy,
Em 28-07-2010 15:18, Andy Walls escreveu:
> On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote:
>> On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>>> On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
>>>> Em 28-07-2010 11:53, Jon Smirl escreveu:
>>>>> On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
>>>>>> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
>>>
>>>>> I recommend that all decoders initially follow the strict protocol
>>>>> rules. That will let us find bugs like this one in the ENE driver.
>>>>
>>>> Agreed.
>>>
>>> Well...
>>>
>>> I'd possibly make an exception for the protocols that have long-mark
>>> leaders. The actual long mark measurement can be far off from the
>>> protocol's specification and needs a larger tolerance (IMO).
>>>
>>> Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
>>> protocol element that is 8 to 16 protocol time units long, doesn't make
>>> too much sense to me. If the remote has the basic protocol time unit
>>> off from our expectation, the error will likely be amplified in a long
>>> protocol elements and very much off our expectation.
>>
>> Do you have a better way to differentiate JVC and NEC protocols? They
>> are pretty similar except for the timings.
>
> Yes: Invoke the 80/20 rule and don't try.
At the room where my computers is located, I have two wide fluorescent lamps
each with 20W. If I don't hide the IR sensors bellow my desk, those lamps
are enough to generate random flickers at the sensors. With the more relaxed
driver we used to have at saa7134, it ended by producing random scancodes,
or, even worse, random repeat codes. So, lots of false-positive events. It is
a way worse to have false-positive than having a false-negative events.
So, I don't think it is a good idea to use a "relaxed" mode by default.
> Enable NEC and disable JVC by
> default. Let the users know so as to properly manage user expectations.
> (Maxim's original question was about expectation.)
We should discuss a little bit about RC subsystem evolution during LPC/2010,
but, from my point of view, we should soon deprecate the in-kernel keymap tables
on some new kernel version, using, instead, the ir-keycode application to
dynamically load the keycode tables via UDEV. Of course, after some time,
we may end by removing all those tables from the kernel.
So, assuming that we follow this patch, what we'll have for a newer device is:
For most devices, the keymap configuration table (rc_maps.cfg) will associate
all known devices with their corresponding keytable (we still need to generate
a default rc_maps.cfg that corresponds to the current in-kernel mapping, but
this is trivial).
As ir-keytable disables all protocols but the one(s) needed by a given device,
in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled.
If the table is for JVC, NEC will be disabled.
So, this already happens in a practical scenario, as all decoders will be enabled
only before loading a keymap (or if the user explicitly enable the other decoders).
So, the device will be in some sort of "training" mode, e. g. it will try every
possible decoder, and will be generating the scancodes for some userspace application
that will be learning the keycodes and creating a keymap table.
IMO, we should have a way to tell the RC and/or the decoding subsystem to work on a
"relaxed" mode only when the user (or the userspace app) detects that there's something
wrong with that device.
> When the user knows NEC isn't working, or he suspects JVC may work, he
> can bind that protocol to the particular IR receiver.
>
> Trying to solve the discrimination problem with blindly parallel
> decoding all the possible protocols is a big waste of effort IMO:
>
> a. Many remotes are sloppy and out of spec, and get worse with weak
> batteries.
>
> b. The IR receiver driver knows what remotes possibly came bundled with
> the hardware. (For the case of the MCE USB, it's almost always an RC-6
> 6A remote.)
>
> c. The user can tell the kernel about his remote unambiguously.
>
> There's no burning need to wear a blindfold, AFAICT, so let's not.
>
> Why bother to solve a hard problem (discrimination of protocols from out
> of spec remotes), when it raises the error rate of solving the simple
> one (properly decoding a single protocol)?
>
> Doing many things poorly is worse than doing one thing well.
> Non-adaptive protocol discovery (i.e. blind parallel decoding) should
> not be the default if it leads to problems or inflated expectations for
> the user.
>
>
>> What happened in this case
>> was that the first signals matched the NEC protocol. Then we shifted
>> to bits that matched JVC protocol.
>>
>> The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5%
>> error in the initial bit you can't separate the protocols.
>>
>> In general the decoders are pretty lax and the closest to the correct
>> one with decode the stream. The 50% rule only comes into play between
>> two very similar protocols.
>>
>> One solution would be to implement NEC/JVC in the same engine. Then
>> apply the NEC consistency checks. If the consistency check pass
>> present the event on the NEC interface. And then always present the
>> event on the JVC interface.
>
> It's just too simple to have the user:
>
> a. Try NEC
> b. Try JVC
> c. Make a judgment and stick with the one he perceives works.
>
>
> To have reliable discrimination in the general case between two
> protocols, given the variables out of our control (i.e. the remote
> control implementation) would require some sort of data collection and
> adaptive algorithm to go on inside the kernel. I don't think you can
> get reliable discrimination in one key press. Maybe by looking at the
> key press and the repeats together might up the probability of correct
> discrimination (that's one criterion you examined to make a
> determination in your earlier email).
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 20:13 ` Mauro Carvalho Chehab
@ 2010-07-28 20:27 ` Maxim Levitsky
2010-07-29 2:36 ` Andy Walls
1 sibling, 0 replies; 33+ messages in thread
From: Maxim Levitsky @ 2010-07-28 20:27 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Andy Walls, Jon Smirl, Jarod Wilson, linux-input, linux-media
On Wed, 2010-07-28 at 17:13 -0300, Mauro Carvalho Chehab wrote:
> Andy,
>
> Em 28-07-2010 15:18, Andy Walls escreveu:
> > On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote:
> >> On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> >>> On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
> >>>> Em 28-07-2010 11:53, Jon Smirl escreveu:
> >>>>> On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> >>>>>> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
> >>>
> >>>>> I recommend that all decoders initially follow the strict protocol
> >>>>> rules. That will let us find bugs like this one in the ENE driver.
> >>>>
> >>>> Agreed.
> >>>
> >>> Well...
> >>>
> >>> I'd possibly make an exception for the protocols that have long-mark
> >>> leaders. The actual long mark measurement can be far off from the
> >>> protocol's specification and needs a larger tolerance (IMO).
> >>>
> >>> Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
> >>> protocol element that is 8 to 16 protocol time units long, doesn't make
> >>> too much sense to me. If the remote has the basic protocol time unit
> >>> off from our expectation, the error will likely be amplified in a long
> >>> protocol elements and very much off our expectation.
> >>
> >> Do you have a better way to differentiate JVC and NEC protocols? They
> >> are pretty similar except for the timings.
> >
> > Yes: Invoke the 80/20 rule and don't try.
>
> At the room where my computers is located, I have two wide fluorescent lamps
> each with 20W. If I don't hide the IR sensors bellow my desk, those lamps
> are enough to generate random flickers at the sensors. With the more relaxed
> driver we used to have at saa7134, it ended by producing random scancodes,
> or, even worse, random repeat codes. So, lots of false-positive events. It is
> a way worse to have false-positive than having a false-negative events.
>
> So, I don't think it is a good idea to use a "relaxed" mode by default.
>
>
> > Enable NEC and disable JVC by
> > default. Let the users know so as to properly manage user expectations.
> > (Maxim's original question was about expectation.)
>
> We should discuss a little bit about RC subsystem evolution during LPC/2010,
> but, from my point of view, we should soon deprecate the in-kernel keymap tables
> on some new kernel version, using, instead, the ir-keycode application to
> dynamically load the keycode tables via UDEV. Of course, after some time,
> we may end by removing all those tables from the kernel.
/me is very happy about it.
The reason isn't even about size or some principle.
These keymaps just increase compilation time too much...
>
> So, assuming that we follow this patch, what we'll have for a newer device is:
>
> For most devices, the keymap configuration table (rc_maps.cfg) will associate
> all known devices with their corresponding keytable (we still need to generate
> a default rc_maps.cfg that corresponds to the current in-kernel mapping, but
> this is trivial).
>
> As ir-keytable disables all protocols but the one(s) needed by a given device,
> in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled.
> If the table is for JVC, NEC will be disabled.
>
> So, this already happens in a practical scenario, as all decoders will be enabled
> only before loading a keymap (or if the user explicitly enable the other decoders).
>
> So, the device will be in some sort of "training" mode, e. g. it will try every
> possible decoder, and will be generating the scancodes for some userspace application
> that will be learning the keycodes and creating a keymap table.
>
> IMO, we should have a way to tell the RC and/or the decoding subsystem to work on a
> "relaxed" mode only when the user (or the userspace app) detects that there's something
> wrong with that device.
>
> > When the user knows NEC isn't working, or he suspects JVC may work, he
> > can bind that protocol to the particular IR receiver.
> >
> > Trying to solve the discrimination problem with blindly parallel
> > decoding all the possible protocols is a big waste of effort IMO:
> >
> > a. Many remotes are sloppy and out of spec, and get worse with weak
> > batteries.
> >
> > b. The IR receiver driver knows what remotes possibly came bundled with
> > the hardware. (For the case of the MCE USB, it's almost always an RC-6
> > 6A remote.)
> >
> > c. The user can tell the kernel about his remote unambiguously.
> >
> > There's no burning need to wear a blindfold, AFAICT, so let's not.
> >
> > Why bother to solve a hard problem (discrimination of protocols from out
> > of spec remotes), when it raises the error rate of solving the simple
> > one (properly decoding a single protocol)?
> >
> > Doing many things poorly is worse than doing one thing well.
> > Non-adaptive protocol discovery (i.e. blind parallel decoding) should
> > not be the default if it leads to problems or inflated expectations for
> > the user.
> >
> >
> >> What happened in this case
> >> was that the first signals matched the NEC protocol. Then we shifted
> >> to bits that matched JVC protocol.
> >>
> >> The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5%
> >> error in the initial bit you can't separate the protocols.
> >>
> >> In general the decoders are pretty lax and the closest to the correct
> >> one with decode the stream. The 50% rule only comes into play between
> >> two very similar protocols.
> >>
> >> One solution would be to implement NEC/JVC in the same engine. Then
> >> apply the NEC consistency checks. If the consistency check pass
> >> present the event on the NEC interface. And then always present the
> >> event on the JVC interface.
> >
> > It's just too simple to have the user:
> >
> > a. Try NEC
> > b. Try JVC
> > c. Make a judgment and stick with the one he perceives works.
> >
> >
> > To have reliable discrimination in the general case between two
> > protocols, given the variables out of our control (i.e. the remote
> > control implementation) would require some sort of data collection and
> > adaptive algorithm to go on inside the kernel. I don't think you can
> > get reliable discrimination in one key press. Maybe by looking at the
> > key press and the repeats together might up the probability of correct
> > discrimination (that's one criterion you examined to make a
> > determination in your earlier email).
>
> Cheers,
> Mauro.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 14:24 ` Maxim Levitsky
2010-07-28 14:41 ` Jon Smirl
@ 2010-07-28 21:01 ` Maxim Levitsky
2010-07-28 21:35 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 33+ messages in thread
From: Maxim Levitsky @ 2010-07-28 21:01 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Jon Smirl, Jarod Wilson, linux-input, linux-media
On Wed, 2010-07-28 at 17:24 +0300, Maxim Levitsky wrote:
> On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote:
> > Em 28-07-2010 07:40, Jon Smirl escreveu:
> > > On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > >> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
> > >>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> >
> > >> No its not, its just extended NEC.
> > >
> > > http://www.sbprojects.com/knowledge/ir/nec.htm
> > > Says the last two bytes should be the complement of each other.
> > >
> > > So for extended NEC it would need to be:
> > > 1100 0010 1010 0101 instead of 1100 0010 1010 0100
> > > The last bit is wrong.
> > >
> > > From the debug output it is decoding as NEC, but then it fails a
> > > consistency check. Maybe we need to add a new protocol that lets NEC
> > > commands through even if they fail the error checks.
> >
> > Assuming that Maxim's IR receiver is not causing some bad decode at the
> > NEC code, it seems simpler to add a parameter at sysfs to relax the NEC
> > detection. We should add some way, at the userspace table for those RC's
> > that uses a NEC-like code.
> >
> > There's another alternative: currently, the NEC decoder produces a 16 bits
> > code for NEC and a 24 bits for NEC-extended code. The decoder may return a
> > 32 bits code when none of the checksum's match the NEC or NEC-extended standard.
> >
> > Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so
> > there's no risk of generating a wrong keycode, if the wrong consistent check
> > is due to a reception error.
> >
> > Btw, we still need to port rc core to use the new tables ioctl's, as cleaning
> > all keycodes on a 32 bits table would take forever with the current input
> > events ioctls.
> >
> > > It may also be
> > > that the NEC machine rejected it because the timing was so far off
> > > that it concluded that it couldn't be a NEC messages. The log didn't
> > > include the exact reason it got rejected. Add some printks at the end
> > > of the NEC machine to determine the exact reason for rejection.
> >
> > The better is to discard the possibility of a timing issue before changing
> > the decoder to accept NEC-like codes without consistency checks.
> >
> > > The current state machines enforce protocol compliance so there are
> > > probably a lot of older remotes that won't decode right. We can use
> > > some help in adjusting the state machines to let out of spec codes
> > > through.
> >
> > Yes, but we should take some care to avoid having another protocol decoder to
> > interpret badly a different protocol. So, I think that the decoders may have
> > some sysfs nodes to tweak the decoders to accept those older remotes.
> >
> > We'll need a consistent way to add some logic at the remotes keycodes used by
> > ir-keycode, in order to allow it to tweak the decoder when a keycode table for
> > such remote is loaded into the driver.
> >
> > > User space lirc is much older. Bugs like this have been worked out of
> > > it. It will take some time to get the kernel implementation up to the
> > > same level.
> >
> > True.
>
>
> I more or less got to the bottom of this.
>
>
> It turns out that ENE reciever has a non linear measurement error.
> That is the longer sample is, the larger error it contains.
> Substracting around 4% from the samples makes the output look much more
> standard compliant.
>
> You are right that my remote has JVC protocol. (at least I am sure now
> it hasn't NEC, because repeat looks differently).
>
> My remote now actually partially works with JVC decoder, it decodes
> every other keypress.
>
> Still, no repeat is supported.
>
> However, all recievers (and transmitters) aren't perfect.
> Thats why I prefer lirc, because it makes no assumptions about protocol,
> so it can be 'trained' to work with any remote, and under very large
> range of error tolerances.
>
> Best regards,
> Maxim Levitsky
>
I think I found the reason behind some of incorrect behavior.
I see that in-kernel decoding is unhappy about the way I process gaps.
I do exactly the same I did in lirc driver.
At the end of keypress, the driver receives series of spaces from
hardware.
I accumulate 'em until patience^Wtimeout runs out.
Then I put hardware in 'idle' mode, and remember current time.
As soon as I get new pulse, I send a sum of accumulated same and time
difference to user.
Therefore every keypress ends with a pulse, and starts with space.
But in-kernel decoding isn't happy about it, it seems.. at least NEC
decoder...
How you think to solve that?
Fix in-kernel decoders maybe?
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 21:01 ` Maxim Levitsky
@ 2010-07-28 21:35 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 33+ messages in thread
From: Mauro Carvalho Chehab @ 2010-07-28 21:35 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Jon Smirl, Jarod Wilson, linux-input, linux-media
Em 28-07-2010 18:01, Maxim Levitsky escreveu:
> On Wed, 2010-07-28 at 17:24 +0300, Maxim Levitsky wrote:
>> On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote:
>>> Em 28-07-2010 07:40, Jon Smirl escreveu:
>>>> On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>>>>> On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote:
>>>>>> On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>>
>>>>> No its not, its just extended NEC.
>>>>
>>>> http://www.sbprojects.com/knowledge/ir/nec.htm
>>>> Says the last two bytes should be the complement of each other.
>>>>
>>>> So for extended NEC it would need to be:
>>>> 1100 0010 1010 0101 instead of 1100 0010 1010 0100
>>>> The last bit is wrong.
>>>>
>>>> From the debug output it is decoding as NEC, but then it fails a
>>>> consistency check. Maybe we need to add a new protocol that lets NEC
>>>> commands through even if they fail the error checks.
>>>
>>> Assuming that Maxim's IR receiver is not causing some bad decode at the
>>> NEC code, it seems simpler to add a parameter at sysfs to relax the NEC
>>> detection. We should add some way, at the userspace table for those RC's
>>> that uses a NEC-like code.
>>>
>>> There's another alternative: currently, the NEC decoder produces a 16 bits
>>> code for NEC and a 24 bits for NEC-extended code. The decoder may return a
>>> 32 bits code when none of the checksum's match the NEC or NEC-extended standard.
>>>
>>> Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so
>>> there's no risk of generating a wrong keycode, if the wrong consistent check
>>> is due to a reception error.
>>>
>>> Btw, we still need to port rc core to use the new tables ioctl's, as cleaning
>>> all keycodes on a 32 bits table would take forever with the current input
>>> events ioctls.
>>>
>>>> It may also be
>>>> that the NEC machine rejected it because the timing was so far off
>>>> that it concluded that it couldn't be a NEC messages. The log didn't
>>>> include the exact reason it got rejected. Add some printks at the end
>>>> of the NEC machine to determine the exact reason for rejection.
>>>
>>> The better is to discard the possibility of a timing issue before changing
>>> the decoder to accept NEC-like codes without consistency checks.
>>>
>>>> The current state machines enforce protocol compliance so there are
>>>> probably a lot of older remotes that won't decode right. We can use
>>>> some help in adjusting the state machines to let out of spec codes
>>>> through.
>>>
>>> Yes, but we should take some care to avoid having another protocol decoder to
>>> interpret badly a different protocol. So, I think that the decoders may have
>>> some sysfs nodes to tweak the decoders to accept those older remotes.
>>>
>>> We'll need a consistent way to add some logic at the remotes keycodes used by
>>> ir-keycode, in order to allow it to tweak the decoder when a keycode table for
>>> such remote is loaded into the driver.
>>>
>>>> User space lirc is much older. Bugs like this have been worked out of
>>>> it. It will take some time to get the kernel implementation up to the
>>>> same level.
>>>
>>> True.
>>
>>
>> I more or less got to the bottom of this.
>>
>>
>> It turns out that ENE reciever has a non linear measurement error.
>> That is the longer sample is, the larger error it contains.
>> Substracting around 4% from the samples makes the output look much more
>> standard compliant.
>>
>> You are right that my remote has JVC protocol. (at least I am sure now
>> it hasn't NEC, because repeat looks differently).
>>
>> My remote now actually partially works with JVC decoder, it decodes
>> every other keypress.
>>
>> Still, no repeat is supported.
>>
>> However, all recievers (and transmitters) aren't perfect.
>> Thats why I prefer lirc, because it makes no assumptions about protocol,
>> so it can be 'trained' to work with any remote, and under very large
>> range of error tolerances.
>>
>> Best regards,
>> Maxim Levitsky
>>
>
> I think I found the reason behind some of incorrect behavior.
>
> I see that in-kernel decoding is unhappy about the way I process gaps.
>
> I do exactly the same I did in lirc driver.
>
> At the end of keypress, the driver receives series of spaces from
> hardware.
> I accumulate 'em until patience^Wtimeout runs out.
> Then I put hardware in 'idle' mode, and remember current time.
>
> As soon as I get new pulse, I send a sum of accumulated same and time
> difference to user.
>
> Therefore every keypress ends with a pulse, and starts with space.
> But in-kernel decoding isn't happy about it, it seems.. at least NEC
> decoder...
>
> How you think to solve that?
> Fix in-kernel decoders maybe?
Just send whatever you receive from hardware to the decoders. both LIRC and
decoders have already a code to handle the timeouts.
Cheers,
Mauro
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-28 20:13 ` Mauro Carvalho Chehab
2010-07-28 20:27 ` Maxim Levitsky
@ 2010-07-29 2:36 ` Andy Walls
2010-07-29 11:58 ` Jon Smirl
1 sibling, 1 reply; 33+ messages in thread
From: Andy Walls @ 2010-07-29 2:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jon Smirl, Maxim Levitsky, Jarod Wilson, linux-input, linux-media
On Wed, 2010-07-28 at 17:13 -0300, Mauro Carvalho Chehab wrote:
> Andy,
>
> Em 28-07-2010 15:18, Andy Walls escreveu:
> > On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote:
> >> On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> >>> On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote:
> >>>> Em 28-07-2010 11:53, Jon Smirl escreveu:
> >>>>> On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> >>>>>> On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote:
> >>>
> >>>>> I recommend that all decoders initially follow the strict protocol
> >>>>> rules. That will let us find bugs like this one in the ENE driver.
> >>>>
> >>>> Agreed.
> >>>
> >>> Well...
> >>>
> >>> I'd possibly make an exception for the protocols that have long-mark
> >>> leaders. The actual long mark measurement can be far off from the
> >>> protocol's specification and needs a larger tolerance (IMO).
> >>>
> >>> Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a
> >>> protocol element that is 8 to 16 protocol time units long, doesn't make
> >>> too much sense to me. If the remote has the basic protocol time unit
> >>> off from our expectation, the error will likely be amplified in a long
> >>> protocol elements and very much off our expectation.
> >>
> >> Do you have a better way to differentiate JVC and NEC protocols? They
> >> are pretty similar except for the timings.
> >
> > Yes: Invoke the 80/20 rule and don't try.
>
> At the room where my computers is located, I have two wide fluorescent lamps
> each with 20W. If I don't hide the IR sensors bellow my desk, those lamps
> are enough to generate random flickers at the sensors. With the more relaxed
> driver we used to have at saa7134, it ended by producing random scancodes,
> or, even worse, random repeat codes. So, lots of false-positive events. It is
> a way worse to have false-positive than having a false-negative events.
So those sorts of false positiives are bad, but a glitch filter handles
those. (Easily done in software - borrow from the LIRC userspace if
need be.) Set the glictch filter discard pulses that are shorter than
some fraction of the expected protocol time unit.
In the cx23885-input.c file I chose to set the hardware glitch filter at
75% for RC-6 and 62.5% for NEC (I forget my reasons for those numbers
aside from being 3/4 & 5/8 respectively)
> So, I don't think it is a good idea to use a "relaxed" mode by default.
So I disagree. We should set the default to make the most common use
case as error free as possible, reducing false detections and missed
detections, so that it "just works".
I see two conflicting goals, which force optimizations one direction or
another:
1. Optimize for good protocol discrimination
(at the expense of ability to decode from remotes/receviers that don't
meet the protocol specs).
2. Optimize for good decoding within each protocol
(at the expense of discriminating between the protocols).
My assertion that goal #1, is not important in the most common use case
and the ability have an acceptable success rate in the general case is
questionable. There is so much information available to constrain what
IR protocols will be present on a receiver, it hardly seems worth the
effort for the normal user with 1 TV capture device and the remote that
came with it.
I'll also assert that goal #2 is easier to attain and more useful to the
general case. Cheap remotes and poor ambient light conditions are
common occurences. Glitch filters are simpler if you can just throw out
glitches, restarting the measurment, knowing that the tolerances will
still pull you in. One can also start to think about adaptive decoders,
that adjust to the protocol time unit the remotes appears to be using.
(In NEC, the normal mark time indicates the remote's idea of the
protocol time unit.)
What am I going to do about it all in the end? Probably not much. :)
(I seem to have more time to gripe than do much else nowadays. :P )
> > Enable NEC and disable JVC by
> > default. Let the users know so as to properly manage user expectations.
> > (Maxim's original question was about expectation.)
>
> We should discuss a little bit about RC subsystem evolution during LPC/2010,
Yes. I'll be there.
> but, from my point of view, we should soon deprecate the in-kernel keymap tables
> on some new kernel version, using, instead, the ir-keycode application to
> dynamically load the keycode tables via UDEV. Of course, after some time,
> we may end by removing all those tables from the kernel.
>
> So, assuming that we follow this patch, what we'll have for a newer device is:
>
> For most devices, the keymap configuration table (rc_maps.cfg) will associate
> all known devices with their corresponding keytable (we still need to generate
> a default rc_maps.cfg that corresponds to the current in-kernel mapping, but
> this is trivial).
>
> As ir-keytable disables all protocols but the one(s) needed by a given device,
> in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled.
> If the table is for JVC, NEC will be disabled.
>
> So, this already happens in a practical scenario, as all decoders will be enabled
> only before loading a keymap (or if the user explicitly enable the other decoders).
>
> So, the device will be in some sort of "training" mode, e. g. it will try every
> possible decoder, and will be generating the scancodes for some userspace application
> that will be learning the keycodes and creating a keymap table.
I like that discovery of a remote protocol and scancodes is a particular
mode, but I don't see the value of turning it on by default. It seems
like the user-space CLI or GUI apps could just set it that way for the
receiver of interest.
I'm not sure I can develop some evil IR DoS device to take advantage of
that default, so I suppose it is only wasting CPU cycles.
> IMO, we should have a way to tell the RC and/or the decoding subsystem to work on a
> "relaxed" mode only when the user (or the userspace app) detects that there's something
> wrong with that device.
Simple glitch filters, like ones that discard measurments, would be a
case where the decoding would benefit from the decoders being less
picky.
As an example of simple hardware glitch filter, here's an excerpt
from the public CX25480/1/2/3 datasheet on the IR low-pass (glitch)
filter that's in the hardware:
"the counter reloads using the value programmed to this register each
time a qualified edge is detected [...]. Once the reload occurs, the
counter begins decrementing. If the next programmed edge occurs before
the counter reaches 0, the pulse measurement value is discarded, the
filter modulus value is reloaded, and the next pulse measurement begins.
Thus, any pulse measurement that ends before the counter reaches 0 is
ignored."
Regards,
Andy
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Can I expect in-kernel decoding to work out of box?
2010-07-29 2:36 ` Andy Walls
@ 2010-07-29 11:58 ` Jon Smirl
0 siblings, 0 replies; 33+ messages in thread
From: Jon Smirl @ 2010-07-29 11:58 UTC (permalink / raw)
To: Andy Walls
Cc: Mauro Carvalho Chehab, Maxim Levitsky, Jarod Wilson, linux-input,
linux-media
On Wed, Jul 28, 2010 at 10:36 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> As an example of simple hardware glitch filter, here's an excerpt
> from the public CX25480/1/2/3 datasheet on the IR low-pass (glitch)
> filter that's in the hardware:
>
> "the counter reloads using the value programmed to this register each
> time a qualified edge is detected [...]. Once the reload occurs, the
> counter begins decrementing. If the next programmed edge occurs before
> the counter reaches 0, the pulse measurement value is discarded, the
> filter modulus value is reloaded, and the next pulse measurement begins.
> Thus, any pulse measurement that ends before the counter reaches 0 is
> ignored."
You could make a small library that drivers could link in. That way we
won't get it implemented ten different ways. Devices that do the
filtering in firmware won't have to use the code.
There are lots of ways to design it. A simple one would be to sit on
each message until the next one arrives. Then make a decision to pass
the previous message up or declare the current edge a glitch and wait
for the next one. It probably needs a timeout so that you don't sit
on long pulses forever waiting on the next one.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2010-07-29 11:58 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-27 22:33 Can I expect in-kernel decoding to work out of box? Maxim Levitsky
2010-07-27 23:32 ` Maxim Levitsky
2010-07-28 1:29 ` Jon Smirl
2010-07-28 2:33 ` Jarod Wilson
2010-07-28 6:30 ` Maxim Levitsky
2010-07-28 6:59 ` Maxim Levitsky
2010-07-28 10:40 ` Jon Smirl
2010-07-28 13:13 ` Mauro Carvalho Chehab
2010-07-28 13:46 ` Jon Smirl
2010-07-28 14:38 ` Andy Walls
2010-07-28 14:53 ` Jon Smirl
2010-07-28 15:42 ` Mauro Carvalho Chehab
2010-07-28 17:02 ` Andy Walls
2010-07-28 17:35 ` Jon Smirl
2010-07-28 18:18 ` Andy Walls
2010-07-28 20:13 ` Mauro Carvalho Chehab
2010-07-28 20:27 ` Maxim Levitsky
2010-07-29 2:36 ` Andy Walls
2010-07-29 11:58 ` Jon Smirl
2010-07-28 18:29 ` Mauro Carvalho Chehab
2010-07-28 14:24 ` Maxim Levitsky
2010-07-28 14:41 ` Jon Smirl
2010-07-28 15:18 ` Jarod Wilson
2010-07-28 15:56 ` Mauro Carvalho Chehab
2010-07-28 17:04 ` Jon Smirl
2010-07-28 17:21 ` Andy Walls
2010-07-28 17:38 ` Jon Smirl
2010-07-28 18:35 ` Mauro Carvalho Chehab
2010-07-28 18:08 ` Mauro Carvalho Chehab
2010-07-28 18:05 ` Jarod Wilson
2010-07-28 18:40 ` Mauro Carvalho Chehab
2010-07-28 21:01 ` Maxim Levitsky
2010-07-28 21:35 ` Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).