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

51–60 of 250 posts

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

#51

Post by yyyk »

Seirdy wrote: post #40
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…

The biggest reason is security. X offers no GUI isolation. This is a basic mitigation that should have been the norm a decade or two ago. Advanced mixed DPI also comes to mind. Another is performance: Sway easily outperforms DWM/i3/AwesomeWM on most ARM devices when configured for minimal latency.

Security would be the worst reason. Zero cases in the wild, and it's not that difficult to add access checks to X - there used to be an X extension to do this.

The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.

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

#52

Post by loxias »

blacklion wrote: post #50
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…

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.

I've done a spot of embedded linux programming before and it is a royal PITA to do anything but the simplest graphics. I can easily see a role for Wayland for that.

This is a great answer, thanks. Also, the comment about GUI isolation for security makes sense (though I suspect x11docker would solve the security issues as well). Seems like Wayland is on track to be a good solution for a niche use case.

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

#53

Post by vidarh »

Seirdy wrote: post #47
qwerty456127 wrote: post #21

Earlier quoted context omitted.

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

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

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

#54

Post by forgotpwd16 »

low_tech_love wrote: post #7

Funny, yesterday someone posted an article about an Ada-based X implementation, and I thought “could be fun to write my own X”. I guess I wasn’t the only one!

For anyone that may have missed it: https://news.ycombinator.com/item?id=29077750

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

#55

Post by Seirdy »

enriquto wrote: post #44
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…

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

> hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before.

Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype.

Which apps don't support Wayland? The only ones on my machine that need XWayland are some video games and FLTK apps like Dillo (I have to test with xwininfo since it's normally impossible for me to notice if a program is using XWayland). All GTK/Qt apps work OOTB on Wayland as a first class citizen, especially since those toolkits nowadays receive more Wayland testing than X11 since barely any current distros still ship X in their default installations.

Which Wayland compositor/version and GUI toolkit/library gave you blurry bilinear filters?

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

#56

Post by Seirdy »

vidarh wrote: post #53
Seirdy wrote: post #47

Earlier quoted context omitted.

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

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

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.

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

#59

Post by phendrenad2 »

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.

Most of the concepts here are the same for wayland. The only difference is, Wayland handles compositing, whereas in x11 compositing is a pluggable component.

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

#60

Post by loxias »

danachow wrote: post #48
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…

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.

> 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 points, not pixels. To me, and many others, this would be hell, but hey, different strokes for different folks -- good software does what the user wants, not the developer's will.

> ...majority of users that want sane...

You troll. :P I think the majority of users want sane display systems that don't resample and change resolutions away from the native resolution of the hardware. To you, the majority of users want fuzzy text and ugly UIs. We're both wrong to assert this as some obvious fact, because neither of us speak for any user but ourselves!

If I have any complaint (which, again, I'm not sure if I do!) it's that I don't appreciate my reliable computing setup breaking just because some young developer decided the programs I use are "too old".

Post reply on HN