Martin Gräßlin

I'm well out of my depth here and welcome corrections:

Managing and multiplexing access to hardware is a core responsibility of the kernel. When video drivers are implemented in user space as X11 has traditionally done there are a bunch of issues: the program that includes them has to be setuid root to have the right access to the hardware, opening up the possibility of security bugs; only one such program can run at a time; and if something goes wrong in user space, it can bring down the system.

The newer kernel subsystem responsible for handling video cards is the Direct Rendering Manager, with the unfortunately confusing acronym DRM. [1] nVidia declined to support DRM in its proprietary driver for quite some time but eventually chose to do so.

They have some quibbles with GBM, one of the parts of the kernel API, but they didn't raise them until after the API was implemented in the kernel, was implemented in the AMD and Intel drivers, and had become a dependency for the Wayland reference compositor Weston. They refused to implement GBM and instead implemented their own alternative, EGLStreams, which is far more complicated. The open source world believes this is the wrong architecture and has had a lot of discussion about how to (reluctantly) support it. The current KDE and Gnome approach seems to be to accept patches from nVidia for EGLStreams support [2][3], but not everyone feels the same way. [4]

nVidia has implemented DRM already. They could implement GBM if…

> If you're willing to fiddle around, there are a few good themes that don't waste so much space.

The point of this "first impressions" exercise was to explore the happy path.

> It's not just Gnome that does that. There's an entire generation of designers that's cargo-culting mobile designs at the moment. Breeze, KDE's default theme, is equally space-wasting.

I would agree with that sentiment, though I didn't want to get into that flame war today. I think a lot of other people have already written extensively on this subject and I don't feel I can contribute anything new. Here are some relevant articles...

Several of these are about CSDs, which I think are a big point of contention with respect to the design philosophy of GTK/Gnome 3.X. This list does not include much about the KDE/Qt side, which I'm less familiar with.

I would certainly like to expand the side of this list on the "Pro Gnome" side in the interest of a more fair and balanced debate.

Pro Gnome 3.x:

Client-Side Decorations Initiative - https://wiki.gnome.org/Initiatives/CSD

Restyling apps at scale - https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/

Introducing the CSD Initiative - https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

Against Gnome 3.x:

Why do we keep building rotten foundations? - https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/

GNOME (et al): Rotting In Threes -…

This is also in a similar boat. I'm having a hard time pinning down anything of any serious relevance from the GNOME/GTK side of things, but there is this[1] which shows that they had planned work on Wayland prior to the Mir announcement. It looks like they started actual work on it some time in 2013 which may look like it increased because of Mir, but I would tend to think that's more coincidence based on their prior plans.

From the Qt/KDE side of things we have work on QtWayland[2] and work on Plasma/KWin[3]. The former had development increase as work on Wayland continued and follows a general upward trend, especially after Plasma started using it. For the latter, the article covers the timeline pretty clearly.

From what I can tell my point still stands, even when talking about support from integrators.

[1] https://wiki.gnome.org/Hackfests/WaylandHackfest2012

[2] https://github.com/qt/qtwayland/graphs/code-frequency the spike you see happened Jan/Feb which was prior to the Mir announcement and if you check the number of commits there was no major increase at that time

[3] http://blog.martin-graesslin.com/blog/2013/04/the-history-on-wayland-support-inside-kwin/

For completeness, here is the reply from one of the KDE developers:
https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAGeFrHA7FyqR24VkOgYO7tfsVEkfhCcvg6DX_jiJSm-y40hdhQ%40mail.gmail.com%3E

(It doesn't appear in the thread because it's been forwarded)

EDIT: and here is a blog post about EGLStreams from another KDE developer (2016):
https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/

Here is a follow-up blog post from the same author (2017):
https://blog.martin-graesslin.com/blog/2017/10/plasmawayland-and-nvidia-2017-edition/

Here are some (technical) discussions on wayland-devel about EGLStreams (2016): https://lists.freedesktop.org/archives/wayland-devel/2016-March/thread.html#27547

Here are some recent IRC logs from #wayland, also discussing EGLStreams: https://dri.freedesktop.org/~cbrill/dri-log/?channel=wayland&highlight_names=&date=2019-02-21#t-1155

That's a really weird way to look at it. In reality nvidia just chose to not invest in it. This sums it up: https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/

Gnome did land eglstream support by the way, xwayland as well. I think kde too at some point (not sure about that).

Nvidia had a lot of options on the table: - allow nouveau to reclock gpus or, better, collaborate with them so that at least there's one usable driver. - follow the community consensus and go with GBM straight away. Didn't seem to be a problem in the first place as it's what they are doing now. - open source their driver like other manufacturer and be part of mesa.

Community had one option: dedicate a lot of time and effort to create a whole code path for nvidia only and having to debug it against a black box driver

What has this to do with wayland or XFCE? The only major DE that is using client side decorations is gnome. This has been true since 2018:

> I heard that GNOME is currently trying to lobby for all applications implementing CSD. One of the arguments seems to be that CSD is a must on Wayland. That’s of course not the case. Nothing in Wayland enforces CSD. Wayland itself is as ignorant about this as X11. [...] In fact we created a protocol (supported by GTK) that allows to negotiate with the Wayland compositor whether to use CSD or SSD.

From https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/

Wayland is agnostic, and it's up to the compositor and application to decide what to do while operating under wayland.