Hacker News Reader

Comment by o11c | Hacker News Reader

"Wayland is a protocol" is exactly the problem. Protocols suck; they just mean multiplying the possibility of bugs. A standard implementation is far more valuable any day.

With X11, it was simple: everybody used Xfree86 (or eventually the Xorg fork, but forks are not reimplementations) and libX11 (later libxcb was shimmed underneath with careful planning). The WM was bespoke, but it was small, nonintrusive, and out of the critical path, so bugs in it were neither numerous nor disastrous.

But today, with Wayland, there is no plan. And there is no limit to the bugs, which must get patched time and time again every time they are implemented.

View on HN

X had garbage handling of multiple monitors and especially multiple monitors with different DPIs, and there was "no plan" to deal with that either. Nobody wanted to work on the X codebase anymore. The architecture bore no resemblance to the way any other part of the desktop stack (or hardware) works.

Most of the garbage aspect is because toolkits refuse to support multiple monitors on DPI with X11 with the argument that "Wayland is just around the corner", for decades now.

For example Qt does per-monitor DPI just fine on X11; it's just that the way to specify/override the DPI values just sucks (an environment variable).

This stupid decision is going to chase us until the end of times since Xwayland will have no standardized way to tell its clients about per-display DPI.

It's not useful if you have to specify a scaling factor before the application has started, when the application can move monitors.

This is something feasible on Wayland, X draws one large wide screen display.

Yes. It just proves that all you needed is a better way to specify the per-monitor DPI, one that can be updated afterwards, or even set by the WM on windows.

X11 used to provide separate displays, but at some point due to hardware changes (and quite probably due to prominence of intel hardware, actually) it was changed to merged framebuffer with virtual cut out displays.

In a way, Wayland in this case developed a solution for issue its creators brought into this world first

It can still provide seperate displays. The problem is you couldn't do something like drag a window from display 1 to 2°. IIRC it's also annoying to launch two instances of a program on both displays. The hacky merged framebuffer thing is a workaround to these problems. But you can have independent DPIs on each display.

° For most programs.

Yeah there were certainly tradeoffs. It's much harder to use separate displays now, though - last time I tried, I could address the two displays individually (":0.0" and ":0.1") if I launched X on its own, but something (maybe the display manager?) was merging them into a single virtual display (":0") as soon as I tried to use an actual desktop environment. (This was was Mint 20, MATE edition, a few years ago - I gave up and reverted to a single-monitor setup at that point.)

X could do seveal different screens I did have this working once. However then moving an application to a different display was impossible (an app could do it but it was a lot of work so nobody bothered). I few cad programs supported two streens but they were seperate and the two didn't meet.

Most people want to drag windown between screens and sometimes even split down the middle. One large display supports that much easier so that is what everyone switched to in the late 1990

I was using it that way until about 2020. (Mint 13 MATE supported, but it seems that capability was lost somewhere along the line. Shame, because I have a dual monitor setup where the second monitor is often displaying the picture from a different device, so in that situation I absolutely cannot have applications deciding to open on the busy-elsewhere screen. I miss being able to set a movie running on one monitor and have it not disappear if I flipped virtual desktops on the other!)

Yes, separate screens would be a much better model for me as well. Much better than KDE randomly deciding to show KRunner on the turned off TV for some reason unless I manually disable the output.

X11 does a lot of things that are outdated now, and multiple independent screens is one of them. Ideally, you'd be able to select either independent screens or one big virtual screen, and still have a window manager be able to move windows between independent screens. I don't know how that would be achieved though.

X's "mechanism, not policy" has proven to be a failure. Without a consistent policy you end up with a pile of things that don't work together. "One big virtual screen" is a policy and it's one that works well enough.

Deciding what needs to be in the protocol and what should be in the application is never easy. It's important to be able to iterate quickly and avoid locking in bad practices. I think that's what Wayland tried to do by making everything a fine-grained extension, but it doesn't really work like that as the extensions become mandatory in practice.

> It's not useful if you have to specify a scaling factor before the application has started, when the application can move monitors.

Windows does this. Try to use in Windows 2 monitors with 2 different scalling factors. It is hit or miss. 100 and 150 works. 100 and 125 doesn't.

For the record: you can specify a different DPI _for each monitor_ for Qt X11. You just cannot change it after the program has started, which is exactly the limitation I was referring to.

But you can definitely move windows to another monitor and Qt will use the right DPI for it. It is the same behavior as Wayland. "One large wide screen display" is exactly how Wayland works...

This is not "just fine" in my book: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input...

>Nobody wanted to work on the X codebase anymore.

That, i think, is the main issue. Nobody wants to work with GTK1, or GTK2, or GTK3 anymore. Nobody wants to work with QT1, or QT2, or QT3 or QT4 anymore. Everybody wants the new shiny toy. Over and over again.

It is CADT all over. Earlier X was developed by an industry consortium. Now Wayland is a monopoly pushed by RedHat.

> Now Wayland is a monopoly pushed by RedHat.

Pushed but still it seems it flails and takes too long to do the basic stuff

RedHat is still mostly a server side company isn't it?

Can we trust them to "care" about desktops?

Oh wait. There is no more RedHat. There is IBM.

They care about applicances and phone-likes. Which is what Wayland is geared towards. Desktop is just there to do the free testing for them.

Exactly, same situation as with audio. Instead of improving the OSS API we got ALSA, PulseAudio, and now PipeWire (and a bunch of less mainstream alternatives) -- all with their own weird issues. And of course it's application (or at least toolkit) developers that bear the cost of this churn, not the developers that get to work on their fancy new NIH tech that they'll then abandon before being 100% stable for yet another reimplementation.

Software has bugs and water is wet. Wait til you hear about HTTP, TCP, UDP, IP torrents, etc... and "simple" is not really a term I would designate to X11. I mean, its fine, but even just the ecosystem surrounding X is convoluted, outdated and absurd. Things like xinit, startx, .Xauthority, xresources, xhost etc... are all a mess.

Reply on news.ycombinator.com