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)

#131

Post by loxias » Wed, Nov 03, 2021, 1:30 PM 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...

Thank you! No idea why your comment is so low. Most educational one here.

I enjoyed reading that link -- a fact oriented list, directly answering my question, rather than an assumption that I want eye candy or resampled resolutions. Fixing the input subsystem alone feels like a compelling reason to use Wayland. It's also interesting to me that the list doesn't mention DPI, which seems to be of great concern here. :>

Having read that, I'm much less terrified, though it does mean I probably will have to take the time to write a window manager for Wayland. Thanks!

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

#132

Post by qwerty456127 » Wed, Nov 03, 2021, 1:35 PM UTC

Seirdy wrote: post #86

qwerty456127 wrote: post #79

Earlier quoted context omitted.

> ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio? > I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines. Why does it have to be? What do we get for this cost? The only things in which I wou…

> Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability. A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns.…

I see. Quite a reasonable, detailed explanation, thank you. I didn't notice any visible difference in perceived performance (just using the PC to write code, browse the web and watch videos) when I switched spectre/meltdown mitigations on/off on my old Core 2 Duo PC though. It just always worked perfectly fast.

Meanwhile, I often don't need any network connection (when coding, watching pre-download videos, or running data/number-crunching or build scripts). Can I expect 90s-like efficiency if I disable all the mitigations and hardening stuff?

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

#133

Post by kaba0 » Wed, Nov 03, 2021, 1:37 PM UTC

loxias wrote: post #128

kaba0 wrote: post #93

Earlier quoted context omitted.

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

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

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

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

#134

Post by IiydAbITMvJkqKf » Wed, Nov 03, 2021, 1:38 PM UTC

dfox wrote: post #125

IiydAbITMvJkqKf wrote: post #23

Earlier quoted context omitted.

All java applications refuse to render without said workaround, because AWT expects the WM to reparent its windows. This is IMO a bug in the JRE, because there is no requirement for the WM to reparent. I use steam on dwm without the steam patch, haven't noticed an issue so far.

Which is highly ironic as the probably only WM written in Java (Project Looking Glass) is not reparenting. IIRC the issue with AWT and non-reparenting WMs is mostly limited to popup (ie. override-redirect) windows that are positioned in relation to some kind of owner window (which means menus, tooltip popups...). AWT simply expectes that parent window of its window to be the frame window of reparenting WM and calulat…

AWT has hardcoded special treatment for WMs which call themselves "LG3D". Which is why [1] exists. Update: found the JDK code [2]

[1] https://tools.suckless.org/x/wmname/

[2] https://github.com/openjdk/jdk/blob/9759fcb17b62d76d75b89348...

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

#135

Post by kaba0 » Wed, Nov 03, 2021, 1:38 PM UTC

RedShift1 wrote: post #130

kaba0 wrote: post #93

Earlier quoted context omitted.

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

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.

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

#136

Post by ximm » Wed, Nov 03, 2021, 1:41 PM UTC

cunidev wrote: post #57

Is there anything similar for Wayland? Its protocol looks considerably more complex than Xorg's, and so are most resources to learn it.

I think the dwl codebase is an excellent read: https://github.com/djpohly/dwl

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

#137

Post by samus » Wed, Nov 03, 2021, 1:52 PM UTC

cunidev wrote: post #57

Is there anything similar for Wayland? Its protocol looks considerably more complex than Xorg's, and so are most resources to learn it.

It's quite ardous and unfun, but the wlroots project does most of the heavy lifting. For beginners it's probably useful to create a toy WM using wlroots[0] and dig deeper from there[1].

[0]: https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master... [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getti...

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

#138

Post by wander_homer » Wed, Nov 03, 2021, 2:07 PM UTC

arein3 wrote: post #78

loxias wrote: post #60

Earlier quoted context omitted.

> Then what is your complaint? What complaint? Why do you think I'm complaining? I wanted to know what's so fundamentally wrong with X to warrant a massive developer effort to replace it. Based on the comments here, I have my answer: Nothing's wrong with X. Also, something lighter weight is desired for embedded platforms. Some fraction of the population, like you, wants their display system to render in terms of poin…

if you buy a high pixel density display (ex a 15 inch laptop with a 4k display) then you need to be able to map 2 real pixels to 1 logical pixel (what apple did with retina displays)

And this works perfectly fine already with X11. You only encounter issues when you add an additional display with different DPI. But dual monitor setups are the exception, and mixed DPI setups are even less common.

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

#139

Post by qwerty456127 » Wed, Nov 03, 2021, 2:10 PM UTC

vidarh wrote: post #123

kaba0 wrote: post #121

Earlier quoted context omitted.

Other than writing an X server implementation is akin to writing a web browser from scratch?

There's absolutely no reason to write an X server from scratch to add native compositing support. You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support ol…

> You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done.

If so, why are we observing apparent shortage of developers to maintain the actual Xorg? I can't believe there are no people interested in maintaining it in the whole world. I thought it's so complex it just requires much more expertise and dedication than anybody is ready to invest.

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

#140

Post by DonHopkins » Wed, Nov 03, 2021, 2:18 PM UTC

vidarh wrote: post #103

DonHopkins wrote: post #84

Earlier quoted context omitted.

Mid 80s hardware, actually. Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here: https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative O…

> Mid 80s hardware, actually. I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :) > WHAT IS YOUR ROOT? A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though. The X protocol is messy in places, but Xlib is far worse than nec…

The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib.

I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp.

https://www.cliki.net/clx

Few people still write applications directly to XLib, but many do write applications directly to toolkits and libraries that DO depend on XLib.

So we're all stuck with XLib from now until eternity. If you replace it, you lose the entire ecosystem of client side extension libraries, so you have to reimplement them all from scratch.

At the time, that was a no-go if you wanted to use Adobe's proprietary Display PostScript extension, which was quite popular and included with most commercial X11 servers of the era. Even if most important X extensions are open source, how about about them NVIDIA drivers?

Display PostScript is simply an old example from 1992 of what I mean, that I wanted to use from Common Lisp via CLX, but couldn't. But it shows how this problem has been around for a long time, and is never going away. The only viable solution was to dump CLX and call XLib and the Display PostScript extension libraries directly from Lisp through a wrapper layer.

But now the problem with clients and toolkits depending on X11 extensions is much more entrenched, not just limited to high-end exotic graphics-rich apps that want to use Display PostScript to draw a nice pie chart.

That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries -- just to measure the display, shape windows, listen for input, memory map pixmaps, and composite the first pixel on the screen -- because they've long since abandoned X11's horrible old built-in pixel-based rendering API, broken font model, leaky input system, etc, and switched to using full stacks of X11 extensions (via their XLib based libraries) instead.