New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When two keys are pressed at the same time the second callback is delayed #1112

Open
fractilegames opened this Issue Oct 29, 2017 · 10 comments

Comments

5 participants
@fractilegames

fractilegames commented Oct 29, 2017

I'm testing this on Xubuntu 17.04 x86_64 and using GLFW from github master from about two months ago. I modified the key callback in the simple example application like this:

static void key_callback(GLFWwindow* window, int key, int scancode, int action, int mods)
{    
    struct timespec ts;
    struct tm lts;
    clock_gettime(CLOCK_REALTIME, &ts);
    localtime_r(&ts.tv_sec, &lts);

    char timestamp[32];
    sprintf(timestamp, "%04d-%02d-%02d %02d:%02d:%02d.%03d", lts.tm_year + 1900, lts.tm_mon + 1, 
        lts.tm_mday, lts.tm_hour, lts.tm_min, lts.tm_sec, (int)(ts.tv_nsec / 1000000));

    printf("%s key_callback(%p, %d, %d, %d, %d)\n", timestamp, window, key, scancode, action, mods);

    if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
        glfwSetWindowShouldClose(window, GLFW_TRUE);
}

This is what see when I slam down I and L keys down at exact same time:

2017-10-29 17:45:29.716 key_callback(0x55f7e199aea0, 73, 31, 1, 0)
2017-10-29 17:45:30.217 key_callback(0x55f7e199aea0, 76, 46, 1, 0)
2017-10-29 17:45:30.267 key_callback(0x55f7e199aea0, 76, 46, 2, 0)
2017-10-29 17:45:30.317 key_callback(0x55f7e199aea0, 76, 46, 2, 0)
2017-10-29 17:45:30.367 key_callback(0x55f7e199aea0, 76, 46, 2, 0)
2017-10-29 17:45:30.417 key_callback(0x55f7e199aea0, 76, 46, 2, 0)
2017-10-29 17:45:30.467 key_callback(0x55f7e199aea0, 76, 46, 2, 0)
2017-10-29 17:45:30.517 key_callback(0x55f7e199aea0, 76, 46, 2, 0)
2017-10-29 17:45:30.567 key_callback(0x55f7e199aea0, 76, 46, 2, 0)
2017-10-29 17:45:30.601 key_callback(0x55f7e199aea0, 73, 31, 0, 0)
2017-10-29 17:45:30.601 key_callback(0x55f7e199aea0, 76, 46, 0, 0)

The first callback comes right away, but the second one comes after 500ms delay, at the same time when the repeat callback start coming.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Oct 29, 2017

Member

Cannot reproduce with 3.2.1 or current master on MATE on Ubuntu 17.04.

Member

elmindreda commented Oct 29, 2017

Cannot reproduce with 3.2.1 or current master on MATE on Ubuntu 17.04.

@fractilegames

This comment has been minimized.

Show comment
Hide comment
@fractilegames

fractilegames Oct 29, 2017

Updating to latest master did not change anything here. I will see if I can reproduce this elsewhere.

fractilegames commented Oct 29, 2017

Updating to latest master did not change anything here. I will see if I can reproduce this elsewhere.

@fractilegames

This comment has been minimized.

Show comment
Hide comment
@fractilegames

fractilegames Oct 30, 2017

I can't reproduce this on my laptop's own keyboard. It only happens on external USB keyboard. To rule out bad keyboard behavior I captured USB messages from the keyboard and it reports both key presses immediately as it should.

The interesting thing here is that the delayed input happens only when both key presses arrive in the same USB message.

Digging into source code, I found this in x11_window.c:

                // HACK: Ignore duplicate key press events generated by ibus
                //       These have the same timestamp as the original event
                //       Corresponding release events are filtered out
                //       implicitly by the GLFW key repeat logic
                if (window->x11.lastKeyTime < event->xkey.time)
                {
                    if (keycode)
                        _glfwInputKey(window, key, keycode, GLFW_PRESS, mods);

                    window->x11.lastKeyTime = event->xkey.time;
                }

When the key presses arrive in the same USB message the key press events here have the same time stamp, so it seems likely that the other key event gets rejected by this "hack".

fractilegames commented Oct 30, 2017

I can't reproduce this on my laptop's own keyboard. It only happens on external USB keyboard. To rule out bad keyboard behavior I captured USB messages from the keyboard and it reports both key presses immediately as it should.

The interesting thing here is that the delayed input happens only when both key presses arrive in the same USB message.

Digging into source code, I found this in x11_window.c:

                // HACK: Ignore duplicate key press events generated by ibus
                //       These have the same timestamp as the original event
                //       Corresponding release events are filtered out
                //       implicitly by the GLFW key repeat logic
                if (window->x11.lastKeyTime < event->xkey.time)
                {
                    if (keycode)
                        _glfwInputKey(window, key, keycode, GLFW_PRESS, mods);

                    window->x11.lastKeyTime = event->xkey.time;
                }

When the key presses arrive in the same USB message the key press events here have the same time stamp, so it seems likely that the other key event gets rejected by this "hack".

@elmindreda elmindreda added this to High Priority in Review Queue Nov 3, 2017

@fractilegames

This comment has been minimized.

Show comment
Hide comment
@fractilegames

fractilegames Nov 12, 2017

I tried changing the condition to window->x11.lastKeyTime <= event->xkey.time. That fixed this issue, but (unsurprisingly) broke #747 again.

I understood that #747 should have only happened with very low polling rates. As I retested it in Ubuntu Budgie (like in #996), I saw the excess callbacks even with high (at least 30 fps) frame rates when running the simple -example.

Edit: That hack with <= condition actually still suppressed all but the last excess key events. The last "ghost" event came with exact same time stamp and now passed the condition.

fractilegames commented Nov 12, 2017

I tried changing the condition to window->x11.lastKeyTime <= event->xkey.time. That fixed this issue, but (unsurprisingly) broke #747 again.

I understood that #747 should have only happened with very low polling rates. As I retested it in Ubuntu Budgie (like in #996), I saw the excess callbacks even with high (at least 30 fps) frame rates when running the simple -example.

Edit: That hack with <= condition actually still suppressed all but the last excess key events. The last "ghost" event came with exact same time stamp and now passed the condition.

@temp832

This comment has been minimized.

Show comment
Hide comment
@temp832

temp832 Dec 6, 2017

Any progress with this issue?

temp832 commented Dec 6, 2017

Any progress with this issue?

@fractilegames

This comment has been minimized.

Show comment
Hide comment
@fractilegames

fractilegames Dec 8, 2017

I ended up temporarily disabling X input method usage completely by commenting out XOpenIM call in initialization. I'm not sure what side effects this has, but at least my keyboard controls work well now.

fractilegames commented Dec 8, 2017

I ended up temporarily disabling X input method usage completely by commenting out XOpenIM call in initialization. I'm not sure what side effects this has, but at least my keyboard controls work well now.

@fonkap

This comment has been minimized.

Show comment
Hide comment
@fonkap

fonkap Feb 27, 2018

Same problem here. I also detected other kind of events ignored, for example when releasing a key and pressing another one very quickly or simultaneously (not very easy to reproduce).

Commenting out XOpenIM, also worked for me.

My system is Ubuntu 16.04.3 LTS (Unity)
My glfw version is current master (commit 0d45347)

fonkap commented Feb 27, 2018

Same problem here. I also detected other kind of events ignored, for example when releasing a key and pressing another one very quickly or simultaneously (not very easy to reproduce).

Commenting out XOpenIM, also worked for me.

My system is Ubuntu 16.04.3 LTS (Unity)
My glfw version is current master (commit 0d45347)

@fractilegames

This comment has been minimized.

Show comment
Hide comment
@fractilegames

fractilegames Oct 4, 2018

Is there a plan to fix this at some point? I won't be able to return to "official" GLFW version before this is somehow resolved. This is a major problem in fast-paced keyboard controlled games.

fractilegames commented Oct 4, 2018

Is there a plan to fix this at some point? I won't be able to return to "official" GLFW version before this is somehow resolved. This is a major problem in fast-paced keyboard controlled games.

@ObsydBT

This comment has been minimized.

Show comment
Hide comment
@ObsydBT

ObsydBT Oct 9, 2018

I'm experiencing this issue too! (Using GLFW through LWJGL) I'm on X11, Fedora 4.18.11-200.fc28.x86_64, with an USB keyboard. Any news regarding this issue?

ObsydBT commented Oct 9, 2018

I'm experiencing this issue too! (Using GLFW through LWJGL) I'm on X11, Fedora 4.18.11-200.fc28.x86_64, with an USB keyboard. Any news regarding this issue?

@ObsydBT

This comment has been minimized.

Show comment
Hide comment
@ObsydBT

ObsydBT Oct 13, 2018

Commenting out _glfw.x11.im = XOpenIM(_glfw.x11.display, 0, NULL, NULL); also works for me!

ObsydBT commented Oct 13, 2018

Commenting out _glfw.x11.im = XOpenIM(_glfw.x11.display, 0, NULL, NULL); also works for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment