On Linux, you can construct an OpenGL context without an X server on any system supporting kernel mode-setting (KMS) and EGL. This includes the open-source radeon, intel and nouveau drivers and, soon, the closed-source radeon drivers.
The OpenTK library has had support for this for a couple of years, see [1] for the implementation.
Open-source drivers have supported this for years, it's nvidia that was (very) late to the game.
Edit: this was one of the big hurdles that Wayland had to surpass, and the main reason why it took so long to develop. The whole kernel- and user-mode GPU driver infrastructure had to be rewritten first to remove reliance on the X server.
Oh it likely worked for quite some time before Wayland. Thing about Wayland is that it is not just a "dumb" canvas, but one that is to support existing UI toolkits like GTK and Qt.
Never mind that X does a lot more than just draw stuff. Its in charge of managing all those displays, keyboards and mice.
Something that various people only noticed after dabbling with Wayland and discovering that where before X was in charge of their laptops touchpad, giving them all kinds of capabilities, now GTK/Gnome was, and thus they found themselves with a massive regression.
I'm not sure you could get an accelerated OpenGL context before KMS+EGL were implemented. Indeed, even today most ARM vendors don't support accelerated OpenGL without X11/GLX.
Edit: libinput covers all your low-level input handling needs. The API is very-well designed, unlike the 3-4 separate input stacks you have to juggle in X11 (core X, XInput 1, XInput 2, XInput 2.1 etc).
Edit 2: X server is not used to draw stuff in modern applications, all drawing is handled client-side (by Qt, GTK, EFL, etc) and the X server just acts as an inefficient intermediary between the client and the compositor.
They just see the X11 driver allowing them to define their own areas etc on a touchpad, while libinput does not.
As the old "joke" about MS Office goes, 99% of their users use only 1% of the functionality. But they all use a different 1%.
Yet MS products are what has been adopted massively across the world, in large part because MS have a history of bending over backwards to not break user space.
Right now the Linux user space is pulling a "deal with it" move at massive scale, something more in tune with Apple than MS.
This will likely alienate both current and prospective users. Just look at the shit storm that happened when Apple dropped their Xserve range virtually over night.
> They just see the X11 driver allowing them to define their own areas etc on a touchpad, while libinput does not.
That's one specific X11 driver for a few specific touchpad devices and with no user interface to configure.
I doubt if more than a handful of users ever bothered to read the manpages to find out about this functionality, much less actually define their own touchpad regions. I'm sure there are a few exceptions, but the vast majority of the users just use the defaults or tweak whatever settings Gnome/KDE exposes in their UI.
In fact, the mere fact that an X11 touchpad driver provides this functionality is actually proof of why X11 has outlived its usefulness. Touchpad regions do not belong to the touchpad driver. They belong to the layer that interprets touchpad input above that - it should be a desktop-environment feature that works with all touchpads, not a driver feature that works with a single touchpad make.
Libinput is correct in not providing a kitchensink.
Never mind that the kernel devs were willing to keep some age old storage subsystem around simply from getting a verified report that someone was still using it.
The OpenTK library has had support for this for a couple of years, see [1] for the implementation.
[1] https://github.com/opentk/opentk/blob/develop/Source/OpenTK/...