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

101–110 of 250 posts

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

#101

Post by kaba0 »

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…

That’s why eg. Macs default to integer-only scaling. But using them at 1x will make everything unusably small.

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

#102

Post by kaba0 »

upofadown wrote: post #94
fyrn- wrote: post #2

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

It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.

Wlroots would like a word with you.

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

#103

Post by vidarh »

DonHopkins wrote: post #84
vidarh wrote: post #53

Earlier quoted context omitted.

X worked just fine on early 90s hardware. Performance today is about implementation, nothing inherent about X.

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 necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.

So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.

There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.

In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.

EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.

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

#104

Post by emersion »

phendrenad2 wrote: post #58

No mention of sockets? I'm surprised. That's the real tricky part of writing an X11 server...

This article is about writing an X11 window manager, which is a different piece of software. An XWM is an X11 client. Writing an X11 server is a much more involved effort (there's a reason why there's only one widely used implementation, Xorg).

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

#105

Post by vidarh »

Seirdy wrote: post #96
pantalaimon wrote: post #89

Earlier quoted context omitted.

There are no problems with running Vulkan applications on X11. You must confuse something here - wlroots recently got a Vulkan backend , meaning you can run it on top of Vulkan API. It has nothing to do with what Graphics API the clients will use.

I was referring to the fact that OpenGL is becoming a second class citizen among the silicon giants, with more attention being drawn to Vulcan/Metal/etc. Now that sway supports a Vulcan backend, it won't be left in the dust stuck on OpenGL. I'm not aware of GNOME or KDE having similar improvements on their X backends or the same happening for X WMs.

X WMs do not have anything to do with rendering. The conflation of the server/compositor with the window management is a Wayland thing, and one of the big regressions in flexibility that current Wayland compositors bring. You may be confusing X WMs with the X server or with the toolkits rendering backends.

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

#106

Post by kaba0 »

josefx wrote: post #16
5e92cb50239222b wrote: post #12

Earlier quoted context omitted.

What "Wayland people"? You probably mean the former Xorg developers who shifted to full time Wayland development long ago. Xorg is on life support, it has been getting bug fixes and nothing else for the past several years. From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.

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

> 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

You mean under “they” the linux kernel devs? Because it has absolutely nothing to do with wayland. Nvidia cards’ proprietary drivers work with X because you are using a part-binary blob for X. Also, finally nvidia realized that they should goddamn support linux, so what all these resulted/will result in is better integration for people with nvidia cards.

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

#107

Post by kaba0 »

jgb1984 wrote: post #49
IiydAbITMvJkqKf wrote: post #29

Earlier quoted context omitted.

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.

> Xorg is an amazing piece of software

Based on what? Because I rather believe its maintainers..

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

#108

Post by Macha »

microtonal wrote: post #100
blacklion wrote: post #50

Earlier quoted context omitted.

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.

Wayland is pushed by people, who do embedded Linux. Maybe when Wayland was started. But X.org is now effectively unmaintained and most of the core X.org developers are now working on Wayland. From the release maintainer of X.org: So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so we…

> So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse

This implies it's a choice made in isolation, rather than with the matrix of WM features and hardware support driving.

People aren't "choosing" Wayland or X in large numbers. They're making decisions like "I'm using distro A which ships Wayland by default" or "I want a tiling WM and have nvidia hardware, so I have to use X".

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

#109

Post by vidarh »

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

> Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link.

i3/dwm (or any X window manager), unlike Sway (or any Wayland compositor) has nothing to do with client window contents rendering. X and Wayland works fundamentally differently in that respect. Under Wayland the compositor and wm is the same. Under X the server and wm are separate programs in separate processes, and the latter is not involved in rendering the client window contents, only the window chrome, if any.

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

#110

Post by kaba0 »

qwerty456127 wrote: post #62
Seirdy wrote: post #56

Earlier quoted context omitted.

ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing. Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.

What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO. I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way…

Have you tried playing a video? Or moving a window around fast? Without a compositor there will be tearing on X. With a compositor, X is just a useless middleman.
Post reply on HN