
EGL Eye: OpenGL Visualization Without an X Server - ingve
http://devblogs.nvidia.com/parallelforall/egl-eye-opengl-visualization-without-x-server/
======
Aeolos
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.

[1]
[https://github.com/opentk/opentk/blob/develop/Source/OpenTK/...](https://github.com/opentk/opentk/blob/develop/Source/OpenTK/Platform/Linux/LinuxGraphicsContext.cs)

------
striking
A free and open alternative:
[http://www.virtualgl.org/](http://www.virtualgl.org/)

Nvidia have a lot of cool tech but they really don't like to share any of it.
Their actions are not super great.

~~~
kmicklas
That does something completely different.

------
shmerl
Yet, Nvidia's driver still doesn't work with KWin in EGL mode in KDE Plasma 5.

And I hope there will be more focus on WSI + Vulkan going forward (instead of
EGL + OpenGL).

------
dalke
Sweet! Software I once helped develop (in the 1990s) was used to create
protein/ligand image.

------
pavlov
I can't believe it's taken this long to get OpenGL without X on desktop Linux.
Definitely better late than never!

~~~
Aeolos
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.

~~~
digi_owl
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.

~~~
Aeolos
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.

Wayland simply removes that intermediary.

~~~
digi_owl
And the user don't care.

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.

~~~
Aeolos
> 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.

~~~
digi_owl
[https://xkcd.com/1172/](https://xkcd.com/1172/)

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.

