Input Not Getting Picked up

[cuppajoeman]

Hey I'm working on a game, and I've started to notice that my inputs get frozen in terms of the mouse and keyboard callback, this seems to have to do with the workload of the game, because on a small resolution there are no issues:

input_small_res.mp4

Note that the black arrow represents what is stored in a struct representing the state of the keyboard which gets written to in the keyboard callback.

When I crank up the resolution to 1920x1080, notice that I get a frozen right input and the mouse starts snapping weirdly:

input_big_res.mp4

Note that q is the button to quit and I have to press that 28 times for it to get recognized.

I'm trying to understand why this might happen and what I can do to stop this from happening, any help is appreciated thanks. I do not implement any type of custom thread behavior btw if that helps.

[dougbinks]

I've marked this as support rather than an issue as I think you are asking for help with understanding how to properly use input at low framerates, and because I don't think this is a core issue in GLFW.

It's difficult to help without knowing any of the source code.

If you suspect there is an issue with GLFW at low poll rates on your system then you should test with the events.c program adding a sleep to slow down the rate of the loop. In my testing on Windows 11 this has no effect.

[cuppajoeman]

Hey @dougbinks from what you're saying it seems like this is unexpected behavior with respect to GLFW and that you would expect GLFW to correctly pick up on on inputs even if the rate of the loop is slow. Also In the second video I posted I turned on v-sync which is why the frame rate was around 55-60fps, regularly that's running at around 150fps and the issue still persists.

I'll see if I can cook up a minimal working example (I'm working on linux).

In the mean time are there any other sanity checks that can be done? Like measuring how frequent the keyboard callback actually gets called? Or something to prove that this isn't GLFW's fault?

[dougbinks]

Note that the black arrow represents what is stored in a struct representing the state of the keyboard which gets written to in the keyboard callback.

Ah, I understood from this sentence that you were receiving all the input to your callback, so had already debugged that it was not a GLFW issue. Since you're not sure I've removed the support tag.

In the mean time are there any other sanity checks that can be done?

As I mention the place to start is with the test events.c. I altered this to add a sleep(1) ( with #include <unistd.h>) and additionally modified the callback to close the window as below. This worked for me on Ubuntu 22.04.4 LTS, all key presses are registered and I only need to press the ESCAPE key once to exit.

static void key_callback(GLFWwindow* window, int key, int scancode, int action, int mods)
{
    Slot* slot = glfwGetWindowUserPointer(window);

    if (key == GLFW_KEY_UNKNOWN)
    {
        printf("%08x to %i at %0.3f: Key (%s) Scancode 0x%04x (with%s) was %s\n",
                counter++, slot->number, glfwGetTime(),
                get_key_name(key), scancode,
                get_mods_name(mods),
                get_action_name(action));
    }
    else
    {
        const char* name = glfwGetKeyName(key, scancode);
        if (name)
        {
            printf("%08x to %i at %0.3f: Key 0x%04x (%s) Scancode 0x%04x Name %s (with%s) was %s\n",
                   counter++, slot->number, glfwGetTime(),
                   key, get_key_name(key), scancode, name,
                   get_mods_name(mods),
                   get_action_name(action));
        }
        else
        {
            printf("%08x to %i at %0.3f: Key 0x%04x (%s) Scancode 0x%04x (with%s) was %s\n",
                   counter++, slot->number, glfwGetTime(),
                   key, get_key_name(key), scancode,
                   get_mods_name(mods),
                   get_action_name(action));
        }
    }

    if (action != GLFW_PRESS)
        return;

    switch (key)
    {
        case GLFW_KEY_C:
        {
            slot->closeable = !slot->closeable;

            printf("(( closing %s ))\n", slot->closeable ? "enabled" : "disabled");
            break;
        }

        case GLFW_KEY_L:
        {
            const int state = glfwGetInputMode(window, GLFW_LOCK_KEY_MODS);
            glfwSetInputMode(window, GLFW_LOCK_KEY_MODS, !state);

            printf("(( lock key mods %s ))\n", !state ? "enabled" : "disabled");
            break;
        }
        case GLFW_KEY_ESCAPE:
        {
            glfwSetWindowShouldClose(slot->window, GLFW_TRUE);
            printf("(( Exiting Window ))\n");
            break;
        }

    }
}

If events.c works for you, then I would next modify your own code to add key press logging in the key callback, as per the code in events.c. This should help you debug if the problem occurs in GLFW or in the rest of your code.

Also be aware that the GLFW event polling function must be called from the main thread.

[cuppajoeman]

Hi @dougbinks just sending a message to let you know I've seen your message. I haven't gotten around to testing events.c (which I will do soon, within next 2 weeks probably).

I'm developing on a laptop and only started noticing this problem when I was connected to a secondary monitor. I haven't had a chance to do use the second monitor for a while, but this issue has not come back since then. I will try to replicate this again on that setup.

I also added information which states how many key callbacks and mouse callbacks that occur per second and print that to the screen, so I will try to use that to debug this more as well on the two screen setup.

KCBPS = Key callbacks per second.

frag-z-progress.mp4

I notice that the poll rate seems to be relative to the hardware, for example in the above video I'm using a gaming mouse which polls at ~1000 times per second, and it seems that the keyboard updates at a rate of ~20 times per second. When I hold a key down on the keyboard the rate goes down to like 7hz but when constantly switching keys it's at max 20hz (but I think that's expected?). I'll try to see if on the double monitor setup if the poll rate gets affected which might be the reason keys get stuck.