Well, depending on your goal, your solution is fine.

SFML uses the same kind of API: https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Keyboard.php

But SDL2 has a much more complex keyboard API: https://wiki.libsdl.org/CategoryKeyboard

I have found some issues with the "simple" SFML and your proposed way. Which is most likely also why the SDL2 API is much more complex. In general, there are 3 different types of keyboard input:

1. Pressing a specific physical key on the keyboard for an action (Use WASD keys for movement, independed of keyboard layout)
2. Pressing a specific named key on the keyboard for an action (Press "A" to continue, where A is located depends on keyboard layout config)
3. Typing text, coverting key presses into specific text entry actions. Pressing shift gives nothing, while shift+A is an upper case A. Generally this is more event based.

For my home grown game engine, I've build an abstraction called "KeyBinding", which solves a few different things as well, like:

• Multiple keys bound to the same action
• Checking if the key was pressed/released this frame/update cycle
• Assigning joysticks axis to keybinding as well
• Saving/loading keybindings to a file

https://github.com/daid/SeriousProton2/blob/master/include/sp2/io/keybinding.h

So consider what level of abstraction you are providing, and what your end goal is.

Also consider whether you want keys to be pressed if your application has focus or not. Big surprised if you alt-tab to a browser and the game keeps reading your input.

My code uses the HID interface and platform dependent APIs to get the input (not just Keyboard but also Mouse and GamePad). On Windows (and I think Linux too) the HID driver is populating messages to input receivers (a Window). This way what I did was to attach my input system to the main window of my application and have messages be processed as they enter.

This "event driven" input has the advantage to not query the hardware all the time but instead store updates in some kind of input manager. I also not use specific keys or key events directly like the 'A' button but instead generate a 16 bit UID for every key as it provides a state change. The UID is calculated (shifted) from the bist of the HID result like the Usage ID and the key code/mouse button or button/axis ID

Oh, and I checked your code, you seem to use "GetAsyncKeyState" for windows at least, I guess something along the same lines in linux. I've had players manage to press&release a key between 2 frame calls with that kind of setup. So I would recommend against it for things like quick arcade like games. As people get pretty annoyed when they press the jump key and nothing happens.

I know from someone at a AAA studio that you'll need some kernel functions (userspace) to aquire HID on Linux but he dosen't mentioned anything from root-privileges. I'm not at the point where we are working on the Linux port so I'm a bit out of experience here but there is a reference Lib on GitHub you might want to take a look at.

Generally for gameplay you want as less API calls as possible, so polling the state of an input key every few ms and possibly multiple times per key isn't very performance improving. You 'ld needsome type of caching the poll but this will become very complicated in a multithreaded environment. Because in async processing you'll need to know when a frame ends and the next frame starts to invalidate the state for that certain key.

Going into an event based system, you update the state just when an OS message arrives and anything else is handled by the comes first/serves first principle