Live data from Hacker News

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

jichu4n.com

11–20 of 250 posts

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

#11
post #2

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

That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.

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

#12
post #11
post #2

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

That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.

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.

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

#13
post #9

Talk about timing, I took my first plunge into writing code for X just a week or so ago and this was some really good reading. If someone is interested in digging into a non-toy, C codebase I can highly recommended dwm [1,2]. Yes, it is a very opinionated WM, but the code is clean, brief, and hackable – even for someone like me that has not hacked C for anything serious for over a decade – for something that can be u…

Keep in mind that DWM explicitly does not obey the ICCCM [0] (because they don't like it), meaning that large groups of applications might function erratically on it. This is not an idle concern -- I've had several bugs reported to me in some applications I've written were because the user wasn't running an ICCCM-compliant WM.

[0] https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm... , the standard for how X11 clients and WMs should communicate.

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

#14
post #13
post #9

Talk about timing, I took my first plunge into writing code for X just a week or so ago and this was some really good reading. If someone is interested in digging into a non-toy, C codebase I can highly recommended dwm [1,2]. Yes, it is a very opinionated WM, but the code is clean, brief, and hackable – even for someone like me that has not hacked C for anything serious for over a decade – for something that can be u…

Keep in mind that DWM explicitly does not obey the ICCCM [0] (because they don't like it), meaning that large groups of applications might function erratically on it. This is not an idle concern -- I've had several bugs reported to me in some applications I've written were because the user wasn't running an ICCCM-compliant WM. [0] https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm... , the standard for how…

Do you have a link to a bug report? I tried digging around a bit as I got curious how bugs like these would manifest, but could not find anything good to link. What I am aware of is that Java application can break without workarounds (saw it in the documentation somewhere) and that Steam needs an explicit workaround [1].

[1]: https://dwm.suckless.org/patches/steam

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

#15

So for someone who knows nothing about this stuff, how is Wayland different?

In general, wayland does not implicitly have a distinction between server and window manager. There is a server and there are clients. The server gets to decide where a particular client's windows are rendered. Wayland itself is just a spec of the protocol that the client and server use to talk to each other - the format of the messages, and a few documents that describe various such messages. What the server does is basically completely arbitrary.

I don't know about GNOME and KDE's wayland servers, but with sway and river and cage the server is a single process that does the job of both server and window manager. It doesn't mean everyone has to write the equivalent of an X server, ie code that interacts with OpenGL and the kernel interfaces, themselves - there is a popular library called wlroots that can be used for that.

I don't think it's impossible that someone wraps wlroots into a standalone "server" binary that then has its own protocol for talking to an arbitrary "window manager" binary at runtime. ie do the equivalent of what wlroots does with function calls and callbacks at compile time but at runtime via IPC. But I don't know anyone who's doing such a thing.

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

#16
post #11

Earlier quoted context omitted.

That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.

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 wheel from 2010 with minor problems.

Now imagine wayland, a brand new tesla, it doesn't have brakes or a steering wheel because history has shown that these concepts evolve and if anything it should be a third party provider that creates them. Who cares that it took ten years between the release of the car as ready for use and the first compatible steering wheel implementation? 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.

> From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.

As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs). Of course the people who wrote wayland also wrote X11 so removing themselves from the equation might have been the nicest thing they ever did, given their own opinion of their past work on X11.

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

#17
post #2

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

Does upstream Wayland work on any platform except for Linux?

Does this display server have any form of colour management for, you know, the stuff it's displaying?

Wayland is taking off like the Spruce Moose...

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

#18
post #11

Earlier quoted context omitted.

That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.

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

I don't think life support is appropriate here. It still works well.

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

#19
post #16

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.

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 even now, because it requires a proprietary driver, so compositor / Mesa / kernel devs cannot debug the full stack when anything goes wrong. So having your problems ignored is something you'll have to get used to if you choose to use hardware that requires proprietary drivers, regardless of whether you use it with X or wayland.

>As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs).

wlroots exists to solve that problem. Whether an individual compositor decides to use it or not is up to the compositor.

At least in KDE's case, wlroots did not exist at the time they added Wayland support so of course it's understandable that they don't use it. There's a fork of kwin that uses wlroots ( https://gitlab.com/kwinft/kwinft ) but I believe it's just an experimental one-person effort rather than anything that kwin devs are working on as a replacement.

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

#20
post #11

Earlier quoted context omitted.

That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.

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.

FYI there are crowdfunding efforts to keep Xorg maintained https://news.ycombinator.com/item?id=29034479 . The recipient is the current X server maintainer so it's likely this is the best way to help keeping Xorg maintained.
Post reply on HN