Live data from Hacker News

The death watch for the X Window System has probably started

utcc.utoronto.ca

331–340 of 518 posts

Re: The death watch for the X Window System has probably started

#331

Earlier quoted context omitted.

A downstream compositor which wishes to implement Nvidia support could do so and integrate it with wlroots. However, there are more reasons than political not to "support" Nvidia. Their alternative has genuine technical problems that would render large parts of wlroots broken.

> Their alternative has genuine technical problems that would render large parts of wlroots broken. If this is indeed true (and I have no reason to doubt you) then I wish you and the rest of the Sway folks would focus on those issues, instead of the political arguments because from the outside it all looks very petty when you write stuff like "Nvidia doesn't support Sway". Nvidia doesn't even know about you.

This would be a great idea if NVIDIA was open to suggestions so that things could be fixed.

However, they mostly refuse to play ball. They did seem to be preparing an alternative suggestion, but they seem to have dropped it entirely in favor of just dumping EGLStream patches on KDE and GNOME, hoping every one else will be forced to follow.

Re: The death watch for the X Window System has probably started

#332

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…

Maybe a dumb question but why do people want to use Wayland if it's that horrible?

For a bunch of stupid, hysterical reasons, the Open Source X11 server still has all the warts of early-1990s release. XFree86 used the MIT X.Org core dump to implement open X11 on Linux, but outside of certain new things (DRI, XRender extension) it remained stuck in "world is dumb framebuffers with optional bitter" design.

Over time, a lot of useful stuff was broken and supported less and less, then reimplemented in bad way over compositors, instead of having composting Xserver like Xsgi.

Security extensions or even basic security tools (private input grab) got waylaid because toolkits didn't implement them (try running GTK3 on hardware without 32bit color GL or on system that defaults to lower bit depth than 32/24).

Generally, after letting it get more and more broken, the suggestion for big rewrite arrived. Said suggestion often results in something that resembles "devs first graphic stack", with a lot of basic, important features for daily life relegated to "someone will make an extension for it later" or "use D-bus to implement it elsewhere, and who cares about compatibility".

Re: The death watch for the X Window System has probably started

#333
post #183

Earlier quoted context omitted.

No not really similar. It is basically a raw video that transfers the full window content over the wire. X11 is capable of drawing primitives. Even though the most popular toolkits (Gtk, QT) sadly did not use them, those who did (e.g. Athena, Tcl/Tk) worked perfectly over the network, even modem lines. If Wayland would contain modern drawing primitives like those that Cairo offers which could easily be serialized, we…

I would be careful about describing cairo’s Primitives as modern. Cairo-style rendering apis and implementations are struggling to keep up with modern user interfaces and modern resolutions. It isn’t super clear which way 2d rendering apis will go in future. It seems silly to me to bake such an assumption into a protocol

What realistic alternative designs are there?

Re: The death watch for the X Window System has probably started

#334

Earlier quoted context omitted.

Are the technical problems documented anywhere where non-NVIDIA-driver-developers can learn about them? Most of the discussion I've read online argues that to support NVIDIA's solution, everyone would need to add if(nvidia) checks to their code and maintain them forever. But this argument only really holds in Wayland's bizarro-world where all programs that arrange windows must also bake in code that interfaces direct…

> Most of the discussion I've read online argues that to support NVIDIA's solution, everyone would need to add if(nvidia) checks to their code and maintain them forever. This is a severe misunderstanding of NVIDIA's solution. NVIDIA's solutions is so fundamentally different that you'd basically maintain two compositors internally: One that handles every sane driver, and one that handles NVIDIA. Nothing in wayland is…

> NVIDIA's solutions is so fundamentally different that you'd basically maintain two compositors internally: One that handles every sane driver, and one that handles NVIDIA.

If Wayland had a standard compositor interface like X has, this wouldn't be a problem at all, would it? You could write your compositor that talks to the hardware using your "sane" interface, and someone else could write a compositor that uses the NVIDIA interface, and users could pick the compositor that works for them and use it with any window manager they choose.

It's only because of Wayland's design that "GPU manufacturer creates nonstandard interface to their driver" is some giant, existential, ecosystem-fragmenting threat to the open-source community.

Re: The death watch for the X Window System has probably started

#335

Earlier quoted context omitted.

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 mi…

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…

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.

Re: The death watch for the X Window System has probably started

#336

Earlier quoted context omitted.

> I would use Wayland, but the most actively-developed tiling window manager, sway, doesn't work with the NVIDIA graphics card I own. May I suggest you buy an AMD GPU next time around; not only because they didn't try to impose their "standard" (which virtually nobody other than them implements, as far as I can tell) without implementing the de-facto standard interface, hurting their customers' access to Wayland to t…

> May I suggest you buy an AMD GPU next time around This doesn't help anyone. I bought an expensive Nvidia GPU 6 years ago, when AMD support on Linux was really bad. What do I do, throw out a perfectly good powerful graphics card and spend another $500 to satisfy the needs of some newfangled software which doesn't solve any of my problems? I've had 6 years to experience the horrors of Nvidia, on multiple machines. I'…

Your 6 year old GPU probably works fine with the nouveau driver, which is supported by wlroots.

Re: The death watch for the X Window System has probably started

#337

Earlier quoted context omitted.

NVidia has a horrible history of Linux support. GBM works just fine, they've simply chosen not to support it.

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.

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.

Re: The death watch for the X Window System has probably started

#338
post #50

Earlier quoted context omitted.

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 t…

I don't understand the ojection to dbus in particular. Are there not multiple implementations of the dbus spec?

Haven't seen a case of dbus daemon replacement, only I think one or two client libraries, and one is niche and the other is so niche I think less than 10 people ever used it.

Re: The death watch for the X Window System has probably started

#339
post #318

Earlier quoted context omitted.

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

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

Haha! Yeah, that's true.

Re: The death watch for the X Window System has probably started

#340

Earlier quoted context omitted.

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

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

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.

Post reply on HN