How X Window Managers Work, and How to Write One (2014) • Hacker News Board

Re: How X Window Managers Work, and How to Write One (2014)

#221

Post by md8z » Wed, Nov 03, 2021, 10:32 PM UTC

vidarh wrote: post #214

md8z wrote: post #194

Earlier quoted context omitted.

Once you are talking about double/triple buffering every client, you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue. Of course Wayland doesn't "solve" it but it does remove the old slow code paths. If you're on an SoC with a GPU then you want to use it as much as you can otherwise you are wasting CPU. The rest of your comment doesn'…

> Once you are talking about double/triple buffering every client Nobody is talking about double/triple buffering every client, but the final composited surface. > you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue Double-buffering was viable and done on quite a lot of 1980's hardware. The point remains that this is not a protocol i…

You need to double buffer the clients or you will still get flickering and noticeable redraw. You can see this with older X clients. It actually is a protocol issue because X was explicitly designed to do this.

You are presenting this as if it's some kind of decision between "break compatibility" and "start from scratch" when really those are a lot closer than you think. Realistically, most of the X server is still overdue for a major rewrite/refactor. But I really doubt anyone would ever volunteer to do that work at this point.

Re: How X Window Managers Work, and How to Write One (2014)

#222

Post by md8z » Wed, Nov 03, 2021, 10:45 PM UTC

ddingus wrote: post #205

md8z wrote: post #159

Earlier quoted context omitted.

I would be interested to know why you think that, is this website not a multi-user graphical thing running on a computer? Edit: Also I'm pretty confused as to why anyone refers to X as "multi-user", are you talking about multi-pointer X? That doesn't really have anything to do with X in particular and is also possible in Wayland.

Well, on an X window display, I could have: Fonts from one machine Window management from another An application running on yet another, with it's program data sourced from yet another machine accessing data on still another machine. All of which is displayed on another machine also supplying user input. Or, I could do something crazy like put a window on your display, with appropriate permission of course, and you c…

All of that is extremely possible with a web app though, and most of it is probably done even easier with a web app. In fact that is the usual way to build a web app, make a server that does the heavy lifting and then make a GUI that runs in the client which can then be accessed by multiple users. You can easily access them from a smartphone too.

The only exception is this:

"Another case might be several users running on one machine each with their own displays and inputs."

This would be multi-seat which doesn't really have anything to do with the display server. It is implemented in udev and logind, which spawns additional X or Wayland servers for each additional "seat".

Re: How X Window Managers Work, and How to Write One (2014)

#223

Post by destructionator » Wed, Nov 03, 2021, 10:54 PM UTC

kaba0 wrote: post #213

destructionator wrote: post #210

Earlier quoted context omitted.

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

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".

Re: How X Window Managers Work, and How to Write One (2014)

#224

Post by enriquto » Wed, Nov 03, 2021, 11:43 PM UTC

hollerith wrote: post #179

loxias wrote: post #43

Earlier quoted context omitted.

Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right? In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel…

You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland. (Those apps use something called XWayland, which is blurry if the user has configured a non-standard size for things.) 99.9% of fonts these days, most icons provided by the OS, and most other g…

> You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland.

This can be true only if you use a really narrow definition of "apps adapted for Wayland". For example, a viewer of png files may not be possible to adapt to wayland? A png file is just an array of pixels (typically without a meaningful dpi). How are you going to ever display it without interpolating and resampling?

Re: How X Window Managers Work, and How to Write One (2014)

#225

Post by md8z » Thu, Nov 04, 2021, 12:14 AM UTC

destructionator wrote: post #223

kaba0 wrote: post #213

Earlier quoted context omitted.

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

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

"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.

Re: How X Window Managers Work, and How to Write One (2014)

#226

Post by [deleted] » Thu, Nov 04, 2021, 12:39 AM UTC

md8z wrote: post #222

ddingus wrote: post #205

Earlier quoted context omitted.

Well, on an X window display, I could have: Fonts from one machine Window management from another An application running on yet another, with it's program data sourced from yet another machine accessing data on still another machine. All of which is displayed on another machine also supplying user input. Or, I could do something crazy like put a window on your display, with appropriate permission of course, and you c…

All of that is extremely possible with a web app though, and most of it is probably done even easier with a web app. In fact that is the usual way to build a web app, make a server that does the heavy lifting and then make a GUI that runs in the client which can then be accessed by multiple users. You can easily access them from a smartphone too. The only exception is this: "Another case might be several users runnin…

[deleted]

Re: How X Window Managers Work, and How to Write One (2014)

#227

Post by ddingus » Thu, Nov 04, 2021, 12:45 AM UTC

md8z wrote: post #222

ddingus wrote: post #205

Earlier quoted context omitted.

Well, on an X window display, I could have: Fonts from one machine Window management from another An application running on yet another, with it's program data sourced from yet another machine accessing data on still another machine. All of which is displayed on another machine also supplying user input. Or, I could do something crazy like put a window on your display, with appropriate permission of course, and you c…

All of that is extremely possible with a web app though, and most of it is probably done even easier with a web app. In fact that is the usual way to build a web app, make a server that does the heavy lifting and then make a GUI that runs in the client which can then be accessed by multiple users. You can easily access them from a smartphone too. The only exception is this: "Another case might be several users runnin…

Seems you highlighted the differences nicely enough.

Re: How X Window Managers Work, and How to Write One (2014)

#228

Post by md8z » Thu, Nov 04, 2021, 1:22 AM UTC

ddingus wrote: post #227

md8z wrote: post #222

Earlier quoted context omitted.

All of that is extremely possible with a web app though, and most of it is probably done even easier with a web app. In fact that is the usual way to build a web app, make a server that does the heavy lifting and then make a GUI that runs in the client which can then be accessed by multiple users. You can easily access them from a smartphone too. The only exception is this: "Another case might be several users runnin…

Seems you highlighted the differences nicely enough.

Is that sarcasm? A key difference I would say is that the web is actually better because you can run javascript or WASM code in the browser, in X that would be the equivalent of the "server"...

Re: How X Window Managers Work, and How to Write One (2014)

#229

Post by ddingus » Thu, Nov 04, 2021, 3:29 AM UTC

md8z wrote: post #228

ddingus wrote: post #227

Earlier quoted context omitted.

Seems you highlighted the differences nicely enough.

Is that sarcasm? A key difference I would say is that the web is actually better because you can run javascript or WASM code in the browser, in X that would be the equivalent of the "server"...

Not at all.

Re: How X Window Managers Work, and How to Write One (2014)

#230

Post by hulitu » Thu, Nov 04, 2021, 7:30 AM UTC

ch_123 wrote: post #92

loxias wrote: post #24

Earlier quoted context omitted.

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community o…

Here is one list of problems with X11 which Wayland solves. One of the author is someone who has done a lot of work on Xorg, so they know what they are talking about: https://www.phoronix.com/scan.php?page=article&item=x_waylan...

This link shows what is the problem with SW development, not with X . The same thing is done also in QT or GTK. Why a program written for QT4 cannot compile in QT5 ? Why every library release must be incompatible with the predecessor ? I was able to compile and run X10 programs in X11. Why do i need to have on my linux system more than one version of a library ? Will Wayland fix that, because from this article I see that it is more or less in the same mess of incompatible libraries ?