
The death watch for the X Window System has probably started - _emacsomancer_
https://utcc.utoronto.ca/%7Ecks/space/blog/unix/XDeathwatchStarts
======
csande17
I would use Wayland, but the most actively-developed tiling window manager,
sway, doesn't work with the NVIDIA graphics card I own.

And come to think of it, isn't that a really weird problem to have? On X, the
compositor (responsible for actually drawing all the windows on the screen)
and the window manager (responsible for deciding how to arrange the windows
and what their title bars/borders should look like) can be separate
components, so I use i3 to arrange my windows and compton to draw them without
tearing.

On Wayland, my impression is that the compositor and the window manager have
to be built into the same program, so you run into silly situations where you
can run GNOME on your graphics card but you can't run a basic tiling window
manager. This also makes it a lot harder to create a new window manager, since
you also have to write a compositor and test it on every graphics card.

That last issue could be solved with a reusable library that provided basic
compositor functionality for window managers. Except every member of the
Wayland community has independently had that idea and written their own, each
with a different, incompatible interface and support for different graphics
cards. So either we need a meta-library that abstracts away all the different
libraries, or we need a standard compositor interface like X had.

~~~
emersion
NVIDIA doesn't support GBM, which is the standard for buffer allocation. Use
nouveau.

>The last issue could be solved with a reusable library that provided basic
compositor functionality for window managers.

This is pretty much what wlroots is.

~~~
chrisseaton
> NVIDIA doesn't support GBM

If Nvidia don't support it, how much of a useful standard can it really be?

~~~
robert_foss
NVidia has a horrible history of Linux support.

GBM works just fine, they've simply chosen not to support it.

~~~
calcifer
Nvidia has _excellent_ support, I think you are conflating Linux with open
source. For decades, Nvidia had (and arguably still has) excellent support for
the former, without really caring for the latter.

~~~
arghwhat
Are you referring to the small decade it took them to support KMS so that
their driver behaved even remotely like a modern one?

Or perhaps their marvelous installation methods of running a random script as
root that rewrites configuration files, and its configuration interface that
likewise also rewrites configuration files in attempts to get multi-monitor
setups working that until recently hardly ever worked?

Maybe you are referring to their magnificent support, forcing you to stay on
outdated kernels as upgrading would break compatibility and render you without
a functioning graphics adapter short of a VGA-resolution framebuffer console?

It could also be their fantastic backwards compatibility, requiring you to
keep track of driver series compatible with certain adapters, where every
other GPU in existence just works OOB.

I used NVIDIA up until a 2 years back. While you could arguably get things to
_work_ , claiming they had excellent support is laughable at best.

~~~
Crinus
I think he refers to the fact that Nvidia's drivers provided excellent OpenGL
support for multiple years compared to the absolute dumpsterfire that fglrx
was. Before Valve decided to pay attention to Linux and thus prod AMD to
improve their drivers, if you wanted anything approaching serious 3D
performance on Linux, you _had_ to use Nvidia. Anything else would be a waste
of money.

~~~
arghwhat
Fair enough: That was indeed true _many_ years ago.

~~~
Crinus
Not that many, fglrx's replacement amdgpu was released in april 2015, that is
just four years ago. And it wasn't until later that it got usable.

------
neilv
Quoting a quote from the article:

> _The reality is that X.org is basically maintained by us and thus once we
> stop paying attention to it there is unlikely to be any major new releases
> coming out and there might even be some bitrot setting in over time. We will
> keep an eye on it as we will want to ensure X.org stays supportable until
> the end of the RHEL8 lifecycle at a minimum, but let this be a friendly
> notice for everyone who rely the work we do maintaining the Linux graphics
> stack, get onto Wayland, that is where the future is._

The fair warning is appreciated. Anytime we hear something like this in open
source (sometimes after the fact), I try not to prejudge, but I definitely pay
attention. Linus Torvalds notwithstanding, the parties with the development
resources effectively make the decisions. Sometimes such decisions turn out to
still be controversial even years after being pushed onto Linux (like GTK3 or
Systemd). I haven't yet used Wayland enough to guess how it will turn out.

~~~
nextos
My concern at the moment with Wayland (and Systemd, Pulseaudio, DBus and a few
others) is that Linux is loosing modularity.

All these dependencies seem to be getting more or less mandatory. Running a
distribution without them is getting harder.

Given that they are all getting pushed by the same group of people at Red Hat,
it is concerning as they are effectively gaining control of the Linux
userland. And given that their architectural decisions are quite contentious
and at odds with many Unix design principles, this is not good.

~~~
notatoad
>they are effectively gaining control of the Linux userland.

but they aren't gaining control by some dastardly power grab, they're gaining
control because they're the only ones actually putting in the work. They're
simply doing what they think is best for their product, while at the same time
contributing their work back to the open source world. That is good, that's
how it's supposed to work.

The only reason they're gaining control is becuase the rest of the linux
userbase has decided that although they might complain about Red Hat's work on
hacker news and deride it as "not good", it's actually good enough that nobody
wants to use any alternative projects to the ones red hat works on.

~~~
traverseda
It seems like a lot of those projects just aren't interested in accepting
pull-requests from outsiders.

If they were more willing to compromise and cooperate I don't think they'd
catch nearly this much flac.

~~~
nextos
Exactly. And for much smaller organizations and individuals, it is much harder
to organize an alternative effort to this set of projects backed up by a big
corporation (Red Hat).

I only expect this to happen if Systemd and related efforts become really
bothersome. Right now it is a big of a mixed situation. A better init system,
and some modern basic userland infrastructure was needed. Systemd has brought
some good things, but overall changes are concerning for the reasons outlined
in my parent comment.

~~~
danieldk
_Exactly. And for much smaller organizations and individuals, it is much
harder to organize an alternative effort to this set of projects backed up by
a big corporation (Red Hat)._

There are exceptions. Drew Devault and the rest of the Sway team did write
wlroots, an alternative compositor for Wayland, so Wayland is less of a
monoculture.

But it is true that it requires a lot of manpower, money, and will to develop
an alternative to e.g. Wayland. However, I see the current situation more as
the glass being half full. Imagine that we did not have Red Hat, and others
pulling the weight of Wayland (and other technologies, such as Flatpak), the
Linux desktop ecosystem would in many ways be hopelessly behind macOS, iOS,
and Windows.

I think this is a better outcome than being stuck with 80ies/90ies graphics
technology forever, even if it is not perfect.

------
nsajko
One thing that a great majority of commenters here seem to be missing is that
Wayland's issues that make it unsuitable to replace X Windows will not just be
ironed out in a couple of years (at least not in a way that would be an
improvement over X), because it is flawed by design.

The thing is, Wayland developers do not want you to take screenshots or
automate input events (injection and interception). Those are both "power-
user" and "accessibility" features. So respectively those who like to use the
Unix (or other OS) programming environment to its full potential (hackers?),
and the blind/visually impaired will have a hard time if Wayland gets forced
on them.

It is possible to solve those problems with effort on a per-compositor basis
(meaning less choice for users and more redundant programming effort -
programs that interact with GUIs will need to have separate code for each
compositor!), or with protocol extensions - that, of course, would not be
universally accepted. For example, I think no compositor currently give a
Wayland user the option to mess with input events (key presses, etc.). This
means no hot-keys!

Quoting Red Hat: "Furthermore, there isn’t a standard API for getting screen
shots from Wayland. It’s dependent on what compositor (window manager/shell)
the user is running, and if they implemented a proprietary API to do so."

An interesting Reddit discussion: "It has been almost a decade, why does
Wayland not have a protocol definition for screenshots?" \- answer - "Because
security, dude! Wayland is designed with the thought that users download
random applications from the interwebz which are not trustworthy and run them.
Wayland actually makes a lot of sense if you don't think of Linux desktop
distributions and desktop systems, but of smartphones. But for some reason we
_absolutely need_ this technology on the desktop, like we had not enough pain
and lose ends over here without it." [7]

See [1] [2]. And my previous comments on the same topic: [3] [4].

Another thing wrong with Wayland is that forced compositing means noticeably
(in interactive applications) more latency.

 _Small nitpick regarding the blog post: Chromium depends on GTK3._

[1]
[https://wiki.gnome.org/Accessibility/Wayland](https://wiki.gnome.org/Accessibility/Wayland)

[2]
[https://www.freedesktop.org/wiki/Accessibility/Wayland/](https://www.freedesktop.org/wiki/Accessibility/Wayland/)

[3]
[https://news.ycombinator.com/item?id=20310200](https://news.ycombinator.com/item?id=20310200)

[4]
[https://news.ycombinator.com/item?id=20308011](https://news.ycombinator.com/item?id=20308011)

[7]
[https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...](https://www.reddit.com/r/linux/comments/7lb5l7/new_screenshot_alternative_for_wayland/)

~~~
rambojazz
You cannot take screenshots with wayland??

~~~
hannasanarion
Nope! Not unless your DE has implemented their own custom screenshot solution,
and your screenshot program has Code to interface with that DE.

~~~
PlutoIsAPlanet
Don't throw such bullshit. Of course you can take screenshots, and no a
screenshot program does not need to be adjusted for each DE.

The screenshot program only needs to interface with the
org.freedesktop.portal.Screenshot api, which works on GNOME, KDE and wlroots.

~~~
ddevault
The dbus screenshot API does not work on wlroots without a standalone bridge.

------
rleigh
Maybe the death watch for the traditional Linux desktop has also started...

Linux distributions have had a decade long slide in their usability and
polish. Much of this has been due to an abandonment of its historical UNIX
roots in favour of half-baked "modern" replacements.

Being a UNIX replacement with a full X11 server and all the rest was what made
it compelling and practical in the first place.

However, it's coming to the point where it's simply getting unusable. And I
say this after using Linux on the desktop as my primary user and development
environment for over 22 years at this point. If I want actual UNIX, I can run
FreeBSD in a virtual machine, or even on the bare metal. Otherwise, I might as
well resign myself to fate and use Windows with WSL or VMs for everything
else. If I'm going to be forced to use something I dislike, it might as well
be something that properly supports all my hardware and I can be productive
with despite its annoyances.

~~~
zbuf
I come from an environment where we have a reasonable number of Linux
workstations; approaching 2000 in the company I work for, and more in the
wider field.

> Being a UNIX replacement with a full X11 server and all the rest was what
> made it compelling and practical in the first place.

Yes, here as well. We have big apps, small apps, legacy apps, remote apps, all
doing real work.

For the enthusiast user base, who mainly live within the distribution's
ecosystem, this sort of churn in the platform is exciting and interesting, or
feels like progress. The platform is the end result.

For us, the platform is just that -- a platform on which sits a lot of vendor
applications and custom tooling assembled over decades with its idiosyncrasies
carefully accommodated.

This churn isn't good. Anything short of 100% compatibility is going to prompt
a risky re-evaluation of what's out there on the market -- risky because
Windows is in the strongest position, not Linux.

Linux is already in a weakened position than it once was as a workstation OS.
My colleagues will be enticed by a Windows platform which has an emerging
Linux compatibility; and a tried-and-tested build of most of the vendor-driven
GUI applications and GPU drivers, too.

------
rspeele
I can't say it any better than JWZ did over 15 years ago. This is the result
of the Cascade of Attention-Deficit Teenagers model and is why Linux will not
approach Windows or OSX in usability.

Cannot link to his site:

JWZ dot org /doc/cadt.html

A complete teardown and rebuild of the whole ecosystem (because X succccckkks)
is fun! Making something backwards-compatible, or standardized, or polished
that "last 90%" so it works on everybody's environment... is not.

~~~
xorcist
The CADT development model is very real, but it's not really a good
description of the Xorg situation. The most active Wayland developers are not
only also Xorg developers but have been so for a very long time. They know
their history.

X11 has some fundamental problems. It's not fun using a modern desktop where
it is impossible to sandbox individual applications. Firefox frequently
processes untrusted data and is run with a dedicated uid, but it is also an
interactive application and can suddenly listen in on all my passwords entered
in other applications. Virtualized appliations are referred to using dumber
protocols like VNC and SPICE which isn't always ideal.

Wayland has some interesting design issues on its own but that doesn't make
the developers ignorant. XWayland will stick around for the foreseeable
future.

~~~
altfredd
> The most active Wayland developers are not only also Xorg developers but
> have been so for a very long time

Amusingly, I often hear this argument from Wayland proponents. Do they
realize, that those very same developers have failed at maintaining Xorg code
base and fixing it's bugs in backward compatible way?

To run a project into the ground and wash one's hands of it... is not worthy
of endorsement.

~~~
xorcist
It's important to know that there were once many implementations of X11. Xorg
is the only one that _hasn 't_ failed. Everything else is unmaintained now.

This may be a matter of different perspective, but from my point of view the
Xorg maintainers did a monumental work modularizing and cleaning up the
codebase. They kept integrating modern extensions and have kept X11 relevant
all this time. Try something pre-Xorg to compare.

------
carapace
RIP

( I don't doubt for a minute that _someone_ will pick up the slack, but that
makes me wonder, who's gonna pay for it? Would you contribute to e.g. a
Kickstarter for X Windows? FWIW, I'm not sure I would, meaning no disrespect
I've been hoping to ditch X for something better ever since Don Hopkins opened
my eyes to NeWS, &c. )

So there's Wayland. What else? Arcan?

[https://arcan-fe.com/about/](https://arcan-fe.com/about/)

On HN:
[https://hn.algolia.com/?query=%22arcan%22&sort=byPopularity&...](https://hn.algolia.com/?query=%22arcan%22&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

> Arcan is a powerful development framework for creating virtually anything
> between user interfaces for specialised embedded applications all the way to
> full-blown standalone desktop environments. Boot splash screen? no problem.
> Custom Interface for your Home Automation Project? sure thing. Stream media
> processing? Of course.

> It has been used in a number of both experimental, hobby, academic research
> and commerical projects and products alike, in areas ranging from VR
> desktops to industrial computer vision systems for robotic automation.

> At its heart lies a robust and portable multimedia engine, with a well-
> tested and well-documented interface, programmable using Lua. At every step
> of the way, the underlying development emphasises security, performance and
> debugability guided by a principle of least surprise in terms of API design.

~~~
DonHopkins
Thank you, I hadn't heard of it before so I'll check it out!

I'm not optimistic about Wayland, since early on they decided not to use an
extension language, and that's not something you can have a change of heart
about later, and then just nail onto the side.

It would be interesting to see how Arcan uses L ua, which is a great language
for that kind of stuff. It's a lot smaller and sleeker and better designed
than JavaScript.

The Arcan developers should check out how Factorio modding works! (But then
all work on Arcan would halt when for months while they were addicted to
Factorio.)

[https://wiki.factorio.com/Modding](https://wiki.factorio.com/Modding)

Lua's main problem is that it isn't JavaScript (i.e. in JavaScript's enviably
lucky position of ubiquitous dominance).

If I had a time machine, I'd go back and try to convince Netscape to use Lua
2.1 instead of inventing JavaScript (released December 4, 1995). And hire the
Self guys (Dave Ungar, Randy Smith and the crew who eventually made the Java
HotSpot compiler) away from Sun, and Mike Pall (LuaJIT) from wherever he was!

[https://www.lua.org/versions.html](https://www.lua.org/versions.html)

>Lua 2.1 was released on 07 Feb 1995. Its main new features were extensible
semantics via fallbacks and support for object-oriented programming. This
version was described in a journal paper. Starting with Lua 2.1, Lua became
freely available for all purposes, including commercial uses.

[https://news.ycombinator.com/item?id=12574290](https://news.ycombinator.com/item?id=12574290)

[https://channel9.msdn.com/Blogs/Charles/A-Conversation-
with-...](https://channel9.msdn.com/Blogs/Charles/A-Conversation-with-Bjarne-
Stroustrup-Carl-Hewitt-and-Dave-Ungar)

~~~
crazyloglad
I get paid to work on Arcan so I don't think factorio would have that big of
an impact ;-)

The initial choice of Lua for Arcan was based on its use, at the time
(2004-2005ish), in World of Warcraft. The UIs that people were hacking
together in WoW even with little to no serious programming experience was way
more advanced than what would ever be needed for desktop interfaces so it
seemed like a good fit. Even for other projects, Lua is still my goto "safe"
keyword for C.

There are more interesting properties though, especially how the VM- bindings
integrate with C. Stay away from using too much metatable magic etc. and what
you get is an ok "protocol+binding" in one. Substitute the stack for socket
read/write, add an identifier to function translation and you can chose
between in-process or stronger separation. The reality is slightly more
involved, but not by much.

~~~
DonHopkins
Don't be so sure you won't miss work if you haven't yet tried Factorio! ;)

[https://news.ycombinator.com/item?id=20362179](https://news.ycombinator.com/item?id=20362179)

WoW was what convinced me how practical and powerful Lua really was, too. And
that there were people out there that knew how to program it really well.

The WoW "Auctioneer" mod in particular was quite advanced and elegantly
written. It would analyze the prices of items in the auction house over time,
and help you price and sell your own items competitively. Not just lots of
fancy user interface, but some respectable data wrangling and number crunching
too.

One important thing about Lua is how cleanly and efficiently it integrates
with C code. TCL/Tk also has this virtue, but TCL was a terribly designed (but
brilliantly implemented) programming language. While both Lua's design and
implementation are quite excellent. It also has a great community, plus RMS
never declared a holy war on it, either!

[https://news.ycombinator.com/item?id=14944103](https://news.ycombinator.com/item?id=14944103)

[https://vanderburg.org/old_pages/Tcl/war/0000.html](https://vanderburg.org/old_pages/Tcl/war/0000.html)

~~~
eadmund
> TCL was a terribly designed (but brilliantly implemented) programming
> language.

What do you dislike about Tcl? I always kinda liked it.

> While both Lua's design and implementation are quite excellent.

The implementation is pretty good, but 1-based arrays are pretty evil. I don't
know if I like the way arrays & tables are conflated either: part of me thinks
it's clever, and part thinks that it's too clever by half.

It's also pretty verbose.

Something I like about both Tcl & Lisp is that they have a good built-in
messaging format (Tcl object notation in the former, and S-expressions in the
latter). Lua doesn't really have something similar, which is IMHO unfortunate.

------
logicprog
I'm really not very sad to see X go. It was old, creaky and insecure. As
advanced and cool as it may have been at one time, and as much as I respect
the people who worked on it, it's time for it to go.

As for the people complaining about Wayland possibly missing some of X's
features, remember that it takes time for something to mature, to accrete
features and fixes, and Wayland hasn't had that time yet. If we give it the
time and support it could and almost definitely will grow into something even
better than X. We can't stay on X forever without incurring even worse results
on ourselves than what we'll get when we switch to Wayland.

And another thing. For the people who complain about Wayland in the same
breath as PulseAudio and SystemD: this tells is much more about you than about
these projects. The only thing Wayland has in common with the other two is
that it's new, and that you don't like it. It's more modular and more UNIXy
and more open than X, arguably.

~~~
AnIdiotOnTheNet
> As for the people complaining about Wayland possibly missing some of X's
> features, remember that it takes time for something to mature, to accrete
> features and fixes, and Wayland hasn't had that time yet.

It has been a decade, precisely how long does it need to catch up? I ask
because from what I can tell it is still missing features that were standard
in Windows Vista in 2008, when that OS switched to DWM and WDDM.

~~~
logicprog
If you're talking about screen recording and screenshots, fair point, except
that that lack is a result of designing for security.

~~~
temac
Hum, you can as well reach perfect security by keeping your computer powered
off.

~~~
logicprog
Haha! Yeah, that's true.

------
beowulfey
Is there any plan by Wayland to incorporate ssh forwarding? Last I heard it
wasn't in the cards, and I think that feature is useful enough; it's probably
the only feature I really would miss.

~~~
izacus
I see this a lot and now I need to ask: do you actually use it and find it
usable?

Every time I've tried it, it was plagued with problems (fonts, HiDPI issues,
different environments) and horrible performance. I mostly had to resort back
to NX, which is okish, but not better at all than Windows' RDP or better VNC
solutions. So what's the big draw here?

~~~
jkaplowitz
It was pretty great when I was a university student using X forwarding within
the campus network between my dorm and the CS department (in either
direction). Certainly not as fast as local, but extremely usable when not
trying to do graphics-centric things. (Even using Eclipse was viable.)

Your mileage may vary by use case and bandwidth, especially over the public
internet. But if someone has a similar use case to mine in 2019, it's still
probably usable.

~~~
majewsky
Even if it's usable, it's probably not a good idea. X windows are not rendered
by the server anymore. The client (i.e. the application) renders them and just
transmits a full pixmap to the server. Depending on the redraw strategy, you
could have a worst-case scenario where 60 frames per second of the entire
window are transmitted completely uncompressed (except for the compression
that SSH applies). You'll be sailing much more efficiently by using a VNC
client.

~~~
gmueckl
To be pedantic, this is true with "modern" toolkits (like, this cemtury).
Applications using Motif or Xt or anything similarly ancient still do server
side drawing and they absolutely shine with todays network latency and speed.
But most applications moved on from.these toolkits, with good reason.

------
mindcrime
I'm totally not impressed with the so-called "successor" to X... Wayland.

It _might_ be unrelated, but I just upgraded to F30 and I'm seeing all sorts
of weird graphics / screen drawing related bugs using Wayland. And while it
looks like somebody is finally making some meaningful headway on a remoting
story for Wayland, it's _still_ not truly on par with X in this regard.

So sure, kill X... but we should probably have a replacement that actually
works, first.

------
ken
While I appreciate having choices _at some levels_ , for infrastructure it's
always good to have everyone agreed. Desktop Linux has been held back by the
X11/replacement situation for years (there, I'll say it), and the sooner we
can all get (back) on the same page, at least for this one piece, the better.

Many open-source communities are run by perfectionists (and I must count
myself among the worst of them). While it's a noble goal to create a gem that
will stand the test of time, it's disheartening to see proprietary products
move faster by making a decision, even a lousy one, and then shipping it and
making it work.

------
bitwize
Omae wa mou shindeiru.

If the future of X is uncertain, then X is already dead. No one wants to base
their OS on something without a clear maintenance and development roadmap.

~~~
johnklos
Except for those who pave the way. Not all OSes are products.

~~~
ch_123
I'm not sure that use of X11 could be considered "paving the way"

~~~
nvrspyx
I think they might have meant “pave _their_ way”. Like they said, not all OS’s
are products and some people have specific use cases in which X11 is the only
viable option, whether that’s personal or experimental.

I wouldn’t know what those use cases might be. That’s just my interpretation
of the comment.

------
DonHopkins
Back to the drawing board!

Methodology of Window Management

F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams

29 April 1985

This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon
that took place from 29 April 1985 until 1 May 1985. It was input into the
planning for the MMI part of the Alvey Programme.

The Proceedings were later published by Springer-Verlag in 1986.

[http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/preface.htm)

------
lkirk
I'm also a heavy user of an X-only window manager (xmonad). Learning about
this makes me wonder if I should start learning how to work with another
window manager so I'm not caught off guard when something stops working.

~~~
mimimi31
Do you know about Waymonad? It's supposedly Xmonad for Wayland and uses
wlroots like sway.

~~~
lkirk
I've heard of it, not sure how mature it is these days. Maybe I'll give it
another look

------
hyperion2010
My take home from this thread now with a few weeks to reflect is that if we
want a real window manager that is maintained, then it will have to be a
community effort. This will be hard because training an involvement with x11
has been left entirely to Red Hat too long. It will be a lot of work and money
to transfer knowledge from the few who do know it.

With this in mind, are there other projects that are at risk due to
stewardship by a single corporation? How can we prevent this in the future?

~~~
iso-8859-1
> How can we prevent this in the future?

Software is dependent on hardware. If the hardware changes, as it did since
X11 was invented, the software stack has to change too. You cannot prevent
progress in technology.

Xorg is in a better state now that it has ever been. Therefore it makes no
sense to consider Red Hat some villain that adopted Xorg and ruined it. And
had Red Hat not been there, Wayland would still have been invented.

Xorg developers switched to Wayland. Why? Because they know it is the future.
There is no need to train Xorg developers.

~~~
hyperion2010
To be clear, I am not in any way faulting RH for this, the excellent state of
X11 is indeed due almost entirely to their technical and financial support.
This should be celebrated.

My point is that having such support can lead the community to assume that
such support will always be there an neglect the need to maintain a robust
multi-party collaboration around such vital projects.

------
ht85
Slightly off-topic, but is anyone here using Wayland with a touchpad?

The last time I tried libinput, the behavior was horrendous compared to a
synaptics.

2 finger scrolling had a ~2mm threshold before it activated and wouldn't
compensate for the lost distance once the scroll started, making it feel very
unnatural.

I couldn't find an option to enable true palm detection either. There was an
option to disable the touchpad for a fixed time every time the keyboard was
used, which is abysmal compared to how it works normally (ignoring taps and
drags if they start too close to an edge).

It's hard to believe that this is the current state of things, but I did
search for a way to set it up with no success. Is there a way to get those to
work?

~~~
ZeroCool2u
I've been using Ubuntu with Gnome on Wayland for the past year or so on my
Dell XPS 13.

I actually ended up switching to Wayland, because of how much better the
touchpad worked with it. To be fair though, Dell has an entire team dedicated
to supporting the XPS 13 Developer Edition, so the drivers are highly curated
compared to most devices.

~~~
ht85
My experience was on an XPS 9570, not sure if there's a large gap in driver /
support.

Out of the box synaptics was pretty bad, but after tuning the palm detection
zone size and a couple timings (long press, etc) it feels amazing. When I
don't have to test convoluted UIs, I can go days without plugging the mouse.

Don't you have the small "lag" when two fingers scrolling?

~~~
ZeroCool2u
I've been super happy with the touch pads performance out of the box, I
literally haven't modified any settings related to it.

Are you referring to this bug[1] in Chromium? I think these are growing pains
associated with transitioning to Wayland, but this really doesn't bother me
too much. I will say that the scrolling is otherwise very smooth and almost
perfectly everywhere else in the UX.

[1][https://bugs.chromium.org/p/chromium/issues/detail?id=712737](https://bugs.chromium.org/p/chromium/issues/detail?id=712737)

------
konqi
I hope they manage to standardize the majority of protocols. Last time I've
checked GNOME wasn't happy but the other projects were, surprisingly,
cooperating heavily.

There are very interesting projects using Wayland.
[https://github.com/search?o=desc&q=wayland&s=updated&type=Re...](https://github.com/search?o=desc&q=wayland&s=updated&type=Repositories)

------
pmoriarty
_" Why I'm not going to switch to Wayland yet"_[1] argues that:

"for simple things using the compositor's screen shot tool is fine. But what
if I don't like the screenshot tool for my compositor of choice? My experience
with the GNOME screenshot tool (granted this was pre-wayland) was that it
wasn't as good as, say, shutter, which has a lot of options, let's you easily
crop and edit the screenshot from inside the screenshot tool etc. And then
swaygrab doesn't even (currently) have an option to capture a rectangular
region."

There are some other things this article mentions which are important to me,
like Wayland's lack of color picker tools and xdotool functionality.

Wayland seems just way too immature for me to use for now. X works great, does
everything I want, and I see no compelling reason to switch.

[1] -
[https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...](https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/)

~~~
majewsky
The wlroots developers are working on protocol extensions to make stuff like
screen grabbing work consistently across WMs: [https://github.com/swaywm/wlr-
protocols](https://github.com/swaywm/wlr-protocols)

------
djsumdog
So what are the BSDs planning on doing? Do OpenBSD/FreeBSD just plan on
maintaining their own forks of Xorg, or are there plans to try and port
Wayland to these operating systems as well?

~~~
beezle
FreeBSD user too, I'd like to know that as well. Not going to lay blame on
RedHat for doing what is in their own best interest, but do find it troubling
that the *nix world has had a major piece of software made redundant on the
decision of one company/maintainer.

As an end user my perspective, perhaps incorrect, is that since the late 90s
development of application and system software has become increasingly siloed
with less diverse views and the involvement of fewer stake holders.

I suppose that would happen based on math alone (more linux end users with no
interest beyond a working web browser) but I worry where that path might lead.

------
lettergram
A tad concerned about this because my system still heavily relies on X and
there really isn’t an alternative for my applications (yet). Wayland isn’t
supported for many applications.

~~~
snazz
Does XWayland not solve your issues? It’s a pretty good (seamless)
compatibility layer. Of course, it still involves running an X server, but
applications can switch to Wayland one at a time and you can use both
simultaneously.

~~~
PlutoIsAPlanet
Imho XWayland is "too good". There's little incentive for software like Chrome
to port over to Wayland if it runs on it seamlessly via a compatibility layer.

~~~
the-rc
Nitpick: Chrome, or at least ChromeOS, already uses Wayland, in order to run
Android and Linux apps.

------
voldacar
Are there any major x11 features that wayland lacks other than remote
operation over a network? I think at one point it locked the refresh rate to
60hz, has that been changed?

~~~
nwallin
HiDPI. It's somewhat unusual for a top end laptop to have 1920x1080 screens
these days, and Wayland doesn't support 4k very well. You can upscale, but it
looks like garbage, or it has a 2x mode, which draws image and such slightly
too large, or you can deal with everything being tiny.

For gaming, the latency is bad and always on vsync is horrible. They've fixed
the 60Hz lock though, fortunately. This only applies to gaming though.

My primary issue with Wayland isn't quite so much that it lacks these things,
it's that they seem to be of the opinion that there's only one way to do
things, and any other use of the visual display system is wrong. I just have
this weirdly oppressive feeling about my inability to configure it the way I
want it, the same feeling I get from using Windows. Just... let me be me. I
get that this is a non-technical complaint, and that it ultimately boils down
to "it gives me the heebie jeebies" which isn't an argument, but it's still
how I feel about it.

~~~
emersion
A lot of what you're saying seems due to a particular Wayland compositor, not
to Wayland.

~~~
sprash
That is the problem right? Whenever there is a functionality that you could
get with X11 by tweaking configurations files you have to write you own
complete new Display Server in Wayland to have that functionality.

This is especially true for people that prefer low latency over tear-free
rendering.

~~~
majewsky
I don't get this thread. On one hand, people complain (wrongly) about Wayland
being too monolithic. Now, people complain about there being competing Wayland
implementations with different feature sets. What's it gonna be, guys?

~~~
nshepperd
Those complaints aren't actually opposed but perfectly complement each other.

Wayland requires* everything to be monolithically built into the display
server (which is also the window manager), which means if I want to use a new
WM (say, XMonad) I need to reimplement all of this stuff. Want screenshots?
Build it into your WM! Want redshift? Build it into your WM! The result is
that development effort will be wasted reimplementing "competing Wayland
implementations" stuff that no-one actually wants.

Compare X11, where I could run an Xorg server together with any of a number of
lightweight window managers, and the window manager is _only_ responsible for,
y'know, managing windows, and determining how the window decorations look.
Xorg handles everything else, allowing a robust marketplace of competing WMs
to arise.

* Unless/until they finally give in and standardise protocol extensions for out of process window managers.

------
kabwj
Can Wayland currently handle several monitors with different DPI? And by
“handle” I mean, being able to resize (blurry, I know) windows that are not
DPI-aware transparently when I move them between monitors. What Windows has
been able to do for years now.

~~~
snazz
It’s not Wayland’s job, as I understand. GTK3 does it, I think Qt does it, and
I’m not sure about anything else. Firefox has issues with menu positioning but
works fine. Because X11 applications still talk using the X protocol to
XWayland, which doesn’t handle DPI scaling, there’s no guarantee of it
working.

~~~
kabwj
Applications (and their toolkits) should be able to signal to Wayland whether
they can handle DPI scaling or not, and if they can’t, Wayland should forcibly
resize the windows (ie paint them bigger) like Windows does.

If something as basic as this doesn’t work...

~~~
iso-8859-1
Do you realize that Wayland is a protocol and it involves a compositor (which
is NOT called Wayland)?

------
shmerl
I'm all for switching to Wayland session, but it has a long way to go to
become usable.

The biggest issues for me:

* KWin still has major bugs like flickering windows due to broken subsurfaces clipping.

* No Wayland compositors support adaptive sync yet and according to KWin developers it will take "several years to arrive".

* No support for drawing tablets (Wacom).

So all this "X11 is dead" is way premature, as much as I want Wayland to take
its place.

------
kazinator
How many of these Xorg developers are the original people who made X11R3 in
the mid 1980's?

Somehow X didn't die without those people.

~~~
ibotty
Keith Packard is the only one AFAIK.

------
_emacsomancer_
One of the comments on the article (
[https://utcc.utoronto.ca/~cks/space/blog/unix/XDeathwatchSta...](https://utcc.utoronto.ca/~cks/space/blog/unix/XDeathwatchStarts?showcomments#comments)
) is also possibly of interest, suggesting possible technical routes for using
existing windows managers on Wayland:

> There is XWayland, and apparently it will support handling the root window,
> not just application windows:
    
    
        https://wayland.freedesktop.org/xserver.html
    

> The missing piece of the puzzle is Xweston, which apparently allows you to
> run window managers for X on Wayland:
    
    
        https://github.com/ackalker/Xweston
    

> or maybe xwlnest will work better:
    
    
        https://github.com/gschwind/xwlnest

~~~
bitwize
Again -- XWayland _is_ Xorg. The xorg-server codebase contains a number of
components, one of which is a front end called DIX (Device Independent X) that
handles protocol-level stuff, another of which are several backends
collectively called DDX (Device Dependent X) that handle drawing to the actual
video hardware or other graphics layer. One of these DDX backends is
'xwayland'. So the XWayland server incorporates the entire Xorg server code
base except for the hardware-specific back ends. And so if Xorg languishes
unmaintained... well, sucks to be an XWayland user.

So your best bet is to commit now to switching, entirely, to Wayland. The aim
is to get everyone off of X altogether as quickly as possible, and then stop
shipping X (including XWayland) altogether.

~~~
phkahler
>> So the XWayland server incorporates the entire Xorg server code base except
for the hardware-specific back ends.

Well doesn't that mean XWayland will be easy to maintain since it has no
hardware dependencies? X can completely stagnate so long as the Wayland back-
end is kept up to date with any changes there - and no, people don't want to
be changing Wayland protocols because every compositor would have to be
updated. I think XWayland will be around for a while yet, but I'd rather have
things run native Wayland.

~~~
bitwize
Ostensibly, yes, but that would clash with the official narrative ("X is
broken and bloated and needs to be deprecated"). If they can maintain Xwayland
indefinitely, they can maintain a stub DDX that works with kms indefinitely
also. What they are telling us is that they want to get rid of the entire
thing. Pointing out that Xwayland would be relatively easy to maintain would
be stating the emperor has no clothes.

------
smartmic
Having the Lindy effect [1] in mind, I would not be too pessimistic about an
early decay of this proven (albeit imperfect) technology.

[1]
[https://en.wikipedia.org/wiki/Lindy_effect](https://en.wikipedia.org/wiki/Lindy_effect)

------
noobermin
I seek to be enlightened, not to flame: what exactly is so wrong with X that
it can be retrofit to work better? Wayland is taking a while, which is
expected sure, but for now, X works fine although with issues.

~~~
robert_foss
The design assumptions that went into making X were made before the modern
computer or Linux existed.

Modern X is a Frankensteinian collection fixes upon fixes and unmaintained
code.

~~~
quotemstr
You didn't actually answer the OP's question. There is nothing Wayland does
that could not have been done via the X11 extension mechanism. X has already
been reinvented several times --- few things use the core protocol nowadays,
after all! For example, XRender for text is now universal.

The thing that's different about Wayland is that for reasons that nobody ever
explains clearly at a technical level, _this_ time, a few influential people
created a new and (IMHO, inferior) protocol instead of continuing to use the X
extension mechanism.

Security? Isolate the X session data to individual client connections. Buffer
management? Do it like GLX does. Want server-side decorations for some reason?
What's stopping you? Sure, ICCCM isn't trivial, but it exists, and it's
flexible.

~~~
maxharris
Apple evaluated X11 when they were just starting work on Mac OS X.

This comment by Mike Paquette (designer and author of Quartz!) explains why it
was better to dump X11 and start over:

"> they don't even use X at all!

What Apple is providing is an Apple-original window system that is graphics
model agnostic, as well as a vector drawing system that maps very well to PDF,
which is a sort of PostScript without the non-graphical operators. This is
packaged under the name 'Quartz' for easy reference by Marketing types.

The window system is designed to support both buffered (like an offscreen
PixMap) and unbuffered windows, and is graphics model agnostic, working
equally well with QuickDraw, OpenGL, the Quartz drawing engine, X11, and third
party solutions, and managing window geometry for the Classic, Carbon, and
Cocoa environments. The server portion is a hybridization of screen arbiter
and compositor models (and if that's all Geek to you, don't worry about it).

The Quartz drawing engine supports drawing primitives similar to the graphics
primitives that might be found in the DPSClient single-operator primitives
library for X and NeXTSTEP. There are no math and flow control primitives, as
these can be done more efficiently in the native compiled code. There are no
DPS or PS wrappers, as this optimization for server-side graphics is not
needed in the Quartz client-side graphics model.

The operations provide imaging and path construction and filling operations as
well as some interesting other bits that map well into the direction that 2D
drawing is headed. (See Longhorn, or the X raster projects.) The drawing
engine can output to rasters (like a window!), as well as PS and PDF streams
to feed printers. The Mac OS X printing system takes advantage of the
capabilities of Quartz to support all sorts of printers, and make the life of
printer driver developers much, much easier.

Things we'd need to add/extend in X Window software
(protocol+server+manager+fonts+...):

1) Extend font server and services to vend outlines and antialiased masks,
support more font types, handle font subsetting. 2) Extend drawing primitives
to include PS-like path operations. 3) Add dithering and phase controls. 4)
Add ColorSync support for drawing and imaging operations, display calibration
5) Add broad alpha channel support and Porter-Duff compositing, both for
drawing in a window and for interactions between windows. 6) Add support for
general affine transforms of windows 7) Add support for mesh-warps of windows
8) Make sure that OpenGL and special video playback hardware support is
integrated, and behaves well with all above changes. 9) We find that we
typically stream 200 Mb/sec of commands and textures for interactive OpenGL
use, so transport efficiency could be an issue.

So, yes, it looks like we can use X for Quartz. All we need do is define
extensions for and upgrade the font server, add dithering with phase controls
to the X marking engine, add a transparency model to X imaging with Porter-
Duff compositing support, make sure GLX gets in, upgrade the window buffering
to include transparency, mesh warps, and really good resampling, and maybe
augment the transport layer a bit.

Ummm... There doesn't appear to be much code left from the original X server
in the drawing path or windowing machinery, and it doesn't appear that apps
relying on these extensions can work with any other X server. Just what did we
gain from this?

Oh, yeah. My mom can run an xterm session on her desktop now without
downloading the Apple X11 package, a shareware X server or buying a software
package.

Been there, evaluated that."

[https://developers.slashdot.org/comments.pl?sid=75257&cid=67...](https://developers.slashdot.org/comments.pl?sid=75257&cid=6734612)

~~~
quotemstr
That comment _is my point_. Those things that the Apple guy mentions having to
add to X _were in fact_ added to X. They're called XRender. There's no reason
we couldn't have added more extensions.

Nobody has given me a straight answer for why Wayland-style buffer management
couldn't have been an X11 extension. Nobody.

~~~
maxharris
I think the more pressing question is, what's wrong with supporting all these
legacy X11 apps with XWayland?

Who cares about xeyes, xterm and twm? I sure don't, at least not when it comes
at the expense of maintainers that have better things to do.

------
dpacmittal
I'll miss x11vnc which is currently the only way on linux (afaik) to have a
network connected monitor and between which I can seamlessly move my windows.

------
zzo38computer
I don't really like Wayland, and I think X is better. There are some problems
with X, and I made some ideas how to fix it, including getting rid of a lot of
the extensions of the X protocol, but making now XBell is like XkbBell
instead, moving many things out of the protocol, and also some other stuff.

------
ilovecaching
Sway has become one of my favorite pieces of software. The only issue is that
Sway or Wayland seems to have trouble implementing an easy to use
redshift/nightlight. Based on my research into eye strain and talking to my
optometrist I keep redshift on 24/7 and I can’t go back.

~~~
maroonshifter
If you call redshift before calling sway, it works for me. I have it always on
and just give it a value.

redshift -m drm -PO 3000

sway

~~~
pmlnr
Wayland was meant to fix stuff, and there are already hacks to make it work
with certain scenarios people had been relying on for years.

It'll end up becoming just as convoluted as X and I don't understand why the
devs don't see this.

------
rocky1138
Can we record the screen or take screenshots yet? If not, Wayland is DOA.

~~~
ClashTheBunny
[https://github.com/emersion/grim](https://github.com/emersion/grim)

~~~
nsajko
I think that depends on a protocol that only Sway (the compositor) implements.

------
major505
I would die a happy man, if I never had to open an xorg.config again.

~~~
asveikau
Recent releases encourage you to remove xorg.conf altogether and let it figure
out the config itself. Works pretty well from what I have seen.

~~~
kasabali
I must add ”recent” here means more than 10 years. Last release that required
an xorg.conf file was released in 2006 or 2007?

~~~
major505
Id din't know that Sometime ago I was trying to make an old nvidia video card
work with my pc in With Fedora. One of the instructions was to open the xorg.
change the drive to replace the noveau drive, or something like that. I think
it wasant't even 2 years ago.

Then I just installed ubuntu and isntalled with apt-get install nvidia-
wathever-version. And worked like a charm for me.

~~~
kasabali
When you need to configuration, best practice is to put only the necessary
configuration in a configuration snippet inside /etc/X11/xorg.conf.d/ without
creating a full xorg.conf file.

------
jl6
I intend my next PC build to last ten years, like my last one has. I will be
including an AMD GPU, because I don’t want to be left high and dry by NVIDIA
when Wayland takes off.

------
mpenick
It’s still not possible to remap mouse buttons for most applications under
Wayland and libinput is allergic to adding features.

------
souterrain
RHEL 8.8 will be released in 2023Q4, so I suspect RedHat will continue to
maintain the code at least until then.

------
blodovnik
There's a lot that xwundows can do that it'll take many years for anything
else to catch up to.

------
raverbashing
So long and thanks for all the fish. I even think X's death came late in the
game

Not that it's bad per se, but it was created at a different time, for a very
different use case than modern desktop computers

While there's a love for the "true Unix way", I think X is one where this is
embodied the least

------
hiccuphippo
So is there a timeline for when the RHEL8 lifecycle will end?

~~~
slrz
The normal support period for a RHEL release is 10 years. RHEL8 came out
earlier this year.

------
moocowtruck
that sucks for me I guess, or for me using linux as desktop since I have
nvidia ah well

------
sly010
You mean the nights watch

------
atemerev
So, RedHat decided that they do not want nvidia users anymore? I’d be more
than happy to switch to Wayland, but I can’t.

~~~
daenney
GNOME, which is what powers the RedHat desktop, supports nvidia on Wayland
just fine, and KDE got nvidia/EGLStreams support since KWin 5.16. So at least
2 major DEs do, though quite a few others don't, and have taken a principled
stand not to (Sway for example won't).

When it comes to RedHat though, they're all-in on GNOME anyway so keeping X
around for nvidia users isn't really a concern for them when their desktop
experience supports nvidia on Wayland just fine.

~~~
atemerev
No, just checked it with the latest Fedora 30, it defaults to X when it
detects an Nvidia card.

~~~
daenney
Just b/c it defaults to X does not mean it doesn't work or isn't supported on
Wayland.

~~~
atemerev
It defaults to X, because it works very poorly with Wayland. Until very
recently, it was impossible to run Gnome with Wayland at all (even though it
theoretically supported Eglstreams), as there were many kernel errors
generated by gnome-shell, etc. Now it sort of works, however, lags and freezes
make it completely unusable in most cases. I am testing it every Fedora
release. It _is_ possible to use Gnome with Wayland, I managed to get it
working with Arch Linux once. However, it took me 4 days, manual patches
(literally editing the WM code myself to fix some issues as suggested by the
community) to get the configuration right, and the next rolling Arch update
broke it beyond repair.

Again, I am not against Wayland. Wayland API is beautiful and I want it
adapted more and sooner. It is just sad that me and many other users are not
getting it. Developers blame Nvidia, because they do not open source their
driver (which is a valid concern), however, there are many other binary blob
drivers in mainstream Linux kernel, and everybody except hardcore open source
apologists are OK with that. Why Nvidia is different, I don't understand.

~~~
daenney
Developers don't blame nvidia b/c they don't want to open source their driver.
They blame nvidia for insisting on others shouldering the tech debt of
EGLStreams (a closed, proprietary nvidia-only solution with no documentation
whose implementation can't easily be tested and verified by compositor
authors) instead of enabling the use of GBM with their drivers like every
other Linux graphics driver. nvidia doesn't have to open up their drivers for
that, AMD's closed source driver (so not the Mesa stack), supports GBM just
fine.

------
imode
This is troublesome, and it feels like "progress" for the sake of "progress"
rather than actual improvements. The X Window System is time-tested
technology, while Wayland, from what I've seen and read, is not.

This isn't a good thing to me, especially considering NVIDIA hardware doesn't
seem to be well supported. Someone come along and correct me, please.

~~~
emersion
X11 is a pile of hacks. Have you ever tried to read the source code? When the
X11 devs design a new system and stop maintaining X11, it's likely that X11 is
not in a good shape.

>This isn't a good thing to me, especially considering NVIDIA hardware doesn't
seem to be well supported. Someone come along and correct me, please.

It's the other way around: NVIDIA doesn't support GBM, the standard for buffer
allocation.

~~~
sprash
How about cleaning up the mess.

The most "mess" is coming from old graphics hardware drivers, a task that is
now managed by the kernel.

Besides, the "mess" performs better than Wayland in many use cases thanks to
DRI3.

