[loxias]

> 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 of people wanting to replace things simply because they are old.

[perth]

Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland.

Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work

Some relevant links for those curious about other people hitting into this:

https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi...

Gnome team:

https://wiki.gnome.org/Initiatives/Wayland/XWayland

[jcelerier]

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

[DonHopkins]

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”

>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.

[perth]

Try to set two different DPIs in that.

[AshamedCaptain]

You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.

[hulitu]

Why does QT needs to be smarter ? Just asking.

[jcelerier]

Qt runs on platforms where there is literally only a kernel + the Qt app running, through for instance EGL for rendering. So it has to have its own way.

[Izkata]

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

[kaba0]

That’s for a single monitor. Now try two monitors with different DPIs

[sprash]

The final "composing" step in Wayland does require Wayland to use a "giant" buffer as well. Also My GPU has 16 GB of GDDR how can any frame buffer be "giant" in that context?

The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.

[md8z]

You really don't want to use Xrandr information to do scaling, it's not accurate. A better way would be to set a property on the window and have the compositor read that, AFAIK this is the solution that the Kwin developers were working on.

[loxias]

What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow.

One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors.

Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...

[perth]

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 that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.

[enriquto]

> 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 checkerboard pattern that tingles the monitor refresh rate remains so. This sounds like perfectly appropriate behavior, and anything else would be ridiculously inappropriate. I accept that this usage of "appropriateness" is subjective to a subset of people that includes me, but it may not be universal.

Whatever, this is such a thin point for Wayland: hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. But hey! you can combine monitors of different pixel size as if they had the same pixel size! See, the thing transparently re-scales your windows using cheap-ass bilinear interpolation so that they get the exact same size in millimeters! Fancy, isn't it?

No. It's creepy.

[Seirdy]

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

[loxias]

> barely any current distros still ship X in their default installations.

Bold statement. Citation needed? Debian does, and that's hardly a small percentage of market share. I guess if you include Android as a Linux distribution then you might be correct.

[loxias]

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

I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal.

Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone.

It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)

[hollerith]

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.

[enriquto]

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

This can be true only if you use a really narrow definition of "apps adapted for Wayland". For example, a viewer of png files may not be possible to adapt to wayland? A png file is just an array of pixels (typically without a meaningful dpi). How are you going to ever display it without interpolating and resampling?

[perth]

Yeah. I suppose this functionality isn't everyone's cup of tea. The cool thing about Wayland though is somehow it makes the windows still look crisp and good while making them the same size. With the canonical hack to xorg, they always looked blurry and gross. The gnome wiki had this to say on it:

"On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor."

So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.

[destructionator]

> So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.

X also supports exactly this. Qt uses this information. gtk doesn't for whatever reason, forcing the workarounds.

Most the so-called "X limitations" are actually just toolkit bugs if you get into the weeds.

[danachow]

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.

[loxias]

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

[kaba0]

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

[hulitu]

Basically it is the same for Win 10. It insists on using small fonts on my laptop so i have to scale it. In the golden age you could tell X the size of your screen.

[ch_123]

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

[loxias]

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!

[hulitu]

This link shows what is the problem with SW development, not with X . The same thing is done also in QT or GTK. Why a program written for QT4 cannot compile in QT5 ? Why every library release must be incompatible with the predecessor ? I was able to compile and run X10 programs in X11. Why do i need to have on my linux system more than one version of a library ? Will Wayland fix that, because from this article I see that it is more or less in the same mess of incompatible libraries ?

[II2II]

I have been using Linux for over 25 years. I am not going to shed any tears over the loss of X, though I am concerned that some edge cases will be missed in the transition to Wayland or XWayland. The latter is why I am holding off on switching. Let others figure out and fix those edge cases for me.

As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.

[sprash]

> I have always seen X as complex.

True, but don't assume Wayland to be less complex [1]. It has a lot less features, sure.

1.: https://wayland.app/protocols/

[blacklion]

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.

[microtonal]

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

https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...

See also:

https://www.phoronix.com/scan.php?page=news_item&px=XServer-...

[Macha]

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

[loxias]

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.

[Seirdy]

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.

[destructionator]

> The biggest reason is security. X offers no GUI isolation.

This is completely false. X offers both nesting for full isolation and a concept of "untrusted" connections for partial isolation. This is the reason why ssh -Y and ssh -X are separate things.

These facilities could use a little love to make them user friendly, etc., but they're there and have been for ages (enabled by default around 2013, present before then).

X also supports advanced mixed DPI, providing all the information to the application to handle it as they see fit.

[md8z]

I'm really disappointed to see this get mentioned in this context, it's not relevant. At least on debian, ssh -Y and ssh -X has done the same thing since like 2013 because ssh -X is broken and causes clients to crash. The "sandboxing" there doesn't really work. And it's a lot more than a little love that they need to get them working, the whole reason Xephyr sandboxing exists is because Xsecurity and XACE are so broken that it's unusable. You can see more about this in another comment here: https://news.ycombinator.com/item?id=29092612

[yyyk]

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.

[Seirdy]

> Zero cases in the wild

Follow along this post and you'll end up with one case in the wild all by yourself on your own machine: https://theinvisiblethings.blogspot.com/2011/04/linux-securi...

Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...

[wing-_-nuts]

I read the article, I'm still not clear on why it's a problem. I'd have a very big problem if another user, using my machine via x forwarding, could capture my inputs, but that doesn't seem to be the case here? It seems that this is only for applications running on the same display.

So, to be blunt, this 'security feature' breaks a whole hell of a lot of use cases. If wayland wished to go down this route they should have displayed a prompt to the end user 'this application wishes to record the screen, that ok?'. The last time I made this point someone snidely informed me that 'this was not wayland's responsibility'. I'm sorry, if you break my use case you make it your responsibility!

[md8z]

That is exactly what will happen on a Wayland when you use the portal API, it shows a prompt asking for permission to record your screen and then it sends the stream over pipewire.

It is true that it isn't strictly the responsibility of the Wayland protocol, the API functionality is still there just it has moved somewhere else where it's more appropriate.

[yyyk]

>>Zero cases in the wild

>Follow along this post and you'll end up with one case in the wild all by yourself on your own machine

I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter.

Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on.

Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.

[kaba0]

There are so many holes in linux’s userspace’s “security” that we should start listing the actually protected parts. The only reason there are no linux botnets everywhere is because libre software fundamentally have good intentions.

So the reason for not exploiting X may very well be simply because there is an even easier exploit available..

[RedShift1]

> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.

This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.

[kaba0]

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

[loxias]

> 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 them, and about half of my peers do as well.

The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature.

> you can’t have displays with different DPIs

This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy.

What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals).

Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well. Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way.

And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.

[kaba0]

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

[loxias]

> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor.

Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a bit of tear. But.. I don't do that. Most of the time if I'm watching a video it's full screen. It looks perfect.

I bet the tearing you've seen using Xorg is attributable to something else. I remember back when video kinda sucked (in anything other than mplayer) but that was years ago. I have a windowed Netflix playing video as I type this and nope, no tearing. shrug I see in the Xorg.0.log that the COMPOSITE extension is loaded, but I'm not running a compositing WM, nor am I running a stand alone compositor.

I think we can put this "Xorg video playback has tearing" myth to bed.

It was certainly true back when suspend and resume didn't always work right, but that was quite some time ago. Having read much about Wayland in the last few hours, I think a more accurate thing to say would be "In Wayland, there is never any tearing. In Xorg, you can have tearing under some conditions" There are some very compelling reasons to be interested in Wayland that don't require exaggerating Xorg's failings. :)

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

I think we have a different definition of "handle", and I apologize in advance for semantic pedantry. I'm looking at 3 screens right now, one of them is a 14" "4kish" (3200x1800). Xorg "handles" it just fine. As I drag a window to the highest resolution screen (which I have in portrait orientation and use basically only for coding), the content appears exactly as I expect it to. That monitor has a higher DPI, which means the pixels are a different size. It's not a bug... it's expected and desired behavior. Dots Per Inch. It's right in the name! If some software in the display stack was interpolating everything, making my text look fuzzy, now that would be a serious bug to me!

I really really think what you mean to say is "Xorg doesn't support rendering things in terms of physical size regardless of the underlying resolution." That might be true. Pleaseeeee say that instead. :) Personally, I wouldn't use that feature but I can imagine one desiring it.

But... when you say "X can't have displays with different DPIs" ... I mean this with no offense, but... you sound less intelligent than I'm sure you are. Because I can plainly see multiple displays with different DPIs right in front of my face. :) Xorg has been able to "handle" multiple displays since Xinerama, IIRC.

Anyway, I'm encouraged to take Wayland out for a spin for a reasons not mentioned in this comment thread. I like minimalism. :)

[md8z]

The reason you don't see any tearing is probably because video players under X have gotten better about "guessing" when the frame is supposed to be displayed. The knowledge to do that has accumulated over the last 30 years and it's a pile of hacks, and it's still possible for them to tear under various circumstances because X is still fundamentally an unsychronized protocol (unless you use a compositor with frame sync).

[md8z]

"This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy."

Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...

[loxias]

> ... "correctly" ...

You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective. To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen.

I will (grudgingly!) concede that perhaps it's not "universally and obviously correct" that things stay the same number of pixels, if you concede that perhaps it's not "universally and obviously correct" for windows to be drawn in terms of points and scaled behind the scenes.

[md8z]

We don't though, I mean if you explicitly change the scaling factor. Of course if you don't change the scaling factor then your scaling would technically be correct.

[destructionator]

> Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...

No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).

[md8z]

Yeah you do if you want to have the same window span across monitors. And if you have non-integer DPI scaling then things will probably always be either blurry or inaccurate, that is unavoidable.

[RedShift1]

Why can't the new display server just re-implement the X protocol? The implementation could leave out the unused parts.

[kaba0]

It does, it’s called XWayland. So almost all functionality of “legacy” programs will continue to function under Wayland.

[mcguire]

That word "almost" has me worried.

[destructionator]

This post is completely false. Literally every word of it is false.

[kaba0]

GPUs don’t have a single start, at least it depends on how you define them, but arguibly the first generally available one came in the late 1990s, compared to the various X server implementations that were around before that as well.

About its current role, there is a famous talk by an ex-Xorg developer that explains it well. Very crudely, a wayland compositor relays events to applications, which signals when it’s ready. Xorg on the other hand does these as well, but sits between the compositor and the clients, relaying their messages with some delay (and not having a concept of every frame is perfect)

Xorg doesn’t have support for mixed-DPI monitors, as it renders to all screens simultaneously with a single DPI setting. This is pretty much unfixable, it is so inside the core of the whole thing.

And finally, Xwayland exists and it is backwards compatible to the most part (other than manipulating wayland clients as if they were x ones, but that is also a wanted “functionality”). These are pretty much just nested x servers, so I don’t see how is it false?

[destructionator]

X has had its OpenGL extension available since 1992. Your argument is like saying "Windows 1.0 came out before Direct X even existed, so of course you can't play modern games on Windows 10". As new things came out, they added support for it.

Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says "the X server only talks to the compositor" I'm like "lol what compositor".

But even if you have one, it is still wrong. You have to understand that GUI applications are a LOT more than just low-level rendering. So even if you didn't need it for that, there's so much more going on that the server still plays its role in like coordinating copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc.

And it isn't true that everything goes through the middle man. A graphics-heavy X application actually tends to work very similarly to a Wayland application (not coincidentally - as people love to point out, a bunch of the Wayland devs worked on the gpu rendering parts of X before): you get a direct render context, write to a buffer, then inform it to draw it. See more https://keithp.com/blogs/dri3_extension/

Mixed DPI is fully supported by the system, but may be buggy in applications. See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality, or do auto-scaling for easy support bridges. KDE and Qt manage to do it. So much for "unfixable".

[md8z]

"Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says 'the X server only talks to the compositor' I'm like 'lol what compositor'."

Can't you see how this is self-fulfilling though? People don't use X compositors because they suck and cause issues, so then you have people saying they don't use it because it doesn't add value. Well, yeah, compositing in X is bad and really convoluted and causes issues because X is not built for that, that's why they had to make Wayland to fix it.

"copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc."

The first two, yes, the rest of it not so much. The X server is quite bad when it comes to managing hotkeys or notifications or doing any of that stuff not related to window management and input, most of those uses have been replaced with D-Bus.

"A graphics-heavy X application actually tends to work very similarly to a Wayland application"

Yeah, using extensions that were made way after X was designed.

"See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality"

This article goes around every so often and every time it does, I have to point it out: Randr is not enough information to do mixed DPI. There is a reason the suggestions in that article have not been taken seriously. See this MR if you want more info on what actually needs to be done in the server to get this to work: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

It's for Xwayland but similar things need to be done if you want it to work correctly on the Xf86 hw. And also, you would still need a compositor for this.

[Hendrikto]

> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.

Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.

Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...

[toast0]

> Systemd is neither unnecessary nor stupid.

I'm living a pretty good life without systemd, so it's clearly not necessary. I'm sort of willing to acknowledge that it fits some people's needs better than alternatives however.

systemd doesn't have the ability to cancel tasks from the console like other init systems do, for example when my laptop can't get a DHCP response from the network card that's not plugged in, so it's clearly stupid (and so is the init script or whatever it's called that's trying to get an answer from a not plugged in NIC, but that's a separate although related issue).

[Hendrikto]

> systemd doesn't have the ability to cancel tasks from the console

Yes, it does… not sure what you are talking about.

[toast0]

On other init systems, if you hit ^C it cancels the current task. On the one systemd machine that I used, ^C did nothing while waiting for DHCP, and no gettys had started yet either, so as far as I could tell, there was no way to get the system to respond other than wait for the timeout (minutes) or reboot and maybe reconfigure in single user mode.

[yjftsjthsd-h]

> And I am sure, if you really think about it, you know this yourself.

I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.

[md8z]

Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?

[yjftsjthsd-h]

I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most common uses (because, honestly, the most common cases are covered by anything), but it also introduced pain points for even non-esoteric cases (I've personally witnessed systemd getting stuck in fascinating nondeterministic ways more than sysv).

[md8z]

That doesn't seem to be what most Linux distributions were thinking around 10 years ago when the upstart/systemd/openrc/etc arguments started happening. The general consensus seemed to be that sysvinit needed to be replaced, or at the very least it needed to have a ton of other scaffolding on top of it in order to make it keep working.

Sysvinit never got stuck in those cases because it never had service dependencies and thus never needed to have a constraint solver for the dependency graph... So could you honestly say that pain point was better?

[loxias]

You didn't ask, but I think that:

>Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.

Was bad faith, naive, and frankly... insulting -- so I just chose to ignore it.

My reservations are well grounded, and when ones concerns are echoed by ESR, Linus, and tytso, I don't think they can be dismissed so easily.

Certainly some people wanted features that sysvinit couldn't provide, obviously, because so much effort went into systemd. But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)

I'm still using sysvinit on my main machine, and on all "critical" servers not because I have an advanced use case requiring a specialized init system but because I have a simple use case and a computing philosophy that requires simple init system. I have a strong (I'll admit, borderline fanatic) affinity for the "unix philosophy" of accomplishing things through the composition of simple to understand and debug tools that do one thing, and do it well.

To me, SystemD is about as far as you can get from "do one thing, and do it well" and "simple to understand and debug". It's a monolith (right?) which is why it's not running directly on the hardware. Unfortunately, Debian now builds some packages that I use occasionally with SystemD specified during the configure stage, and I don't want to maintain my own packaging of tools with different compile flags, at least not yet. Presently, I solve this by having a separate VM for "all tasks that need systemd", but I hope to replace that with something lighter weight, perhaps containers instead.

SystemD provides some features I imagine most users want, and that I strongly see the benefit of, but for the vast majority of those features, those reasons I'd want to use systemd, I'd already solved it myself, through the composition of existing and simple tools. A good example is networking. My computer does exactly what I want it to do, every time, in all permutations of wireless, wired ethernet, wireguard, knowing to mount certain NFS shares when I'm at home, randomizing mac address in certain situations, knowing when &c. It's great functionality, and I got there over time by building simple and easy to debug shell scripts, which call out to tools like `ip`, `iw`, `wpa_supplicant` and reading from /sys/class/net.

I also don't use pulseaudio, as audio happens to be one of the subsystems I have strong experience with, and pulse is an unnecessary (and sometimes error prone) layer, considering I get along just fine with ALSA.

The one thing I'm jealous of is faster boot times. But I'll happily boot a few seconds slower in exchange for PID 1 being simple, and my other services being simple and hence easy to debug.

[md8z]

I don't understand why this philosophy discussion seems to get brought up so frequently or why anyone needs to care about philosophy in the context of a computer program. Linux distributions that adopted it are not sitting around pondering the meaning of life or the existential nature of what it means to boot a computer, they were using it to solve a real problem that they had. It was a complex problem, it was not a simple problem that could have been solved with a simple solution. So what you are saying is not really related to the question.

I don't think the opinions of ESR, Linus, and tytso are relevant here either as none of those people work on init systems. If you developed your own solutions with shell scripts, that's great for you, but I hope you can see how that doesn't work at scale in a big distribution. BTW systemd includes a lightweight implementation of containers so I also don't understand what you're talking about when you said you needed to then put it in a VM or container. The exact problem you're having can also be solved... by just using systemd. So it actually seems like you're making things more complex than it needs to be by jumping through hoops to avoid it.

Audio is also my expertise, and using just ALSA is an experience in pain. You need some kind of userspace daemon in order to get a good experience with that.

[kaba0]

Booting is simply a complex problem. The complexity simply lives with your shell scripts instead, which is imo a much uglier and less maintainable solution for most use-cases.

Also, does your system do logging before the file systems are mounted?

[Hendrikto]

> But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)

Sure, but systemd has quickly been adopted by the experts, namely the maintainers of every mainstream distribution. The people who maintain all of that infrastructure think it is much better than what we had before. That does say something about its quality.

> It's a monolith (right?)

That‘s a common misconception. You don‘t have to use all of systemd. And I am not talking about all of systemd, just the init system.

That also invalidates your point regarding networking, btw. You could keep using your setup with systemd.