Bug 117221
| Summary: | RC5 decoding broken in 3.17 onwards | ||
|---|---|---|---|
| Product: | v4l-dvb | Reporter: | Jonathan McDowell (noodles) |
| Component: | v4l-other | Assignee: | v4l-other (v4l-dvb_v4l-other) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | david |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.17 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Kernel log of failing RC5x decode | ||
I've spent some time trying to find details of RC5x (a search for "RC5 extended" works much better) and decoding the debug output of recent kernels. It seems I was mistaken; the remote is outputting what looks like RC5 but has a shorter trailer than the new code is expecting. I only see 6350us space at the end, which is roughly 9 units, rather than the 10 (RC5_TRAILER) the code is expecting. I don't currently have access to the machine in question, but I will try a recent kernel later this week with RC5_TRAILER set to 9 * RC5_UNIT and see if that resolves the issue. Ok, yes...the commit you've pinpointed introduced the trailer check. The "real" trailer value is rather like 100 * RC5_UNIT...but I've already seen that a lot of IR hardware just reports a "long" silence and then stops recording. For all the hardware that I could test, 10 * RC5_UNIT was sufficient, but if your hardware cuts it off around 8-9, then I'm pretty certain that RC5_TRAILER could be reduced a bit more without any bad side effects. Turns out to need reduced to 6 units as the Fintek doesn't seem to provide a space longer than 6350us and there needs to be room for a final space as part of the command as well. I've submitted a patch which is confirmed to work on my Fintek setup. This was fixed in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bbdb34c90aeb8b2253eae88029788ebe1d7f2fd4 (v4.8-rc1 onwards) |
Created attachment 214361 [details] Kernel log of failing RC5x decode I have a nettop with a fintek CIR device in it. It's running Debian jessie and thus using a 3.16 based kernel. I recently tried to upgrade to a 4.4 based backport in order to get support for newer DVB-T2 devices. However this has broken my remote control setup. Further investigation revealed the problem exists in 3.17 onwards. The remote in question is a repurposed Virgin Media VBOX HD remote (URC174000-04R01). It appears that it is an RC5x based remote and that commit e87b540be2dd02552fb9244d50ae8b4e4619a34b merging the rc5 and streamzap decoders is responsible for the issue. If I revert this commit from a 4.5.2 kernel my remote starts working again. I'm unable to find a decent description of RC5x to come up with a cleaner fix than the revert at present, but attach a debug log (echo 2 > /sys/modules/rc_core/parameters/debug) of a failing keypress in the hope that's helpful.