|Summary:||app-misc/lirc-*: livedrive_midi.c: livedrive_rec_midi fails to see SYSEX_END until logprintf(…) is added above it.|
|Product:||Gentoo Linux||Reporter:||Navid Zamani <navid.zamani>|
|Component:||Current packages||Assignee:||Craig Andrews <candrews>|
|Package list:||Runtime testing required:||---|
Description Navid Zamani 2012-05-14 23:34:51 UTC
The problem I have, is that lirc doesn’t seem to notice anything coming in from my remote. I tracked it down to the livedrive_rec_midi function in livedrive_midi.c, where the expression in the “if” at line 52 evaluates to false (Meaning that there is no SYSEX_END, but there should be, so the input is invalid. In practice midi.sysex_end is zero.) Of course I wanted to know what is actually ending up in midi.sysex_end. So I added a logprintf like so, right above the “if” in line 52: logprintf(3, "midi.key = %X", midi.key); And here’s the kicker: THEN IT WORKED! irw now properly shows the input! Yes, I’m serious. And yes, I can’t believe it either. I tried it multiple times, toggling between leaving out the logprintf, and adding it again… and it always results in the same. Of course it has nothing to do with the rest of the code, and shouldn’t do anything. But it does! Since I’m not a C programmer and don’t really know the toolchain, I’m utterly stuck and stumped. IMPOSSIBRU!! Here is a complete overview of how to reproduce it, even without the hardware: _. The version doesn’t matter. I tried all versions in Portage, including -9999. A. 1. # echo LIRC_DEVICES="livedrive_midi" >> /etc/make.conf 2. # emerge lirc 3. # echo 'LIRCD_OPTS="-H livedrive_midi -d YOURMIDIDEVICE"' # (Set YOURMIDIDEVICE to your file. Here, that’s /dev/snd/midiC0D1.) 4. # /etc/init.d/lircd start 5. # irw 6. Now press a button on the remote. (There is a way to simulate it, e.g. by directing LIRC to read from another file that you feed manually. You would feed it the binary representation of this: F00020216000010A4144[KEY]F7. Where “[KEY]” is the button code. E.g. one of: 512E, 710E, 215E.) 7. Wait a bit, see nothing coming out, and then kill irw. B. 8. # ebuild "$(equery w lirc)" configure 9. # cd /var/tmp/portage/app-misc/lirc-*/work/lirc-*/daemons/ 10 # $EDITOR livedrive_midi.c 11. Go to line 52 (at least in version 0.8.7), where the comment is. Above the "if (midi.sysex_end != SYSEX_END)" in line 53. 12. Add the following line above: logprintf(3, "midi.key = %X", midi.key); # Note that logging “midi.sysex_end” does *not* work. (Haven’t tested for other single value loggings, but when logging more than one value of “midi”, it works as long as “midi.key” is in there.) 13. # ebuild "$(equery w lirc)" merge 14. # /etc/init.d/lircd restart 15. # irw 16. Again, press a button on the remote. (Or simulate it.) 17. Wait a bit, see something like “LONGHEXVALUE 00 KEYNAME REMOTENAME” being displayed (e.g. “000000008322857a 00 stop Creative_RM900”), then kill irw. The differences between the output of irw in A and B is the bug. In both cases it should be like in (B.17).
Comment 1 Navid Zamani 2012-05-14 23:40:22 UTC
Oops, there are some inconsistencies in my comment, because I made progress while writing it. • Originally I did not know that midi.sysex_end is zero instead of 0xF7 when the bug occurs. • And I had to replace the logprintf of midi.sysex_end by midi.key, because I found out, that the bug still happens when logprintfing midi.sysex_end. • Also, “line 52” (of livedrive_midi.c) always is meant for version 0.8.7 of lirc. (But I don’t think the code changed much or at all in the last years.)
Comment 2 Ian Stakenvicius 2012-09-27 19:21:13 UTC
Please retest with lirc-0.9.0-r2 and if it still occurrs, I'll patch it. I expect that somehow, without the logprintf, parts of the code are being optimized out when they shouldn't be.
Comment 3 Navid Zamani 2012-10-01 05:33:02 UTC
Hey, I just tried the 0.9.0-r2… No changes. It still doesn’t work. I hope your patch will be bit more elegant than my quick-and-dirty logprintf though. ;)
Comment 4 Navid Zamani 2012-12-02 02:09:04 UTC
Okay, I just merged 0.9.0-r2 again, and this is still the case. I’m wondering about upstream right now. I would contact them, if you haven’t already.
Comment 5 Craig Andrews 2016-07-31 22:16:59 UTC
Please report this issue upstream and link to it here if you can still reproduce this issue.