Hacker News new | ask | show | jobs
by kaba0 1690 days ago
Or just try to go at things with an open-mind and hell, you might learn something?

X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayland.

3 comments

> a middleman in the communication of applications and the compositor

There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.

The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature.

> you can’t have displays with different DPIs

This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy.

What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals).

Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well. Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way.

And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.

> start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.

That’s just one part of what a compositor does. I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor — something solved entirely by wayland’s “every frame is perfect”. Even on window managers like sway which has absolutely no animation or eye candy. Android also uses composition even with animations turned off.

I’m not sure we mean the same thing with multiple monitors having different DPI settings. X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other. If both screens have the same DPI, X can also render at eg. at 2x size.

And thank you for trying it out, X is indeed a cool project that spanned 3 decades. But due to the very major improvements in the underlying hardware, its abstraction is simply not up to date.

> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor.

Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a bit of tear. But.. I don't do that. Most of the time if I'm watching a video it's full screen. It looks perfect.

I bet the tearing you've seen using Xorg is attributable to something else. I remember back when video kinda sucked (in anything other than mplayer) but that was years ago. I have a windowed Netflix playing video as I type this and nope, no tearing. shrug I see in the Xorg.0.log that the COMPOSITE extension is loaded, but I'm not running a compositing WM, nor am I running a stand alone compositor.

I think we can put this "Xorg video playback has tearing" myth to bed.

It was certainly true back when suspend and resume didn't always work right, but that was quite some time ago. Having read much about Wayland in the last few hours, I think a more accurate thing to say would be "In Wayland, there is never any tearing. In Xorg, you can have tearing under some conditions" There are some very compelling reasons to be interested in Wayland that don't require exaggerating Xorg's failings. :)

> X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other.

I think we have a different definition of "handle", and I apologize in advance for semantic pedantry. I'm looking at 3 screens right now, one of them is a 14" "4kish" (3200x1800). Xorg "handles" it just fine. As I drag a window to the highest resolution screen (which I have in portrait orientation and use basically only for coding), the content appears exactly as I expect it to. That monitor has a higher DPI, which means the pixels are a different size. It's not a bug... it's expected and desired behavior. Dots Per Inch. It's right in the name! If some software in the display stack was interpolating everything, making my text look fuzzy, now that would be a serious bug to me!

I really really think what you mean to say is "Xorg doesn't support rendering things in terms of physical size regardless of the underlying resolution." That might be true. Pleaseeeee say that instead. :) Personally, I wouldn't use that feature but I can imagine one desiring it.

But... when you say "X can't have displays with different DPIs" ... I mean this with no offense, but... you sound less intelligent than I'm sure you are. Because I can plainly see multiple displays with different DPIs right in front of my face. :) Xorg has been able to "handle" multiple displays since Xinerama, IIRC.

Anyway, I'm encouraged to take Wayland out for a spin for a reasons not mentioned in this comment thread. I like minimalism. :)

The reason you don't see any tearing is probably because video players under X have gotten better about "guessing" when the frame is supposed to be displayed. The knowledge to do that has accumulated over the last 30 years and it's a pile of hacks, and it's still possible for them to tear under various circumstances because X is still fundamentally an unsychronized protocol (unless you use a compositor with frame sync).
Thanks for this! I was thinking similarly, but you phrased it better than I could. My observation was "it used to suck, just like wireless, and suspend/resume, but now it doesn't." which matches perfectly with "software has built up a pile of hacks... aka bug fixes".

BTW, despite any appearances to the contrary, I recognize (and look forward to!) the superiority of an architecture based on fixed rate interrupts rather than a freewheel unsynchronized protocol. I was just afraid, previously, that:

1) All my stuff is gonna break! (Consider I've been using the same setup unchanged since the mid 2000s, and it's got a lot of self written code)

2) I'm gonna be stuck with a system I consider ugly!

3) My stuff breaking will be in exchange for nothing I consider worthwhile in return!

Now that I read the great article https://www.phoronix.com/scan.php?page=article&item=x_waylan..., much of my FUD has melted away. I know that #2 and #3 aren't true, #1 is probably true but now I'm looking forward to it.

> X is still fundamentally an unsychronized protocol

Again, factually false. X has various synchronization options from the older double buffer protocol to the XSync extension to the GLX/DRI vsync commands.

I've also never seen tearing in X since like 2006.

No, it's not factually false, those fall in the "pile of hacks" I mentioned, and none of them work in all cases, some of them are highly dependent on driver support which is spotty. I can show you various bug reports from the last few years of people still complaining about tearing. This problem is not even remotely close to being solved in X and I don't think it ever will be. Again just look at the bug reports.

Meanwhile, if you plumb atomic page flipping through the whole system and make it mandatory, the chances of having tearing are pretty nonexistent. But you have to drop legacy stuff from X if you want to do that.

It’s more like the video card: doing vsyncing, especially on video.
I don't understand, a video card cannot "do vsync" like that. If the program sends its contents at the wrong time then the video card can't do anything about that, the correct information is simply not there.
"This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy."

Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...

> ... "correctly" ...

You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective. To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen.

I will (grudgingly!) concede that perhaps it's not "universally and obviously correct" that things stay the same number of pixels, if you concede that perhaps it's not "universally and obviously correct" for windows to be drawn in terms of points and scaled behind the scenes.

We don't though, I mean if you explicitly change the scaling factor. Of course if you don't change the scaling factor then your scaling would technically be correct.
You're right! I'm sorry! You said "scaled correctly" but I misinterpreted as "appear/behave correctly".

Before this discussion I didn't have the concept of "scaling" my windows.. because that doesn't make sense to me, and it's something I'd never want. So my scaling factor for everything would be 1. Given that, Xorg "scales" perfectly.

> Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...

No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).

Yeah you do if you want to have the same window span across monitors. And if you have non-integer DPI scaling then things will probably always be either blurry or inaccurate, that is unavoidable.
Why can't the new display server just re-implement the X protocol? The implementation could leave out the unused parts.
It does, it’s called XWayland. So almost all functionality of “legacy” programs will continue to function under Wayland.
That word "almost" has me worried.
This post is completely false. Literally every word of it is false.
GPUs don’t have a single start, at least it depends on how you define them, but arguibly the first generally available one came in the late 1990s, compared to the various X server implementations that were around before that as well.

About its current role, there is a famous talk by an ex-Xorg developer that explains it well. Very crudely, a wayland compositor relays events to applications, which signals when it’s ready. Xorg on the other hand does these as well, but sits between the compositor and the clients, relaying their messages with some delay (and not having a concept of every frame is perfect)

Xorg doesn’t have support for mixed-DPI monitors, as it renders to all screens simultaneously with a single DPI setting. This is pretty much unfixable, it is so inside the core of the whole thing.

And finally, Xwayland exists and it is backwards compatible to the most part (other than manipulating wayland clients as if they were x ones, but that is also a wanted “functionality”). These are pretty much just nested x servers, so I don’t see how is it false?

X has had its OpenGL extension available since 1992. Your argument is like saying "Windows 1.0 came out before Direct X even existed, so of course you can't play modern games on Windows 10". As new things came out, they added support for it.

Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says "the X server only talks to the compositor" I'm like "lol what compositor".

But even if you have one, it is still wrong. You have to understand that GUI applications are a LOT more than just low-level rendering. So even if you didn't need it for that, there's so much more going on that the server still plays its role in like coordinating copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc.

And it isn't true that everything goes through the middle man. A graphics-heavy X application actually tends to work very similarly to a Wayland application (not coincidentally - as people love to point out, a bunch of the Wayland devs worked on the gpu rendering parts of X before): you get a direct render context, write to a buffer, then inform it to draw it. See more https://keithp.com/blogs/dri3_extension/

Mixed DPI is fully supported by the system, but may be buggy in applications. See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality, or do auto-scaling for easy support bridges. KDE and Qt manage to do it. So much for "unfixable".

"Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says 'the X server only talks to the compositor' I'm like 'lol what compositor'."

Can't you see how this is self-fulfilling though? People don't use X compositors because they suck and cause issues, so then you have people saying they don't use it because it doesn't add value. Well, yeah, compositing in X is bad and really convoluted and causes issues because X is not built for that, that's why they had to make Wayland to fix it.

"copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc."

The first two, yes, the rest of it not so much. The X server is quite bad when it comes to managing hotkeys or notifications or doing any of that stuff not related to window management and input, most of those uses have been replaced with D-Bus.

"A graphics-heavy X application actually tends to work very similarly to a Wayland application"

Yeah, using extensions that were made way after X was designed.

"See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality"

This article goes around every so often and every time it does, I have to point it out: Randr is not enough information to do mixed DPI. There is a reason the suggestions in that article have not been taken seriously. See this MR if you want more info on what actually needs to be done in the server to get this to work: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

It's for Xwayland but similar things need to be done if you want it to work correctly on the Xf86 hw. And also, you would still need a compositor for this.