* 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: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: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: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 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 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: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 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 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
* 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 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 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: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: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: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: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 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 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 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 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 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
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).