Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jichu4n.com

Post reply on HN
Print view View original

41–50 of 250 posts

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

#41

Post by mrweasel »

linguae wrote: post #3
fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

1. The article was written in 2014. 2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver ( https://wiki.freebsd.org/Graphics/Wayland ), though work has been done getting Wayland compositors and ot…

Someone has started work on OpenBSD Wayland: https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-...

I doubt it's something that will be ready for 7.1 next spring, but it's nice to see that it's actually working.

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

#42

Post by Seirdy »

sprash wrote: post #30
fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

> right as the replacemeant for Xorg starts to take off though It has been "taking off" for 13 years at this point. It seems like it doesn't have much thrust behind it.

Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years.

On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not familiar.

Wayland has already taken off; once we get XFCE to switch we should be able to move on.

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

#43

Post by loxias »

perth wrote: post #38
loxias wrote: post #35

Earlier quoted context omitted.

What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow. One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors. Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...

Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks…

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

I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal.

Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone.

It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)

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

#44

Post by enriquto »

perth wrote: post #38
loxias wrote: post #35

Earlier quoted context omitted.

What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow. One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors. Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...

Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks…

> The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI.

The word "properly" here is quite subjective, though. I have a similar setup, combining monitors of different pixel sizes. It works properly with Xorg: When I move a window of size WxH pixels from one monitor to another, it remains a window of WxH pixels. A thin line of one pixel width remains so. A checkerboard pattern that tingles the monitor refresh rate remains so. This sounds like perfectly appropriate behavior, and anything else would be ridiculously inappropriate. I accept that this usage of "appropriateness" is subjective to a subset of people that includes me, but it may not be universal.

Whatever, this is such a thin point for Wayland: hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. But hey! you can combine monitors of different pixel size as if they had the same pixel size! See, the thing transparently re-scales your windows using cheap-ass bilinear interpolation so that they get the exact same size in millimeters! Fancy, isn't it?

No. It's creepy.

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

#45

Post by 5e92cb50239222b »

josefx wrote: post #37
Arnavion wrote: post #19

Earlier quoted context omitted.

>Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction. a) nvidia's refusal to implement GBM in their driver was their own choice. The abstraction was never removed; GBM is the abstraction over all drivers. b) nvidia already relented and implemented GBM in their driver. The latter doesn't necessarily mean nvidia is a good choice of GPU e…

> So having your problems ignored is something you'll have to get used to if you choose to use hardware that requires proprietary drivers 3..2..1 and the floss copy pasta has arrived a bit delayed but still as expected. Might want to check if the server your bot is running on is a bit overcapacity to fix that delay. Still not going to amputate my leg over a stubbed toe even if RMS considers the toe cancer. > GBM is t…

I really don't see why a bunch of unpaid volunteers should bother to support the only player in town that refuses to play nicely and tries to strong-arm everybody else to use its technically inferior solution.

Here's a nice write-up. I can imagine how nice it is to spend all your waking time trying to improve the Linux graphics stack and then listen to all the bullshit that we see in this discussion.

https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.ht...

That said, from what I heard, before nvidia backed down, GNOME and KDE developers started adding support for it in their Wayland compositors.

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

#46

Post by perth »

loxias wrote: post #43
perth wrote: post #38

Earlier quoted context omitted.

Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks…

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…

Yeah. I suppose this functionality isn't everyone's cup of tea. The cool thing about Wayland though is somehow it makes the windows still look crisp and good while making them the same size. With the canonical hack to xorg, they always looked blurry and gross. The gnome wiki had this to say on it:

"On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor."

So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.

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

#47

Post by Seirdy »

qwerty456127 wrote: post #21
fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

This is exactly why I would rather do. I see absolutely no reason to abandon X and want to learn its internals to be able to maintain it myself. To me X seems a perfect piece of software which just works and does its job flawlessly, while having all the features I ever needed (including remote execution - I used Windows apps running on a remote Linux machine with Wine over SSH over OpenVPN on a local Windows machine…

1. Wayland does support remote execution; see waypipe for an example.

2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).

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

#48

Post by danachow »

loxias wrote: post #43
perth wrote: post #38

Earlier quoted context omitted.

Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks…

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…

Then what is your complaint? No one is stopping you from using X for as long as you like. Meanwhile the majority of users that want sane, modern handling of HiDPI can move on.

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

#49

Post by jgb1984 »

IiydAbITMvJkqKf wrote: post #29
josefx wrote: post #16

Earlier quoted context omitted.

> Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering whee…

Xorg barely works on nvidia (source: me) vsync requires a compositor to work, and even picom needs a very specific combination of flags to get vsync to work. Chromium cannot gpu accelerate video playback. On rolling release distros, most major kernel updates leave your system broken, because nvidias out-of-tree driver can't build against new kernel versions. If nvidia stops supporting your old gpu, like they just did…

I have used strictly Nvidia gpus, on debian Linux, for 20 years, using the binary drivers, and I have none of the issues you describe. It just works, very well, stable and fast. Xorg is an amazing piece of software and combined with openbox it does exactly what I need.

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

#50

Post by blacklion »

loxias wrote: post #24
fyrn- wrote: post #2

Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though

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

Wayland is pushed by people, who do embedded Linux. Think: infotaiment system in your car. All UI is pre-installed and fixed to one (maybe, custom) toolkit, custom "window manager" (and it is not full-featured WM, as X11 ones are, as you can not move and resize windows arbitrarily), one theme, no remote access, very low response time. It is better than both X11 and plain framebuffer in this role, for sure.
Post reply on HN