Hacker News new | ask | show | jobs
by happens 788 days ago
What's annoying to me is that when we talk about Wayland, the things it's capable of that X11 can't do are always left out. X has no fractional dpi scaling, and no per-monitor scaling, so it's a non-starter for both my desktop and my laptop setup.

X will never have those things, while Wayland is consistently improving. Yes it has rough edges, yes the security model might be over-engineered, but it's perfectly serviceable nowadays from my point of view.

4 comments

X HAS those things. Ubuntu's version of Gnome for example has supported fractional DPI scaling and per monitor scaling on X11 since I think 20.04. Upstream Gnome wasn't interested because that's what Wayland is supposed to do. Xrandr has made this possible for years with some setup.

Wayland is frustrating at basic crap. Just this past month I had issues sharing my screen, getting programs to use my PATH correctly and setting options. It's insanely stupid that SO much has moved over DE that how you do things between Gnome, KDE, etc. are now all radically different. It's actually worse than X11 in so many ways.

> X HAS those things. Ubuntu's version of Gnome for example has supported fractional DPI scaling and per monitor scaling on X11 since I think 20.04. […] Xrandr has made this possible for years with some setup.

Via some ugly hacks that degrade performance and make things look blurry. It‘s not the same.

I mentioned network transparency in another comment, and wayland will never have that unless they implement that "degrade performances and make things look blurry".

So meh, you give and you take, life is a compromise.

https://gitlab.freedesktop.org/mstoeckl/waypipe

here, found the wayland network transparency, fix your comment

Not officially supported, irrelevant
If you have known the structure of the Wayland protocol before making the comment, you'd know that "official support" is a red herring.

The only official thing provided by the Wayland project (other than the protocols themselves described in XML) is the wayland-server and wayland-client library pair, which is more or less just a serializer and deserializer of the protocol.

There is also Weston, but we don't talk about it.

Waypipe is about as official as Kwin, Mutter or wlroots, and yet we don't disregard those projects as being irrelevant due to their unofficial status.

There are maybe five people in the world that care about network transparency (an exaggeration, but probably not more than 2 magnitudes of order off). X11 was built for every scenario conceivable. Wayland is being built for end-user thick devices. What you decide not to do is more important than what you decide to do.

And some dedicated soul managed to get it working anyway, as a sibling comment has pointed out.

> What's annoying to me is that when we talk about Wayland, the things it's capable of that X11 can't do are always left out.

I think it's fair, considering we also leave out stuff that X11 can do that wayland can't do (and will likely never be able to do).

Example: network transparency. I still occasionally have to save the day by doing `ssh -X` and run some stuff on a remote host (but having a window be displayed on a local X11 server).

And I already foresee some idiot coming here and commenting that "you're not supposed to do that" to which i pre-reply: not all companies are FAANGS that can rework and rebuild everything that's sub-optimal. Many (most?) of us have to do the best with what we've got.

Wayland does have network transparency, it's called waypipe.

But caveats apply: applications which use the GPU are network translucent. You'd need VNC or other forms of streaming for that.

i didn't find that mentioned on waypipe, could you link a issue that mention that?
It's an inherent limitation of any network transparent windowing protocols.
X also has awful touchscreen support. When you use a touchscreen, you are just dragging the cursor around with your finger. In Wayland, touch support is what you'd normally expect (e.g. dragging scrolls pages instead of selecting text).
This is configurable[1]. I am writing this from a laptop with a touchscreen using X. I can use the touch screen fine and _browse_ Firefox with it and don't select text.

[1] https://wiki.archlinux.org/title/Firefox/Tweaks#Enable_touch...

X has decent touchscreen support, but it sucks at dealing with multitouch gestures, especially on touchpads rather than touch screens.
That's configurable in X and I've never had this issue.
exactly, you can go back and forth in firefox using your touchpad and i thing that very practical
But what if we just kept working on X11 instead starting from scratch?
The thing is, many things in X11 are "hardcoded" to the protocol.

For example, there is only one coordinate space in the X11 world. This meant that 1 pixel is always N "real" pixels (typically N=1).

But nowadays we have this thing called HiDPI, where 1 pixel can mean 1.5 real pixels on one screen (150% scaling), 2 real pixels on the second (200% scaling), and 1 real pixel on the third (100% scaling). We need mixed DPI and hence multiple coordinate systems, but you will break existing X11 programs if you tried to add that to the protocol, and at this point if you force your way through the problem it'll just be Wayland.

Existing X11-compatible systems "fix" this by:

1. assuming N=scale factor, thus upscaling all programs. Everything becomes a blurry mess (see XWayland).

2. assuming N=1, and let the programs upscale themselves. The problem is older apps (e.g. GTK2) don't understand HiDPI and you get a GUI for ants.

> But nowadays we have this thing called HiDPI, where 1 pixel can mean 1.5 real pixels on one screen (150% scaling), 2 real pixels on the second (200% scaling), and 1 real pixel on the third (100% scaling).

This is the wrong way to do scaling and even Wayland got it wrong and has been very slowly fixing things. What you actually want to do is just use real pixels everywhere and just tell the client "here's your NxM window size and it will be displayed in a X scale" and let the client do the intelligent thing. If it's a browser, a 3D game, or a PDF reader it will render directly at target resolution and scale with no fuzziness and those are most use cases people care about. GUI toolkits were stuck at integer scaling for a long time and thus the strange solutions to render at higher resolution and then scale down happened. All of this can work in X11, just always use native resolution for everything but Wayland is much better anyway and works great these days.

> What you actually want to do is just use real pixels everywhere and just tell the client "here's your NxM window size and it will be displayed in a X scale"

This is already how the Wayland fractional scaling protocol works. You have a 100x60 window and Wayland tells you the scale is 1.5. You give Wayland a 150x90 framebuffer and call it a day.

The giant problem with X11 is that it is still making the assumption that everything is one giant screen -- even if you have multiple monitors and whatnot. Even the act of sending a scaling event like Wayland does is a challenge on X11.

Wayland has gotten it right in the latest protocols but up to very recently it still did only integer scaling and scaled down for fractional. Scaling the buffer in fake coordinates is also needlessly complex. Just start with the 150x90 buffer to begin with and the scaling is just a UI hint. All of that would work fine with X11 exactly because there's no need for fake coordinates. All scaling is the client's job based on a DPI or scale hint.
Wouldn't that mean every application has to re-invent (or include) some form of scaling? Isn't it better than the display manager handles that for you?
The app knows how to render its UI, the display manager can only upscale or downscale what the app has provided. You get more performance and better quality if the app renders to the needed resolution in the first place, rather than if the display manager scales up or down to it.
But that's the point. It's a sunk cost fallacy.

The assumptions that X11 uses are incompatible with what personal computing turned into. Drivers, security, the networking part... All of it is just not how things work these days.

It is a major project, it is hard to push through but it's there already, with most of the work complete by now.

And as a programer I must say that underlying Wayland libraries are vastly better than X11 ever was.

Maybe we should consider starting over again in that case. Wayland increasingly appears to be supported by a sunk cost fallacy itself - the A11Y issues are not fixable in the base architecture, which means that every Wayland DM implementation needs to implement them again, which in turn means lots of different APIs, incompatibilities and so on.
go ahead them, show was how to make a good screen protocol that is as secure as wayland, and flexible, and one that support every type of screen, from cellphones, to VR, to desktop, go ahead, i'm waiting, show how these wayland normies(x11 too, they are the same people) how to make a protocol
Go ahead.

The people who actually work on it decided that was not the way forward, and chose another approach.

If you are qualified to work on it yourself, and you disagree, you can step up to maintain and improve X11.

No they decided working on X11 would not rake in enough consulting money. So they engineered a completely non-working solution called Wayland that is broken by design and takes years and many consulting hours to fix.
Calling it "broken by design" is an extraordinary claim and requires extraordinary evidences to back it up.

Now, X11 being un-sandboxable is truly something broken by design.

> "broken by design" is an extraordinary claim and requires extraordinary evidences

There are many technical aspects that make Wayland broken by design (like default forced vsync, forced double buffering, a fucked up event-loop for single threaded applications or severely lacking functionality for things like window positioning or screen sharing). But the biggest problem is the design-philosophy: Wayland makes life extremely easy for gate keeping "Protocol Designers" and extremely hard for application developers.

> un-sandboxable

Not true. The quick and dirty way would be using Xephyr. Besides that many access control hooks like XACE are present and standardized in the X11 protocol for many years. Application developers just choose not to use them. So if X11 is not secure enough for you, blame GNOME and KDE, not X11.

> like default forced vsync, forced double buffering,

A few things:

1. Vsync-by-default is the norm. X11 was the outlier.

2. Wayland does triple buffering, not double buffering.

>a fucked up event-loop for single threaded applications

I dunno, I wrote Wayland applications and I did not notice any peculiarities w.r.t. the event loop, at least in comparison with other platforms like Win32.

You need to expand a little more.

>window positioning

I suggest to read up on the Gitlab MR for the in-development window positioning protocol. The basic TL;DR is that window positioning has certain implications regarding tiling window managers and other unusual desktop usecases e.g. VR.

>screen sharing

I just shared my screen this morning.

> Not true. The quick and dirty way would be using Xephyr.

...So what you are saying is that you'd need a separate server running. Thanks for telling me that X11 is unsandboxable.

"broken by design" proceeds to work perfectly, lol, i don't can that broken by design
Nobody wants to keep working on X11, its design is fundamentally mismatched with the needs of a modern graphics stack and it contains a ton of legacy code and layers that make development difficult.

Check the lwn.net archives for some articles that explain this in detail.

The X11 DRI3 buffer swap mechanism is identical to the one used in Wayland. The fact that Wayland has still worse performance across the board (especially latency metrics) might be an indicator that Wayland is fundamentally mismatched with the needs of a modern graphics stack.
You are basing your conclusions on a single blogpost. Measurements from other people show that X11 wins in some cases, Wayland wins in other cases, there isn't a clear winner.

https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-...

> X11 wins in some cases, Wayland wins in other cases

Even according to your blog post uncomposited X11 wins in all cases (or is tied within the error of one millisecond). It especially sweeps the floor with immediate rendering.

Uncomposited anything is madness in 2024. You have the VRAM, use it and save your battery life / power which is arguably far more important. It being tear-free is a very nice bonus on top of the power savings too.

(And no, composition is not just for 3D cube effects or anything like that. Although it certainly enables them.)

MacOS have moved on, Windows have moved on, Linux should do the same.

I think the problem is nobody actually wants to work on x11.
What does that meme even mean? Are you saying if Red Hat wanted to hire people to work on X11 they would get 0 people applying?? I really doubt that.
I think it means RedHat takes opinions of their technical staff into consideration and thinks their money is better invested into Wayland.
I see your approach is quite radical. But I think the real issue here is that we expect the developers currently working on Wayland working faster.

I managed to be a bystander in this debate as I've been using X exclusively but I do hope that one day Wayland gets all the functionality and performance of X, and people stop getting frustrated by it.

Yes, if Red Hat wanted to, there wouldn't be nobody. Like you say, if Red Hat wanted to, they could hire those people to work on X11. Conversely if "Red Hat doesn't want to work on X11", then they wouldn't hire those developers, and now nobody wants to work on X11.
Right, so the problem isn't "nobody wants to work on X11", it's that "Red Hat management doesn't want to hire anybody to work on X11", and phrasing it as the former is extremely dishonest.
Why is Red Hat the one who has to pay for development? Why not any other Linux contributor? Ubuntu, Google, AMD. They don't want to hire anybody to work on X11 either. Why not you? That's why it's "everybody doesn't want to pay for development", which is shortened to "nobody wants to".
The people actually working on X11 decided it was worth starting from scratch.
So fire them and hire people that want to work on X11.
Have you ever worked on a project when after several years it became clear that the initial assumptions were wrong and the current design is untenable? Like, users asking for simple features that you know could be implemented in just a few lines of code had the design been done differently but now require many weeks of months of clunky hacks? Because I did and in some cases the initial decisions were mine - I had to admit I was wrong and do what is logical to make it easier for both developers and users.
Are we talking about Wayland or X11 here? Because like the article mentioned, Wayland is now 15 years old and still sucks. Sure sounds like the Wayland design is untenable.
What's stopping you from using (and even developing) X11? It's an open competition.

Wayland might reach feature parity in 2, 5, 10, or 20 years, and I'm fine waiting, because while X11 can kinda work well now, its archaic design with 10 levels of hacks will likely make it extremely hard to support new needs (it already struggles with some existing use cases).

> 15 years old and still sucks

People dragged their feet on Wayland support for at least 10 years.

> Experts agree. And if they don‘t, we‘ll find ones who do!
I want to speak to the manager of Unix!
We can do both at the same time.

Are you working on X11 though?