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

171–180 of 250 posts

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

#171

Post by marcodiego »

DonHopkins wrote: post #76

https://donhopkins.medium.com/the-x-windows-disaster-128d398... >As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics…

Hi DonHopkins!

Would you mind to share your opinion on Wayland with us?

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

#172

Post by md8z »

wander_homer wrote: post #138
arein3 wrote: post #78

Earlier quoted context omitted.

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.

Not really, you will probably have to deal with this any time you connect your laptop to a projector.

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

#173

Post by md8z »

vidarh wrote: post #151
qwerty456127 wrote: post #139

Earlier quoted context omitted.

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

Because Xorg is a huge beast with plenty of legacy, and it's also not a very fun project to hack on because it's largely maintenance of stuff people only care about when it breaks. E.g. support for a bunch of backends of which most are not worth supporting if you want to implement a server from scratch, but which Xorg has been saddled with, as well as support for a bunch of legacy X functionality that nobody would bo…

I really don't understand this line of thinking or what you are trying to accomplish. If you are dropping things from the X protocol to the point where it's only XInput2.2, SHM and DRI3, and then farming the rest out to Xephyr, then it's no longer X anymore. That is pretty much entirely what Wayland already is. So you might as well just build it as a Wayland server and call it a day.

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

#174

Post by marcodiego »

pantalaimon wrote: post #90
Seirdy wrote: post #42

Earlier quoted context omitted.

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

There are a lot of smaller projects that lack the resources for the Wayland transition. I'm a happy Mate user and while there is ongoing work to move towards Wayland, it will likely take several years to complete. So for the time being I keep X11 dear to my heart, and to be honest I'm not sure what I'm missing with Wayland (expert apparently problems with screen sharing applications that have not been updated to Wayl…

I think most smaller project will transition automatically once their widget toolkit is ported. For the cases where this does not happens, xwayland is working well enough.

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

#175

Post by Izkata »

perth wrote: post #39
jcelerier wrote: post #32

Earlier quoted context omitted.

Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt

Try to set two different DPIs in that.

I don't have a second monitor right now to double check, but I have this in a script for our office monitors to get a different dpi for one display (named eDP-1):

  xrandr --dpi 100/eDP-1

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

#176

Post by Seirdy »

qwerty456127 wrote: post #132
Seirdy wrote: post #86

Earlier quoted context omitted.

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

There are...a lot of good reasons to keep the mitigations enabled. All nontrivial software has bugs, and hardening measures can keep some of the worst ones in check. Frankly, the Linux desktop needs more of this, not less.

That being said, one writeup explained how disabling several mitigations improved http server perf by several factors: https://talawah.io/blog/extreme-http-performance-tuning-one-...

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

#177

Post by md8z »

yjftsjthsd-h wrote: post #164
DonHopkins wrote: post #140

Earlier quoted context omitted.

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

> 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 Then Wayland will be more a nightmare still, since they moved everything but core rendering into extensions and say "just use wlroots" to deal with it.

No, you have it mixed up. Wlroots is on the server, the Xlib problem is explicitly with client libraries.

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

#178

Post by md8z »

sprash wrote: post #150
bitwize wrote: post #145

Earlier quoted context omitted.

Your toolkit should abstract all that away. We have these wonderful things called dynamic libraries, that X was designed for a world without because they didn't exist under Unix yet.

If toolkits can "abstract that away" they can do the same on X11 and there is even less reason for Wayland to exist. There is no reason for you to even care about X11/Wayland if you only work with toolkits. So stop participating in a discussion that doesn't concern you.

"they can do the same on X11 and there is even less reason for Wayland to exist."

Well actually it's the reverse: the more abstractions were put into toolkits, the more it became obvious that there was little reason to use everything in X11.

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

#179

Post by hollerith »

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…

You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland. (Those apps use something called XWayland, which is blurry if the user has configured a non-standard size for things.) 99.9% of fonts these days, most icons provided by the OS, and most other graphical elements (e.g., rounded corners) are specified as mathematical descriptions of curves that can be rendered at the display's native resolution regardless of what size the user chooses them to be. (I believe the 0.1% of fonts that are not mathematical descriptions of curves are called bitmap fonts.)

Note that I am not talking about multiple displays, but rather a single display, but the user wants things to be bigger than they are by default.

I know this because have used all 3 major operating systems recently (MacOS, Windows 10 and Linux/Gnome) on plain-old 96-DPI monitors such that if there were any interpolation or scaling algorithm I would be able to see the effects.

On a monitor 1680 pixels wide, Gnome gives me a choice of the scaling factors 100%, 125%, 150%, 175% and 200%. On a monitor 1920 pixels wide, Windows 10 gives me a choice of the scaling factors 100%, 125%, 150% and 175%. Some apps are blurry as hell, but on both Windows and Gnome I was able to live my life using only those apps that don't have the blurriness problem, but then I am not forced to use old Windows apps provided or specified by my employer and don't need to share my screen (which I am told does not work yet on a pure-Wayland set-up like mine).

On Windows 10, I used Google Chrome, some apps such as Settings and Timer provided as part of the OS and VS Code. On Linux I used (and continue to use) Google Chrome, modern Gnome apps and Emacs. On Linux, I need to open Chrome with specific flags to get it to be non-blurry while the visual elements are a non-standard size, and I need an Emacs built from a git branch called feature/pgtk. Both apps have some bugs when used in this way, but the bugs are definitely live-with-able, and I expect the bugs to be fixed eventually.

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

#180

Post by md8z »

wing-_-nuts wrote: post #152
bitwize wrote: post #143

Earlier quoted context omitted.

When your solution to "make something secure" is to isolate instances of it in airtight sandboxes, IT IS NOT SECURE. Theoretically Xorg can be made fully secure: just isolate clients so they can only receive events and bitmap information from windows created on the same client connection. It would be relatively straightforward, if quite involved, to implement. But nobody wants to implement it because everyone qualifi…

>So just... shut up with the irrelevant bullshit and use Wayland There are still, to this day, tons of features which end consumers rely on that are still unsupported out of the box with wayland. If you're writing a replacement for x, it had damned well better have feature parity with x. Saying 'shut up and switch' is not an argument for switching. Also, this sort of attitude is precisely why linux never took off on…

I don't agree with the GP comment's attitude but if you could mention those features then maybe someone can help you, they probably exist in some form.
Post reply on HN