Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#6 key presses behave as if held indefinitely

open
nobody
None
5
2009-09-14
2009-09-14
Ryan Olf
No

I know there is a similar bug to this already reported, however I find the repeated presses ALWAYS occur. I am pretty sure it is NOT a reception issue. Excuse me if another but is not warranted.

This bug relates specifically to use of the keyboard. I am not sure if similar issues exist with remote buttons.

The issue I experience is that every time I press a key, the system behaves as if the key were held until another button is pressed, at which point it is as if that key is held. I do not believe this to be a reception issue for two reasons. First, my IR receiver has a light on the front that is lit when I hold a key. When I release a key, the light becomes unlit. Clearly, then, the receiver can detect when key is depressed. However, the system does not seem to recognize this.

Also, I have read elsewhere that this is a known issue. For example, this tutorial http://ubuntuforums.org/showthread.php?t=782864 recommends using the 0.1.5 version to avoid this issue. However, I found this older version not to work with my MCE IR receiver.

I am using Ubuntu Jaunty, with the 2.6.28-15-generic kernel and lirc 0.8.4a. I use the 0.8.4a lirc_dev.h file when compiling.

Thank you so much for making this module, and let me know if I can help you stomp this bug.

Discussion

  • Ryan Reading
    Ryan Reading
    2010-01-03

    I was having the same issue with v0.2.1 and finally found a fix. The problem that I observed was caused because the driver was analyzing all the IR data (peaks?) upon completion of transmission. Each transmission is ended with what is called (in the driver) a MCE_CONTROL_HEADER packet.

    The new driver has logic that will stop analyzing data once that packet comes in, even if there is "un-analyzed" data left in the buffer. That data doesn't get analyzed until the next keypress happens. So in effect, the "key up" even never gets sent to the input layer.

    After looking at the code, I'm not sure the key up event is being detected correctly. And maybe the intention is that end of transmission should signal key up, but that doesn't seem explicit (just circumstantial) in the driver.

    Bottom line, this fixes the problem (atleast for me):

    Change this block at lirc_mod_mce.c:658 in decode_buffer():

    if (ir->buf_in[offset] == MCE_CONTROL_HEADER)
    break;

    to this:

    if (ir->buf_in[offset] == MCE_CONTROL_HEADER)
    {
    /* If we hit this, it's the end of the current transmission, analyze everything up to this point */
    do_analyze(ir, &ir->peaks[ir->sync_pos], ir->peak_index - ir->sync_pos + 1);
    break;
    }

    I've only test a little bit at this point, but if anyone can give feedback on any side affects, let me know.

     
  • Ryan Olf
    Ryan Olf
    2010-03-01

    @ryanr23: Thanks for the suggestion. I tried that solution and it doesn't seem to have any effect in my setup. What kind of IR receiver do you have? I have the Topseed (device ID 0x0008).