Personally for me - the problematic part of gaming on Linux has been input(i.e mouse) latency and acceleration profile.
I am not sure if this is just my experience but when using libinput on Fedora for example - the cursor movement is not exactly precise. This is not obvious when working but while gaming this is a deal breaker.
Games in Windows can get raw mouse input just by writing the code for it, and Linux games usually don't because that would require root permissions, to add the user to the input group, etc.
It is a security issue and an X-Window design issue.
Oblivious question: is there any notion of granulated permissions, ie a ‘mouse’ user group that the game could add itself to? Seems like something like this shouldn’t be a deal-breaker.
There is an 'input' user group, which gives you access to raw mouse, keyboard, joystick, et c. under `/dev/input/`. (I'm sure you could configure udev to use more more granular user groups for different types of input devices, if you really wanted). Normal human users of a single-user system should be members of the 'input' group, so this "should" be a non-issue.
I have added support for reading the input device directly on my 3D game engine exactly so i can provide unfiltered mouse input, but at least on Debian (and i think on derivatives) the user isn't on the 'input' group by default. The engine shows a message if raw input is enabled it cannot open the device handle (something like "cannot open handle check if you have permissions for accessing - maybe you need to be in the input group?") and it falls back to regular X11 events (the feeling of which depend greatly on the current configuration, which input driver is used, etc - on my PC where i use udev and 1:1 mapping it feels fine, but others use libinput, which i think is the default nowadays, and mappings can be all over the place).
It does but this is only in an environment where the same computer is accessible by more than one people at the same time with different keyboards and monitors. In practice this is an extremely rare case and in that case (and assuming the people involved cannot just trust each other for some reason) the permissions can be set to only allow access to a single device per user.
There is nothing in its design that prevents X windows to be made to send an event like WM_INPUT that games can handle in a similar way to how they handle WM_INPUT on Windows today.
Seems like in an ideal world, games would select that profile programmatically. Assuming, of course, that there's no reason to prefer mouse acceleration and that we're talking about using the mouse as a linear controller for stuff like aiming or moving.
Ideally yes, but remember that a lot of these games aren't designed for Linux but are effectively running in a compatibility layer for Windows. There is no way for the programmers to know that they need to be interacting with a Linux window manager's behavior.
Good point. I guess the emulator could request the profile, but then you either need a one-size-fits-all approach or somebody has to maintain a database of which games to enable it for.
A critical distinction is that it's not an emulator. "Compatibility layer" is a great description of what's actually happening. It's a (set of) native library(ies) which provide the ABI and call targets that are expected by the software and wrap around native OS functions to provide those.
To use a metaphor, it's like someone made a replacement edge for a puzzle, which interlocks with a subset of existing pieces for another puzzle rather than someone making a table-sandbox within which to use the the entire initial puzzle.
Right. I've used the wrong terminology technically because the machine code is running natively. (I'm not aware of a succinct term for what WINE does, though, so I guess I'm being sloppy for convenience.)
I am not sure if this is just my experience but when using libinput on Fedora for example - the cursor movement is not exactly precise. This is not obvious when working but while gaming this is a deal breaker.