Having used Intel open source drivers for 12 years, I've never lost the opinion I gained back with X3100 gpu that Intel is the darling because technically open sourcing the driver papered over the many, many faults of their code.

Whenever I had a chance to run on nvidia binary drivers, the only things I occasionally missed were some new features, or having to wait a bit longer to update the kernel. Stability was better, drivers more performant, and I don't remember daily fighting with memory leaks.

And X.Org's driver architecture could be replaced completely (in fact, it could be made to run on the same stack as Wayland) - it wouldn't be the first compositing Xserver around, and could use methods that would deal with noticeable to many lag involved in compositor-based UI.

> Whenever I had a chance to run on nvidia binary drivers, the only things I occasionally missed were some new features, or having to wait a bit longer to update the kernel. Stability was better, drivers more performant, and I don't remember daily fighting with memory leaks.

I had a Nvidia Riva TNT2 and later on an Nvidia GeForce. I ran Linux on it.

I had stability issues with the driver, but I solved it the following way: ran one X server with a DE, and another X server with Nvidia's proprietary driver (mostly for games). This way, if I had to kill the X server using Nvidia's driver I didn't lose any work.

If that wasn't enough, all the bloody time there were massive security problems found in Nvidia's proprietary driver. I don't know if that is still the case, cause I switched away to ATi in the 00s, and Intel graphics cards + ThinkPad as laptop. ATi/AMD has come a long way ever since. Their FOSS drivers are stable, and they deliver (see various Phoronix benchmarks).

> And X.Org's driver architecture could be replaced completely (in fact, it could be made to run on the same stack as Wayland)

Many distros do this already. Both for graphics drivers (xf86-video-modesetting) and input drivers (xorg-input-libinput)

There's more to it - X.Org is based on lowest-common-denominator code from early days of X11, and the internal driver system despite upgrades is a bit lacking.

There's glamor, but AFAIK it's not as tested as it should, and is still shoehorned into old model.

An example of not following the old model is Xsgi, which was (hw) compositing and quite ingenious in many ways.

> I keep trying to use Wayland, but it never fully works. Everyone keeps saying how well the highdpi stuff works

I use Wayland daily and have for a few years. It’s clearly gotten better, and I rarely encounter problems. I do have my load of applications still running in XWayland though.

But yes. Support for varying DPI in my multi-monitor setup is handled much better on Wayland than on X11. I would say much better than on Windows too.

How's the forced v-sync? I assume all games run XWayland, which makes it a non-issue. (Otherwise, it'd presumably be an FPS hit in a world where adaptive sync [like G-SYNC but not really FreeSync since the latter doesn't really work in Linux lol] makes tearing a thing of the past and obviates v-sync entirely.)

Also, can you use xdotool for key input redirection or screen capture programs and stuff yet?

> How's the forced v-sync?

Not sure what you're talking about. Haven't noticed any adverse negative effects.

It's super nice to have a desktop without any tearing though.

> I assume all games run XWayland, which makes it a non-issue.

I don't do PC-gaming.

> Also, can you use xdotool for key input redirection

Not sure what xdotool is.

I'm using sway[1] with libinput. I haven't had a need to use external tools beyond what they support natively.

> or screen capture programs and stuff yet?

I have no issues to do screenshots ad-hoc (in fact, I have keybindings to do this, and throw it right in the wayland clipboard).

I do notice that most Xwayland-based programs which tries to do screen-sharing fails spectacularly though.

[1] https://github.com/swaywm/sway

I use sway with no issues and a much snappier Desktop with no screen tearing.

Wayland is a protocol. It has nothing to do with multi screen support. You're talking about the compositor you used. The one I use handles multi-screen setups quite well.

I never got to fully understand Wayland's model, but if this means that something that previously was handled by the display server for everybody, and now every single desktop environment (or at least something like wlroots) has to solve it over and over again... how isn't this a step back?

Cutting out bloat, just like you loose weight by cutting of your head.

Wayland is like X11. Xorg implements the X11 protocol. There are other X11 server implementations — XWin32 is one example on Windows.

Nothing has changed with Wayland except we have a new thing and lots of groups writing compositors. And this is great — Mutter, Kwin, wlroots, Mir — and they will all speak a common protocol for putting stuff on the screen and handing input events. And projects with similar use-cases “desktops” are standardizing on common dbus interfaces for non-display stuff.

This is genuinely so much better than the Xorg monoculture. Wayland’s design has made it possible for lots of different groups to implement display servers and have interoperability because what we had before was “X11 actually means do what Xorg does.”

There’s lots of in-fighting about the scope of Wayland and people that want to make a protocol for putting pixels on the screen also handle “desktop stuff” like audio, screenshots, screen recording, keybindings, input automation, authentication. I think this is misguided because it would effectively turn Wayland into a generic message bus between “apps with windows” and the display server when we already have a generic message bus for every application — dbus.

Right now we have things like:

org.gnome.Shell.Screenshot | org.kde.kwin.Screenshot

org.gnome.Shell.Screencast | org.kde.kwin.Screencast

which after shaking out will be promoted to org.freedesktop.* after standardization. Despite the fact that notifications have been "DE specific" in the same way for years and years nobody seems to complain about org.freedesktop.Notifications.

I agree. On one hand I can understand the need to shrink code, focus on the core functionality etc..., but on the other hand X has e.g. "xset" and "xbindkeys" which can be used for all X-desktops (or "Window Managers" or however they're called). With wayland each single desktop environment has to re-implement all that functionality => looks like wasted effort to me - the modularity (from the point of view of functionality) of X is lost in Wayland.

One of the innovations since the 1980s when X was designed are shared libraries, so you can have libweston and wlroots now https://github.com/swaywm/wlroots

X11 used shared libraries since its beginning in the 1980s.

SunOS paper about shared libraries, 1987

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.9...

SunOS 4.0 lists "dynamic linking" as new feature, released 1988

https://en.wikipedia.org/wiki/SunOS

AT&T System V Release 3 got shared libraries in 1986

https://en.wikipedia.org/wiki/System_V_Release_4#SVR3

While the first X11 release was in 1987, the fundamental architecture was designed already since 1984, and this architecture includes a heavyweight server that implements things that in most other window systems are done client-side.

There’s nothing from someone implementing a single extensible compositor that everyone standardizes to build their DE. It’s the same as Xorg and X11.

Right now there’s a bunch of competing compositors with different use-cases but nothing says it has to be true forever.

> Wayland is a protocol.

A protocol definition could cover multi screen support, requiring implementors to do something sane. Of course one of the reasons that Wayland exists was to cut down the bloat X had accumulated over the years. Given that it is rather surprising that the Wayland spec isn't just an empty page.

> Wayland is a protocol. It has nothing to do with multi screen support. You're talking about the compositor you used. The one I use handles multi-screen setups quite well.

Which compositor do you use?

I use Wayfire [0], a customizable compositor based on wlroots, the same base as sway. It's quite involved and not absolutely perfect yet, but it has some features I haven't yet seen on other DEs like being able to swipe horizontally on your touchpad to smoothly switch workspaces (following your fingers) and the satisfaction of having it properly configured is pretty high.

There have been 3 issues I've had regarding it, 2 I'd call minor:

- I haven't found a way to rearrange external displays, though it is theoretically supported

- After a bug in my TV switching to the lowest possible resolution through switching the input in home assistant it would not work with 4K again until after a complete reboot (so it may not even be a wlroots issue)

- XWayland apps are unresponsive in the upper half of the second screen (4K at 1x scaling)

Using mostly native Wayland apps neither of these have been deal breakers for me. Something under-discussed is that virtual desktops are per-screen, which I find quite cool.

So that's my adventure with Wayfire, but I would assume that Gnome and KDE have perfected multi-screen usage on and off of Wayland by now.

[0]: https://wayfire.org/

>XWayland apps are unresponsive in the upper half of the second screen (4K at 1x scaling)

Seems to be a bit of a dealbreaker for people who want to use 100 percent of their screen instead of only 75 percent.

Wayfire's developer here, have you looked into output configuration on our wiki?

Also, is there a chance your 4K screen has negative coordinates? It is well known that Xwayland does not react if an output has negative coordinates (or at least partly negative coordinates).