Invalid scancode error on key entry

I am posting this here, along with the solution in the hopes that others may find this useful, either in diagnosing the problem or assisting developers of GLFW in improving code robustness.

I am writing code on an Ubuntu 20.04 64Bit system. The language of choice is Go, and I am using a GUI library called Fyne. Fyne in turn makes use of GLFW. I created a text box (referred to as Entry by Fyne) for text entry by a user. If I entered alpha-numeric characters the program worked just fine, however if I entered anything like left/right/up/down arrow keys, backspace or Enter, I would get the following (Fyne) error reported in the terminal window:
GLFW poll event error: InvalidValue: Invalid scancode

I edited the GLFW library file (x11_window.c) to expand a little on the error, and discovered that whenever I hit the enter key, scancode was returning 36 (ASCII for ‘$’ symbol). A key value of -1 was being reported back to Fyne as well.

Some further investigation showed (under my Ubuntu settings) that I was running both a South African as well as a US keyboard layout. This machine has been running just fine in this manner for several years, and this is the first time I have had any issues with regards to the keyboard, so I knew this to be the case but left well enough alone before. I deleted the South African keyboard and confirmed the US keyboard was working (using the built in Ubuntu keyboard test facility found under settings) perfectly. Following this I retried my application, and voila no more scancode errors!

Given that I have never had problems before with the South African keyboard installed, I am inclined to think there is some corner case bug hidden in GLFW that could better manage this scenario.

Hi @GWevroy,

Welcome to the GLFW forum, and thanks for the detailed information and investigation!

It’s possible that this is related to a known fixed issue which should be part of the 3.3.3 release (not yet complete).

If you’re able to clone the latest GLFW source code and build using CMAKE there is a test called events.c which can be run to confirm if the issue is present on the latest release.



thanks for the response. Yes I see it as the least I can do (RE detailed response) given the benefit I attain from open source software such as yours.

At the moment I am using GLFW indirectly, as it is integrated into the Fyne library I am presently using, and I don’t want to create any potential version mismatch issues by trying to force Fyne to use anything other than the version files it came with.

With that said, I am in regular contact with the Fyne developers, and when I see that the version of GLFW has been upgraded by them I will be more than happy to run this test.

Thanks again for the great work!