Bug 85721
| Summary: | IR Remote IMon stopped working without errors in log | ||
|---|---|---|---|
| Product: | v4l-dvb | Reporter: | a_user |
| Component: | v4l-other | Assignee: | v4l-other (v4l-dvb_v4l-other) |
| Status: | NEW --- | ||
| Severity: | high | CC: | bugz.rod.k, dmitry.torokhov, jaculor, mchehab |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.17.0 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
syslog
Enable RC5-SZ decoding at rc5-decoder |
||
Bug is not present in newst mainline 3.16.4 kernel btw. I'll try to find some time bisecting the 3.17.xx kernels if there is interest at all. Common, no one cares? Did i did something wrong? Issue still present on 3.17.1. I think iMon belongs to media (Mauro). Bisecting would help greatly. Please note that many people are traveling for LinuxCon/Plumbers/etc. Thank you very much for your answer. I did bisect and the problem starts with 3.17.0 rc1. All 3.16.x kernels work fine and all 3.17 kernels have the problem. I have also experienced problems with my IR remote starting with 3.17-rc1 and continuing through 3.18-rc1, but my problems are with a streamzap remote that I use for MythTV. I'm not sure that the problems are related but the timeframes coincide.
I have noticed that /sys/class/rc/rc0/protocols isn't getting initialized properly in these kernel versions.
# cat /sys/class/rc/rc0/protocols
other unknown rc-5 nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd lirc xmp
Since the only protocols that I have enabled are CONFIG_LIRC and CONFIG_IR_RC5_DECODER, they should be the only ones shown.
rc-5-sz (CONFIG_IR_RC5_SZ_DECODER) is obsolete starting with 3.17 but is still listed.
I noticed that in these versions, drivers/media/rc/rc-main.c contains the following structure which includes the obsolete rc-5-sz protocol:
static struct {
u64 type;
char *name;
} proto_names[] = {
{ RC_BIT_NONE, "none" },
{ RC_BIT_OTHER, "other" },
{ RC_BIT_UNKNOWN, "unknown" },
{ RC_BIT_RC5 |
RC_BIT_RC5X, "rc-5" },
{ RC_BIT_NEC, "nec" },
{ RC_BIT_RC6_0 |
RC_BIT_RC6_6A_20 |
RC_BIT_RC6_6A_24 |
RC_BIT_RC6_6A_32 |
RC_BIT_RC6_MCE, "rc-6" },
{ RC_BIT_JVC, "jvc" },
{ RC_BIT_SONY12 |
RC_BIT_SONY15 |
RC_BIT_SONY20, "sony" },
{ RC_BIT_RC5_SZ, "rc-5-sz" },
{ RC_BIT_SANYO, "sanyo" },
{ RC_BIT_SHARP, "sharp" },
{ RC_BIT_MCE_KBD, "mce_kbd" },
{ RC_BIT_LIRC, "lirc" },
{ RC_BIT_XMP, "xmp" },
};
I hope that this helps track down the issue.
WARNING: I have almost zero kernel hacking experience! Everything below may be BS. I hope not. ;-)
I have finally been able to get my Streamzap remote working with 3.18-rc1 by fixing the proto_names structure in rc-main.c. I believe that this same fix should also work for 3.17 but I haven't tried it.
Since RC_BIT_RC5_SZ has been combined with the other RC5 protocols, the structure needs to be:
static struct {
u64 type;
char *name;
} proto_names[] = {
{ RC_BIT_NONE, "none" },
{ RC_BIT_OTHER, "other" },
{ RC_BIT_UNKNOWN, "unknown" },
{ RC_BIT_RC5 |
RC_BIT_RC5X|
RC_BIT_RC5_SZ, "rc-5" },
{ RC_BIT_NEC, "nec" },
{ RC_BIT_RC6_0 |
RC_BIT_RC6_6A_20 |
RC_BIT_RC6_6A_24 |
RC_BIT_RC6_6A_32 |
RC_BIT_RC6_MCE, "rc-6" },
{ RC_BIT_JVC, "jvc" },
{ RC_BIT_SONY12 |
RC_BIT_SONY15 |
RC_BIT_SONY20, "sony" },
{ RC_BIT_SANYO, "sanyo" },
{ RC_BIT_SHARP, "sharp" },
{ RC_BIT_MCE_KBD, "mce_kbd" },
{ RC_BIT_LIRC, "lirc" },
{ RC_BIT_XMP, "xmp" },
};
Here's a patch:
# cat rc-proto_names.patch
--- a/drivers/media/rc/rc-main.c 2014-10-20 01:08:38.000000000 +0000
+++ b/drivers/media/rc/rc-main.c 2014-10-22 23:34:47.653144954 +0000
@@ -783,8 +783,9 @@
{ RC_BIT_NONE, "none" },
{ RC_BIT_OTHER, "other" },
{ RC_BIT_UNKNOWN, "unknown" },
- { RC_BIT_RC5 |
- RC_BIT_RC5X, "rc-5" },
+ { RC_BIT_RC5 |
+ RC_BIT_RC5X|
+ RC_BIT_RC5_SZ, "rc-5" },
{ RC_BIT_NEC, "nec" },
{ RC_BIT_RC6_0 |
RC_BIT_RC6_6A_20 |
@@ -795,7 +796,6 @@
{ RC_BIT_SONY12 |
RC_BIT_SONY15 |
RC_BIT_SONY20, "sony" },
- { RC_BIT_RC5_SZ, "rc-5-sz" },
{ RC_BIT_SANYO, "sanyo" },
{ RC_BIT_SHARP, "sharp" },
{ RC_BIT_MCE_KBD, "mce_kbd" },
## end patch
/sys/class/rc/rc0/protocols still doesn't get initialized properly and still shows all the protocols instead of just the ones that were actually included in the kernel, but rc-5-sz is now combined with rc-5 as it should be.
# cat /sys/class/rc/rc0/protocols
other unknown rc-5 nec rc-6 jvc sony sanyo sharp mce_kbd lirc xmp
But, since none of the protocols have been enabled by default, I needed one more hack to get things working.
# echo "rc-5" >/sys/class/rc/rc0/protocols
This enables the protocol needed by the Streamzap, as shown below.
# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] nec rc-6 jvc sony sanyo sharp mce_kbd lirc xmp
If /sys/class/rc/rc0/protocols was being initialized properly, it would show the following and the echo statement above wouldn't be necessary.
# cat /sys/class/rc/rc0/protocols (if working properly)
[rc-5] [lirc]
I'm looking at show_protocols() in drivers/media/rc/rc-main.c, but I haven't pinpointed the problem yet.
Rod, thank you for your contribution. I hope some of the devs finally takes not of this issue. a_user, I'm not sure if I helped you or anyone else but I got mine working. This indicates that the merge of the rc-5-sz protocol with the other rc-5 protocols seems to be working, if only the implementation and configuration get completed. Since you don't need the rc-5-sz protocol you shouldn't need to do the patch, just enable the protocol that you need: # echo "protocol_name" >/sys/class/rc/rc0/protocols You can find out which protocol(s) were enabled in 3.16 by booting into it and doing: # cat /sys/class/rc/rc0/protocols Whichever ones are in brackets are the enabled ones. If you need to enable more than one, you can do: # echo "protocol_1 +protocol_2 +protocol_3" >/sys/class/rc/rc0/protocols I put the command in the startup file for lircd: /etc/init.d/lircd on gentoo. It can be removed when the initialization of /sys/class/rc/rc0/protocols gets fixed. i tried what yuo suggested. Indeed all but one protocol that are enabled on 3.16 are disabled if using any newer kernel. While the enabled and available protocols for rc0 are the same the protocols on rc1 differ. There only rc-5 is enabled on 3.17 or 3.18 kernel. Like you suggested i enabled all missing protocols but the remote is still not working after that. I tried stopping and enabling lirc again and still no reaction on irw command. So i can confirm that since 3.17 the protocols are not being set but it seems that this is not all that is needed to getting iMon remote of my chieftec case working again. :( a_user, I can't help you with testing rc1 since I don't have one. I guess we will just have to wait for someone who actually knows what they are doing to take notice. zzzzzzzzzzzzzzzzzz There was a regression on 3.17 that affect LIRC users. Patches with a proposed fix it were already submitted to linux-media@vger.kernel.org (where the Linux media discussions happen): https://patchwork.linuxtv.org/patch/26517/ https://patchwork.linuxtv.org/patch/26516/ I'll be likely testing them next week. Please test if applying those patches fix the issue for you. At the moment i can't compile the kernel to apply the patches and test them. I'll see if i can do this during next week though. I applied both patches shown above.
/sys/class/rc/rc0/protocols still isn't getting initialized properly.
I currently have only one protocol defined:
<*> Enable IR raw decoder for the RC-5 protocol
But /sys/class/rc/rc0/protocols still shows all protocols being allowed, with rc-5 and lirc being enabled.
# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] nec rc-6 jvc sony sanyo sharp mce_kbd [lirc] xmp
This should only show rc-5 as both allowed and enabled, like:
# cat /sys/class/rc/rc0/protocols
[rc-5]
I still need to actually enable rc-5 before it will work:
# echo rc-5 >/sys/class/rc/rc0/protocols
Also, neither of these patches deals with changes to the proto_names structure (see above). This is needed for the rc-5-sz protocol to work now that it has been merged with the other rc-5 protocols.
More diagnostics after patches: I turned on debugging in rc-main.c int rc_core_debug = 1; /* ir_debug level (0,1,2) */ Now, the first time that show_protocols() is called, before I explicitly enable rc-5, the following is logged: show_protocols: allowed - 0xfffff, enabled - 0x24 After it is explicitly enabled: show_protocols: allowed - 0xfffff, enabled - 0x38 rc-5 should be the only one that is allowed or enabled in either case since my .config looks like this: CONFIG_RC_DECODERS=y # CONFIG_LIRC is not set # CONFIG_IR_NEC_DECODER is not set CONFIG_IR_RC5_DECODER=y # CONFIG_IR_RC6_DECODER is not set # CONFIG_IR_JVC_DECODER is not set # CONFIG_IR_SONY_DECODER is not set # CONFIG_IR_SANYO_DECODER is not set # CONFIG_IR_SHARP_DECODER is not set # CONFIG_IR_MCE_KBD_DECODER is not set # CONFIG_IR_XMP_DECODER is not set (In reply to Mauro Carvalho Chehab from comment #11) > There was a regression on 3.17 that affect LIRC users. > > Patches with a proposed fix it were already submitted to > linux-media@vger.kernel.org (where the Linux media discussions happen): > https://patchwork.linuxtv.org/patch/26517/ > https://patchwork.linuxtv.org/patch/26516/ > > I'll be likely testing them next week. > > Please test if applying those patches fix the issue for you. The patch that was applied to fix for LIRC is this one: http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?h=fixes&id=472be605bec4bbcce0b9e403206e2e7c65afc50b So, at least on my knowledge, this should be enough to fix for LIRC. (In reply to Rod from comment #13) > Also, neither of these patches deals with changes to the proto_names > structure (see above). This is needed for the rc-5-sz protocol to work now > that it has been merged with the other rc-5 protocols. This is actually a separate issue. What keytable are you using on your device? If it is this one: drivers/media/rc/keymaps/rc-streamzap.c It should work as-is, as the keytable is properly defined as: .rc_type = RC_TYPE_RC5_SZ, We don't want to merge RC5_SZ with standard RC5, as this is non-standard. That's why the patches didn't touch at the rc-main.c code you mentioned. If you're otherwise using another keytable, then perhaps the .rc_type field there is wrong. Can you provide a full dmesg log with IR debug enabled? (In reply to Mauro Carvalho Chehab from comment #15) > (In reply to Rod from comment #13) > > Also, neither of these patches deals with changes to the proto_names > > structure (see above). This is needed for the rc-5-sz protocol to work now > > that it has been merged with the other rc-5 protocols. > > This is actually a separate issue. > caveat: This is my first foray into kernel debugging and I have no expertise in this area, so if I'm in the wrong forum, violating procedures, or otherwise out-of-line feel free to slap me. But, since I got my remote working (and was feeling pretty smug) I thought that I might help diagnose the problem. I was probably just lucky anyway ;) Mauro, I think that you are correct: these are separate issues, but I think that they are related. > What keytable are you using on your device? If it is this one: > > drivers/media/rc/keymaps/rc-streamzap.c > yes > It should work as-is, as the keytable is properly defined as: > .rc_type = RC_TYPE_RC5_SZ, > > We don't want to merge RC5_SZ with standard RC5, as this is non-standard. > That's why the patches didn't touch at the rc-main.c code you mentioned. > Just to be clear, I'm not proposing that RC5_SZ be merged, that was already done when ir-rc5-sz-decoder.c and CONFIG_IR_RC5_SZ_DECODER were removed from 3.17 and the logic was merged into ir-rc5-decoder.c After looking at the modified ir-rc5-decoder.c in 3.17, I didn't see how it could work unless changes were made to the proto_names structure (see patch above). I tried it and it worked! Luck? But I need to explicitly enable rc-5 on each boot by adding a line to the init file for lircd: echo "rc-5" >/sys/class/rc/rc0/protocols I think that line is only required because of the initialization issue with /sys/class/rc/rc0/protocols, which seems related to the issue first mentioned by a_user and addressed by your patch. > If you're otherwise using another keytable, then perhaps the .rc_type field > there is wrong. > > Can you provide a full dmesg log with IR debug enabled? I'll do some more testing starting with 3.16.6 to try to pinpoint the regression and then provide the dmesg file uploads. How do I post dmesg files without just pasting them into the text? clue to problem?: Why would show_protocols: allowed ever be 0xfffff when .conf contains: CONFIG_RC_DECODERS=y # CONFIG_LIRC is not set # CONFIG_IR_NEC_DECODER is not set CONFIG_IR_RC5_DECODER=y # CONFIG_IR_RC6_DECODER is not set # CONFIG_IR_JVC_DECODER is not set # CONFIG_IR_SONY_DECODER is not set # CONFIG_IR_SANYO_DECODER is not set # CONFIG_IR_SHARP_DECODER is not set # CONFIG_IR_MCE_KBD_DECODER is not set # CONFIG_IR_XMP_DECODER is not set (In reply to Rod from comment #16) > > What keytable are you using on your device? If it is this one: > > drivers/media/rc/keymaps/rc-streamzap.c > yes Ok. > > It should work as-is, as the keytable is properly defined as: > > .rc_type = RC_TYPE_RC5_SZ, > > > > We don't want to merge RC5_SZ with standard RC5, as this is non-standard. > > That's why the patches didn't touch at the rc-main.c code you mentioned. > > > > Just to be clear, I'm not proposing that RC5_SZ be merged, that was already > done when ir-rc5-sz-decoder.c and CONFIG_IR_RC5_SZ_DECODER were removed from > 3.17 and the logic was merged into ir-rc5-decoder.c What it was merged there is the implementation for the decoder: just one driver can handle both decodings. Yet, we want an explicit way to enable RC5_SZ decoding. > After looking at the modified ir-rc5-decoder.c in 3.17, I didn't see how it > could work unless changes were made to the proto_names structure (see patch > above). Then the patch that merged SZ decoding on it is broken, as it should only be enabling it if rc-5-sz is enabled. I'll be submitting a fixup for you to test. > How do I post dmesg files without just pasting them into the text? No. Add it as an attachment. > clue to problem?: Why would show_protocols: allowed ever be 0xfffff when > .conf contains: This seems to be another separate issue, if this is happening. It should only show the protocols for the decoders that are loaded. Created attachment 155861 [details]
Enable RC5-SZ decoding at rc5-decoder
(In reply to Mauro Carvalho Chehab from comment #18) > Created attachment 155861 [details] > Enable RC5-SZ decoding at rc5-decoder Success! One issue down and one to go. Using linux-3.18-rc2.tar.xz with the patch in this attachment fixed the problem with rc-5-sz, as long as I explicitly enable it with: # echo "+rc-5-sz" >/sys/class/rc/rc0/protocols To test the protocols initialization issue, which patches should I apply besides this one? (In reply to Rod from comment #19) > (In reply to Mauro Carvalho Chehab from comment #18) > > Created attachment 155861 [details] > > Enable RC5-SZ decoding at rc5-decoder > > Success! One issue down and one to go. > > Using linux-3.18-rc2.tar.xz with the patch in this attachment fixed the > problem with rc-5-sz, as long as I explicitly enable it with: > > # echo "+rc-5-sz" >/sys/class/rc/rc0/protocols This shouldn't be needed. Can you please post the value of /sys/class/rc/rc0/protocols after rebooting and before doing any changes on it? > To test the protocols initialization issue, which patches should I apply > besides this one? You should also apply this one: http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?h=fixes&id=472be605bec4bbcce0b9e403206e2e7c65afc50b (In reply to Mauro Carvalho Chehab from comment #20) > (In reply to Rod from comment #19) > > (In reply to Mauro Carvalho Chehab from comment #18) > > > Created attachment 155861 [details] > > > Enable RC5-SZ decoding at rc5-decoder > > > > Success! One issue down and one to go. > > > > Using linux-3.18-rc2.tar.xz with the patch in this attachment fixed the > > problem with rc-5-sz, as long as I explicitly enable it with: > > > > # echo "+rc-5-sz" >/sys/class/rc/rc0/protocols > > This shouldn't be needed. Can you please post the value of > /sys/class/rc/rc0/protocols > > after rebooting and before doing any changes on it? > I expected this behavior since I had only applied the one patch; I only mentioned it for completeness. see below. > > To test the protocols initialization issue, which patches should I apply > > besides this one? > > You should also apply this one: > http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/ > ?h=fixes&id=472be605bec4bbcce0b9e403206e2e7c65afc50b Now we're getting somewhere! Not perfect but much closer. Works. using this config section: CONFIG_RC_CORE=y CONFIG_RC_MAP=y CONFIG_RC_DECODERS=y CONFIG_LIRC=m # CONFIG_IR_LIRC_CODEC is not set # CONFIG_IR_NEC_DECODER is not set CONFIG_IR_RC5_DECODER=m # CONFIG_IR_RC6_DECODER is not set # CONFIG_IR_JVC_DECODER is not set # CONFIG_IR_SONY_DECODER is not set # CONFIG_IR_SANYO_DECODER is not set CONFIG_IR_SHARP_DECODER=y # CONFIG_IR_MCE_KBD_DECODER is not set # CONFIG_IR_XMP_DECODER is not set After applying the media_tree patch linked above, we get this initially: # cat /sys/class/rc/rc0/protocols other unknown rc-5 nec rc-6 jvc sony [rc-5-sz] sanyo sharp mce_kbd [lirc] xmp dmesg contains: show_protocols: allowed - 0xfffff, enabled - 0x24 So the proper protocols are getting enabled initially but all the unavailable ones are still showing too. You can even enable ones that aren't avaliable (oops): # echo "+sanyo" >/sys/class/rc/rc0/protocols # cat /sys/class/rc/rc0/protocols other unknown rc-5 nec rc-6 jvc sony [rc-5-sz] [sanyo] sharp mce_kbd [lirc] xmp Also, the init file for lircd (/etc/init.d/lircd on gentoo) contains the following snippet: # start snippet for retval in ${LIRCD_SET_SYSCLASSRCS} ; do if [ -e /sys/class/rc/${retval}/protocols ] && \ grep -qs 'lirc' /sys/class/rc/${retval}/protocols ; then einfo "Setting lirc protocol active for ${retval}" echo lirc >/sys/class/rc/${retval}/protocols fi done # end snippet The echo statement above leaves lirc enabled but turns off rc-5-sz. I've commented this section out for testing because it shouldn't be needed with your new initialization process and it breaks things. My issue seems fixed with 3.18.0 rc4. Thanks! P.S. Should i mark it resolve or do you think there is still something to do? |
Created attachment 152691 [details] syslog While on kernel 3.16.x my iMon remote control is still working it doesn't on kernel 3.17.0. The device is correctly identified which is logged in syslog. Also lirc can connect etc. All log messages are absolutely identical to the working behavior on kernel 3.16. But actually when trying to test it by using irw (or anything else) absolutely nothing happens, neither in log nor in the terminal is any reaction seen while pressing any of the keys on the remote control. Rebooting to kernel 3.16 and it is working again. Problem is 100% reproducable. Note: The iMon Remote Control came together with my chieftec htpc case. It also has iMon Knobs on the front which are actually working even with kernel 3.17. Only the IR Remote isn't. My wireless mouse/keyboard is also working fine. I have attached my syslog of several reboots with 3.17 and 3.16.20 kernel on ubuntu 14.10. During that sessions i also tried stopping lirc and then using cat or irrecord etc. So you can see connection errors from vdr failing to connect to the lirc deamon/device.