I've noticed a peculiar issue configuring a remote control on two different systems. The remote sends a straight forward space encoded, fixed length packet when a button is pressed. I've set up a lircd.conf file for it and have it working flawlessly (with ircat) on my Fedora FC14 box, however it fails miserably on my Ubuntu 10.10 (Mythbuntu) box.
The FC14 system, which works perfectly, uses lirc 0.8.7 with kernel 2.6.35-11 on the x64 architecture. The Ubuntu system, which fails, uses lirc 0.8.7-pre3 with 2.6.35-28 also on x64. I've also tested lirc 0.9.0 on the failing system with the same results--I compiled 0.9.0 with debug mode turned on and sure enough, the log includes repeated sequences of 'failed on sync', then 'sync', then 'failed on header', then 'failed on sync', then 'sync'.
I think the problem might be with syncing the 'gap'. On the working system, mode2 output starts with 'space 100000' and ends with 'pulse 600' (the correct 'gap' and 'ptrail' values), but on the failing system, mode2 output starts with the header and ends with ptrail/gap. I believe the failing system might be trying to sync on the gap value but is instead receiving the header. When I press a button twice in succession, the failing system is able to decode a packet correctly because (I suspect) it is able to sync on the gap after the first packet and thus properly decode the second.
I think the issue might be with the driver and the order in which it delivers pulse/space signals, but on both systems it's mceusb. Could it have changed that much between 0.8.7-pre3 and 0.8.7? I know it's shipped with the kernel now, but both of my systems are still at kernel 2.6.35, including the one where it works flawlessly. I see from this post
that Ubuntu 10.10 uses an old driver. Curiously, the driver built by 0.8.7 is called lirc_mceusb, but in both systems the driver reported by lsmod is called just 'mceusb'. Any advice on which driver I should be using, or if the issue is related to something else?