Gnome developer proposes removing the X11 session
theregister.comGNOME (and many others) have spent years telling anyone who has issues with Wayland that lead them to run an X session to report bugs, and has put a lot of effort into fixing those bugs. This seems like a reasonable next step.
> This plan seems to The Reg's FOSS Desk to be strong-arming people into adopting Wayland.
Or, more reasonably, to maintain less code for alternate paths in favor of fixing the issues that lead people to use those alternate paths.
Wayland has bugs. X has bugs. Fixes to one largely don't help users of the other. Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place. A project taking a step like this allows it to consolidate those efforts.
Yup. I think consumers of FOSS rarely understand the amount of effort that goes into maintaining code, whether that is keeping the test infrastructure up to date, fixing bugs, or adding new features.
In many cases, a large codebase like GNOME will undoubtedly have huge swaths of unmaintained code that doesn't have good test coverage and corresponds to rarely used features of the software. It also becomes a frustrating game of whack-a-mole when attempting to fix bugs in software with inadequate test coverage.
Another infrequently acknowledged point: writing tests isn't simple, it requires you to have thorough understanding of all the moving parts involved. If the current maintainers do not understand the architecture in some obscure corner of the software, then there is a significant upfront cost to expanding existing tests around that code -- time that can be spent improving frequently used parts of the software.
When nobody steps up for maintenance despite welcoming patches and calling for new maintainers, there is simply no reasonable option besides "remove this unmaintained source of bugs that none of the maintainers know how to properly test"
Exactly. Given the nature of Open Source, anyone is free to fork something and say "I'm going to keep maintaining the old thing forever". But that's often not feasible solely with the handful of people and energy of those people interested in a given older technology, especially in a world in which people expect pieces of the ecosystem to cooperate and interoperate with each other.
So, instead, the standard tactics are to 1) push people and projects to maintain the old thing for them as long as possible, 2) treat any new technology that doesn't give you free support as a threat, and respond to it with fear, disparaging and attacking the people and projects who are no longer willing to maintain the old thing forever, trying to rally others to pressure them, and 3) disparage and attack technologies that require integration/cooperation between projects, because it raises the bar for the amount of maintenance effort expected.
New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.
> New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.
Not just new projects. Existing projects can do with a clearer roadmap in my opinion. "Gnome 48 will drop X11" is easier to communicate than a merge request titled "session: Remove x11 session targets".
Except for the guy who tried to do that with Python2 and the Python Foundation threatened legal action
When did they do that? All I can find is the Python foundation protecting their trademark. Someone launched "Python 2.8" without any affiliation to the Python Foundation, that's a silly move. Surely everyone in open source learned from the Iceweasel debacle.
Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7, though I don't see many contributors to that fork.
> without any affiliation to the Python Foundation
Sorry, no dice. The Python team said for years as the 2 to 3 rollout grew increasingly catastrophic "If you wan't to keep Python 2 all you have to do is maintain it" and then threatened to sue the guy who called their bluff. It was a real low point in free software.
This guy wasn't maintaining Python, he as creating a new version incompatible with either Python 2.7 or Python 3.
Red Hat and other large companies have maintained Python for years after 2.7 died (EOL date was January 1st, 2020). IBM/Red Hat offer Python 2.7 including security fixes and bug fixes until 2024 (https://access.redhat.com/solutions/4455511).
Had he just provided patches to Python 2.7, nobody would've batted an eye. Instead, they created an alternative language that was completely different (https://web.archive.org/web/20161210161837/https://www.nafta...).
Founders and core devs indicated that the name was the only problem (https://github.com/naftaliharris/tauthon/issues/47#issuecomm...) and that even things like the header file names could continue to be named Python because of API compatibility.
You can fork any open source project you like, but you still need to stick follow trademark law. You can't just release Linux 2.7 because you disagree with breaking changes in 3.0 either, but you're free to take the Linux code and release Twonux if you really care.
After reading your first link I'm having a very hard time understanding how it's a "new version incompatible with either Python 2.7 or Python 3" or how you can think "they created an alternative language that was completely different" is true in any sense.
> Python 2.8 is a backwards-compatible Python interpreter that runs Python 2 code and C-extensions exactly as-is, while also allowing Python 2 programmers to use the most exciting new language features from Python 3.
Really sounds like Python 2.8 to me!
> Really sounds like Python 2.8 to me!
That's the problem, isn't it? Nobody who works on Python actually worked on this fork, but it sounds and looks official. That's why the Python Foundation people found this troublesome enough to demand a rename.
Tauthnon has lots of additions to normal Python, most stemming from a bunch of PEPs that author liked. You can't run Tauthon code on any Python interpreter (either 2.7 or 3.x), and there are a few edge case incompatibilities as well. It's probably a great interpreter for those who want newer features but are still stuck with Python 2.7 for whatever reason.
That's begging the question, because the guy who picked up the codebase they abandoned was absolutely "working on Python" in any normal sense of the word. The people who used to work on Python stopped working on it to make a new language which they also wanted to call Python.
> Someone launched "Python 2.8" without any affiliation to the Python Foundation, that's a silly move. […]
> Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7
I was curious and did a search for Python 2.8 and found:
- https://news.ycombinator.com/item?id=13144713
- https://news.ycombinator.com/item?id=13159144
Clicking on the GitHub repo it seems that in fact the project making unauthorised use of the name “Python 2.8” was the one that ended up changing its name to Tauthon. Neat!
Also "without any affiliation" is a stretch. He picked up a codebase they abandoned and they got pissy because he kept its name. It was really not a good look.
This is more than a little ironic since Python stole its name from a British comedy show.
Monty Python didn't register Python as a name for computer software was far as I know. Nobody was going to confuse the two.
Releasing Python 2.8 would definitely confuse people.
What would be the confusion? It’s a continuation of a language interpreter compatible with the dialect known as Python2.
Renaming it is more confusing!
"Python 2.8" implies it's the One True Continuation of Python 2.7, as opposed to someone's random fork.
Is there another continuation of Python 2.7 you know of?
He literally took over an abandoned codebase, and got sued for calling it the codebase's name.
You can't release new code that is incompatible with Python and call it Python if you have not been allowed to do so by the Python Software Foundation. It's like, basic trademark law.
I did in fact find it confusing that a very different language was released under the name "Python 3". They probably should have picked a new name rather than capitalizing on the original language's popularity to push their new idea.
My impression though is that for enough people, the wayland code doesn't exist (see this comment from a GIMP dev on the aforementioned MRs for example: https://gitlab.gnome.org/GNOME/gnome-session/-/merge_request...). It's one thing to choose between different buggy behaviour, it's another when the new way does not allow you to do your job.
> Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place.
What fraction is that? I thought X still had the larger user share.
To answer my own question: 70% of Linux gamers use X. Definitely not a small fraction.
They don't care about user shares. Why would they?
It's not just about bugs. It's also about functionality X has that Wayland won't.
If the article is still correct, and Wayland doesn't work with the Nvidia binary drivers then that's a hard blocker for at least myself. :/
That being said, I'm still using Ubuntu 20.04 LTS on my desktop as I prefer stable systems. That way I can put time into the things I'm interested in more. :)
So, as long as it all works nicely by the time I need to change from Ubuntu 20.04, then I likely won't particularly care if it's wayland or X underneath.
It works perfectly fine on Debian testing (in fact the X session developed show-stopper bugs that forced me to use Wayland), so it should be on Ubuntu soon.
Cool, thanks. :)
As someone who used to be a diehard Linux user and supporter, and then switched back to windows after about a decade, this thread is a good reminder of why I switched back. I've been hearing about the year of the Linux desktop for... Years... And yet here are people who suggest I should put up with an incomplete, partially broken display server, because they don't want to deal with maintenance of the old one. And in this thread, any complaint by real users who are missing features or have encountered bugs is met with a dismissal.
You know what? The equivalent of X11 in windows may be full of cruft, technical debt, poorly thought out / "unelegant" design decisions... But it fucking works. I'm sorry, but I have other things to do than dealing with the constant churn of Linux desktop software.
I remember a decade ago when everyone was supposed to switch to pulseaudio, it was the greatest thing since sliced bread, its design was solid and future proof. Migrating from alsa did break everything and was a PITA. And alsa was still there! The fix for many problems was to configure something in the venerable alsamixer. Now apparently we need to migrate to pipewire. All I know is that upgrading broke my rpi4. I don't care about the software, I just want my htpc to play a video with sound when I get back from work. I still had to run alsamixer and flip a few knobs to get it to work again. This is madness.
> You know what? The equivalent of X11 in windows may be full of cruft, technical debt, poorly thought out / "unelegant" design decisions... But it fucking works. I'm sorry, but I have other things to do than dealing with the constant churn of Linux desktop software.
It's funny because it's the opposite.
On Windows, you can install and update the graphics drivers without restarting, and it can ever seamlessly recover from a GPU crash.
On Linux, you need to update the whole kernel, and if the GPU or the driver crashes, you'll kernel panic.
On the compositor side, on Windows you can easily have multimonitor setups with different fractional DPIs, different refresh rates (including variable refresh rate), mix of HDR and SDR, applications without vsync and so on. On linux, even single monitor HDR is unsupported.
X11 also just "fucking works", and this is article is about a proposal to remove it from GNOME.
GNOME is the DE equivalent of North Korea. It's like hearing about North Korea contemplating removing the right to wear clothes and going, "I left Earth a decade ago, and this is a good reminder of why I haven't come back." :p
X11 will still be supported by sane (desktop) DEs for as long as Linux will still be in use, is my guess. (Just like window minimization and non-rounded corners and system trays and disabling composition and...)
> Now apparently we need to migrate to pipewire.
I don't even think I'm on pipewire. Using Arch, you can run anything you want; no ones forcing you to do anything. ;D
> X11 will still be supported by sane (desktop) DEs for as long as Linux will still be in use, is my guess. (Just like window minimization and non-rounded corners and system trays and disabling composition and...)
Not if they remove X from gtk+ too. That is the logical next step.
I am using wayland since 5 years and never looked back to X11. I think it is the right way and time to remove the old insecure X11 backend. GNOME should not be bloated with legacy stuff.
Your experience is not universal. On an intel cpu/gpu laptop, I have zero issues.
But on an AMD/Nvidia desktop it's unusable because it's buggy as all hell. It's endless glitches in dozens of applications. At first it appears fine and then you get subtle stuff like like letters not appearing in vscode when you type, OBS won't record etc.
I have experience with all three manufacturers. We deploy them at work and the integrated AMD GPUs work just as good as the Intel systems. However I can't say much about the discrete AMD GPUs or older hardware. Just yesterday I changed one nvidia system to the proprietary Wayland driver and started gnome with a three monitor setup. Works like a charm.
Then I don't understand why people blame about Wayland about this on its entirety.
Wayland is no way ready
- O proper screen recording support
- broken screen sharing
- No proper global keyboard shortcut
- No push to talk support
- Their developers are seriously crazy on their design decisions.
- Several problems with multiple screens
> proper screen recording support
> broken screen sharing
Both work perfectly here with pipewire installed. I can do screen recording, and share my screen in video meetings in Firefox.
> No proper global keyboard shortcut
System-wide keyboard shortcuts already work, through the desktop. The ability for an arbitrary application to request a global keybinding is in progress and expected to become available soon.
> No push to talk support
Completely valid; that's the near-future global keybinding support mentioned in the previous point.
> Several problems with multiple screens
Such as? Reported bug URLs?
For the record, there are other known issues with Wayland, and they're being worked on; nobody's claiming Wayland is perfect at this point, just that the solution is to fix it rather than assuming it's doomed because it doesn't do some specific thing.
> A proper refactor of X11 should have been the way to go and there should had been X12 with modern technologies
Wayland is X12; it's designed and endorsed by the folks who worked on X11.
So, basic functionality is still not there 15 years after release.
And I believe gnome still has that thing where if the UI lags, the cursor lags.
Windows DWM, WDDM architecture, and anything graphics related on Windows is superior in so many ways. They should have copied that instead of the mess that Wayland is, which was developed in a manner that is typical for so many free software: the developers think they know better than the users about what features they need or don't need
> So, basic functionality is still not there 15 years after release.
X11 didn't have what we currently consider "basic functionality" for decades after its release.
The design of X11 says that every application connected to your display is completely trusted, hence why it can grab any key (and thus be a keylogger if it wants to be). The design of Wayland starts with the premise that every application connecting to your display might not be completely trusted, and thus has to ask for a global key shortcut. That makes some things harder, requiring the design of a protocol for such requests. It also makes it possible to have sandboxed applications. That seems like a tradeoff worth making.
> The design of Wayland starts with the premise that every application connecting to your display might not be completely trusted,
What a strange premise... Do the wayland people have keylocks on all the rooms, drawers and cupboards on their houses?
Unix programs by default have access to all files in the user home. That's the main point of running programs after all: to edit your files. Letting these programs see all pixels in you screen does not seem that bad, does it?
If for some reason you want to run an untrusted application, use a container. But building your whole house around the "untrusted" premise sounds ridiculous.
> If for some reason you want to run an untrusted application, use a container. But building your whole house around the "untrusted" premise sounds ridiculous.
I guess we should do away with memory protection as well. Filesystem permissions? Bah, they can go too, after all, a computer is generally used by a single person right?
The reality is that many users use untrusted applications that don't have access to home, ergo Flatpak. There are plenty of reasons why the free for all security model for X11 isn't suitable. Besides, that ship has well and truly sailed - most of the X11 devs have been working on Wayland for the better part of a decade now.
> The reality is that many users use untrusted applications that don't have access to home, ergo Flatpak.
I'd like to see this quantified. How many people using flatpack are afraid of their application reading their files, vs using flatpack simply because it's a convenient way to install programs? I don't mean "oh me me!" responses, are there any user surveys to support the premise that average users are afraid of their applications?
Quite frankly I don't believe this level of paranoia is the norm. On Windows and MacOS, applications installed in the normal way can read the files on your desktop. This is the way it as always been on Linux too, with few exceptions. Letting the most paranoid users set the norms is a recipe for irrelevance. How popular is Qubes? It's a pain in the ass.
This is incorrect, apps installed through the macOS App Store have required sandboxing since 2012. Since 2018, Microsoft is also attempting to get developers to sandbox more apps, see more about that here: https://news.ycombinator.com/item?id=36059982
I'm pretty sure you're wrong. Looking over the part where you imply that the MacOS App Store is the standard way to install Applications on MacOS (opposed to dragging the application to the Applications folder), let's look at what the system you're referring to actually does:
https://developer.apple.com/documentation/xcode/configuring-...
Show me where it says a program installed from the MacOS appstore will be unable to read the user's files unless the user explicitly authorizes it. Here's how it actually works as far as I can determine: The application developer grants their app the entitlements to read user files. The user may see that entitlement before installing the application, but thinks nothing of it because of course the program operates on their files. This does not protect the user against a malicious program being shipped with those entitlements and a plausible pretext to justify it. Example: The user downloads a program to read some kind of unusual file for work, the program grants itself access to ~/Downloads because of course it needs that, then the program instead reads ~/Downloads/your-tax-documents
This system only protects the user if the application was legitimate, refrained from granting itself the relevant entitlements, then got compromised by an attacker.
>Looking over the part where you imply that the MacOS App Store is the standard way to install Applications on MacOS
That is the standard way. An app that has its own custom installer or patcher/updater is by definition, using a non-standard install procedure.
But even if it wasn't, it definitely is the standard on Linux, where package managers are the norm.
>The application developer grants their app the entitlements to read user files.
Flatpak works in exactly the same way.
It is not a strange premise. It is the security model that for example Android uses. Unix security model is dated, and it is good that steps are taken in this direction.
Android is different, it is built to run untrusted apps.
My Linux Desktop runs Chromium, xterm, IntelliJ and occasionally Gimp.
Do I need the Wayland security model? Hardly so.
Am I an outlier among Linux Desktop users? Hardly so.
Are you actually suggesting that most Linux desktop users only use the same 4 programs you do and will never use or install anything else? If that's the case then why bother with a display server or package managers? We can hardcode those 4 programs into the system, have them draw directly to the framebuffer and then we can remove the ability to install any other programs. Sound good to you?
The point is to reduce the attack surface, especially for browsers that run untrusted input. You don't want a local exploit in your browser (that hopefully is also configured not to have access to your entire filesystem) to screenshot other apps and websites. Maybe you disable all the warnings in IntelliJ too that prompt you to be careful when opening a new Git project from a remote source?
Browsers are already sandboxed.
It has nothing to do with security and everything to do with hollowing out all generic functionality and passing it on to the compositor. In other words, the devs are lazy and went for a minimalist approach and now we all get to suffer.
Wow calling FOSS developers lazy is pretty low.
> X11 didn't have what we currently consider "basic functionality" for decades after its release.
What's the relevance of this? You're position is that we should give up features we have for software that doesn't have them after 15 years of knowing they needed them.
No, my premise is that it takes time to develop features, and what's considered "basic" both changes over time and varies by person.
For instance, I would argue that "basic functionality" today, established by browsers and phones more than 15 years ago, is the ability to sandbox applications and not treat them as all-powerful. X still doesn't have that today. Wayland had that as a basic design premise from the beginning.
> Wayland is X12; it's designed and endorsed by the folks who worked on X11
That would make it a spiritual successor, but not X12.
Considering several comments - and PP's original issues - it also sounds like it isn't ready to become a candidate for X12 at this time.
What about accessibility that needs to emulate mouse and keyboard based on window titles/executable?
> share my screen in video meetings in Firefox.
Yeah, in limited ways, the wayland functionality is there. But as soon as you step off the most-popular-path even a teensy bit, it breaks.
I am relying on Teamviewer for remote desktop access because the official RDP support breaks in a different way with every minor release.
> - O proper screen recording support
Works just fine. I use OBS.
> - broken screen sharing
Never had any trouble with it.
> - No proper global keyboard shortcut
> - No push to talk support
On its way: https://github.com/flatpak/xdg-desktop-portal/pull/711 / https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
> - Several problems with multiple screens
Haven't had any more than on X11, but then again I do use Nvidia hardware on Linux.
OBS is absurd bloat. What's the wayland equivalent of `ffmpeg -f x11grab`?
ctrl + alt + shift + R will record the screen on Gnome, it's built into the shell.
wf-recorder will do Wayland screen recording fromtthe she'll. I don't think anyone has bothered to implement Wayland screen recording in ffmpeg yet, maybe ask the ffmpeg mailing list to check if that's on the roadmap yet.
> [N]O proper screen recording support - broken screen sharing - No proper global keyboard shortcut - Several problems with multiple screens
I thing all these things work flawlessly in my KDE Wayland session.
By the way no more blinking and sound cut (my sound goes through HDMI) when rearranging screens.
I've been very late to make the switch (I did a few months ago because I always saw blocker issues with the wayland session), but now it is at a point it works better than on X11. I miss raising apps when they are called from another app (like calling Kate from the terminal) but I know this is coming soon.
get to work,we're counting on you
Or, users could stay on the perfectly fine X, and anyone who wants to push for Wayland adoption can put in the effort to make it not a regression.
Users are at the mercy of developers. If you want to stay and care about maintenance, you’d better hope someone is there maintaining it.
In that sense they're even more at the mercy of packagers. There's nearly 400 million repositories on Github alone; the pain point is curating those into a coherent system.
Im not sure how many million of those are required to run gnome on x11 though.
To run (let's ignore build deps for now) it needs dconf, desktop-file-utils, glib, schemas, python, ibus (you can disable it but it still has to be there, annoyingly), telepathy, a seat manager, pulse, polkit, eds, mutter, gtk4, and whatever fonts you want. If you want it to display on the local machine you'll need an xserver; as of now each of the apps can simply act as a client though (which is the capability they are discussing getting rid of).
I know this because I'm a packager...
Go for it, I say.
It would be one of many in a long line of backward compatibility missteps they continue to make; and would help shore up my reasons for me to recommend other WMs, as well likely encouraging other developers to bring some of GNOME's good stuff elsewhere.
X can easily support per-display DPI -- clients just have to eschew the legacy global DPI setting. The Xrandr extension knows the dimensions of each display in both pixels and millimeters from its EDID. Clients interested in making adjustments based on per-display DPI could simply use those values obtained from Xrandr. These values can be wrong, of course -- monitors have been known to lie in their EDID reports -- but they'd be wrong in Wayland too.
Of course, no one actually wants to do this work because there is a deep-seated intent to salt the earth where X once stood.
The way multihead works in modern XOrg is basically a hack to enable seamless dragging of windows across physical display boundaries.
Once upon a time you'd do multihead on X with discrete screens and your display environment variable would be something like DISPLAY=:0.0 vs. DISPLAY=:0.1 where the last digit after the dot was the screen number. But your X client would then be confined to that screen. In this old manner you could probably have per-screen DPI stuff work somewhat, but you wouldn't be moving windows across physical monitors like we take for granted today.
Having your X clients connect to DISPLAY=:0 and somewhere behind the scenes that X server is putting its windows across physical displays or moving from one to the other seamlessly is basically Magic (look up XINERAMA) that the protocol is largely ignorant of, so the DPI differences among those physical displays are pretty invisible to the random X client.
IDK if ability to drag a window between screens is something more important than properly supporting different DPIs; but that might be a decent level of ignorance on my part
Eh, I lived with the limitation back in the XFree86 4.0 / beta multihead support days on an array of Matrox Millenium PCI cards.
While it technically works, you quickly discover the importance of being able to organize windows to different physical displays after the programs are already running / the windows have been created.
Requiring exiting and relaunching things to migrate them to different physical screens gets old fast.
The best article I have found about mixed dpi on x11 is.
That article is horrible. What it describes is yet another hack where clients attempt to guess the DPI and then rescale themselves, and the server and compositor know nothing about DPI. That method only exacerbates the problems where clients that don't support scaling are going to be scaled wrong on every screen. Compare this to Wayland where the compositor itself knows the scale of every window and does all the scaling.
Which is a fair assessment, And I think I agree with you. however there is a bit of irony around the whole situation.
The article reaches the conclusion that the best way to handle the situation is for the display server to provide the dpi primitives and let the client figure out how best to draw to that dpi. But acknowledges that there is a hack where you can make the server present a standard scaled dpi, but the drawing will then be bad. And there is this new-fangled thing called wayland where all it can do is the hack.
The irony is that wayland is infamous for usually making the clients do the work(I am thinking window managers) and X for providing a standard method. Nether of which is true, but it made me chuckle.
xrandr is not sufficient for this. One needs a way for users to configure the per monitor DPI. And have the configuration available to X clients. Currently the only cross DE mechanism for this is Xft.dpi and its global, not per monitor.
>Xft.dpi and its global, not per monitor.
It's per screen, though ; you can have different Xresources on different screens bound to different monitors, I'm running such configuration just fine. Actually, since most of the software I'm using is GTK-based, my per-monitor DPI configuration tool(s) are a pair of xsettingsd running with different DISPLAY variables, and having different Xft/DPI values (and a few other tweaks, like different font rendering options). I'm running two openbox instances , xfce4-panel and tint2 , and two picom instances to properly support client side decorations. And I'm trying to scrape some time to patch xfwm4 and xfce4-panel to support per-screen processes for both . This way I'm driving 24" 4K as my primary display, for coding/browsing/etc, and 24" 2K as a sidekick for monitoring/documentation/spotify/etc
My .xsession:
xrdb -screen -display :0.0 -merge .Xresources-0.0 xrdb -screen -display :0.1 -merge .Xresources-0.1 nohup /usr/lib64/xfce4/xfconf/xfconfd & export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0 cff:darkening-parameters=500,500,2000,450,3300,450,4600,200" export DISPLAY=:0.0 export GDK_SCALE=2 export GDK_DPI_SCALE=0.5 export QT_AUTO_SCREEN_SCALE_FACTOR=0 export QT_SCREEN_SCALE_FACTORS=2 nohup xsettingsd -c ~/.xsettingsd-0.0 -s 0 & nohup openbox --config-file ~/.config/openbox/rc-0.0.xml & ~/Apps/Picom/picom --vsync --use-ewmh-active-win --no-frame-pacing --backend glx -b nohup xfce4-panel --display=:0.0 & nohup /usr/lib64/xfce4/notifyd/xfce4-notifyd & export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0" export DISPLAY=:0.1 unset GDK_SCALE unset GDK_DPI_SCALE unset QT_SCREEN_SCALE_FACTORS nohup xsettingsd -c ~/.xsettingsd-0.1 -s 1 & nohup openbox --config-file ~/.config/openbox/rc-0.1.xml & ~/Apps/Picom/picom --vsync --use-ewmh-active-win --no-frame-pacing --backend glx -b nohup tint2 & waitIf this works for you, cool. But this is... not good in any way, and it's still not going to work for clients that use a different toolkit or text renderer than the ones you've configured. I hope you can see how it's unacceptable for an average user to have to mess around with this many random commands and environment variables just to get scaling working.
xrandr is perfectly sufficient for this, although GTK for whatever reason chooses to break it (not just not implement it; proactively break it). Xcb picks it up just fine, as does Qt. I'm pretty sure Fltk does now too though I haven't tried it in a while.
No, xrandr isn't sufficient. It still doesn't have scaling information, only size information. Changing the reported physical size of the monitor is a bad idea as it can break other things.
OFFS this is the most ridiculous reaction ever.
Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.
No. Even the X.org developers disagree with you here. Messing with the DPI will cause lots of clients to break even further. See this merge request for more info on this: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that behaves more like Wayland does it.
And yet, it works better than in Wayland.
No it actually doesn't, I've heard tons of complaints about X clients not scaling correctly. Sure it might work for the subset of clients that are reading the DPI value the way you intended, but in doing so you've silently broke a lot of other clients.
The "subset" of clients using Xcb or Qt? I'm fine with only counting them, personally...
This comment makes no sense, XCB isn't a toolkit. You might be thinking of something else with a similar acronym.
But anyway, any solution that tells users to only use a small subset of compatible clients is about as disruptive as just switching wholesale to Wayland. It's not the reason anyone is hanging on to the X server.
I didn't say it was a "toolkit", it's a library that largely replaces Xlib, and it uses xrandr correctly to allow multiple pitches
Yes, I know what it is. Here are some corrections.
1. XCB is a low level binding to the X11 protocol. It doesn't really replace Xlib. Originally that was the intention, but it's non-trivial to take an Xlib program and port it to XCB.
2. XCB doesn't know anything about scaling or even about XRandR, besides the wire protocol. Just because a client uses XCB is no guarantee that it even uses XRandR. It's definitely not a guarantee that it implements scaling.
3. There is no way to use XRandR correctly to allow multiple pitches, because XRandR doesn't have that functionality. All it does is report an estimated size of the monitor.
4. The scaling you're talking about is happening in the client, not in XCB or XRandR, and if it's ever going to work at all it needs to be controlled by some other setting or environment variable. Someone else in the thread posted a big set of those environment variables. Ideally you wouldn't use XRandR at all, there would be another extension.
5. None of the above applies to Qt, because Qt is a toolkit that does (mostly) implement the scaling for you. That's why it was weird you grouped it with XCB.
That's a whole lot of "nothing" it has to do with randr:
https://xcb.freedesktop.org/manual/group__XCB__RandR__API.ht...
But, yes, software using Xcb does have to actually do it correctly for it to work, like nearly all aspects of software development.
Like everything else in XCB, those are just stubs autogenerated from the wire protocol definition. The client has to actually implement the protocol semantics including duplicating a lot of logic that's already present in Xlib. There's no performance benefit to this either. For that reason XRandR is probably one of the most useless and least beneficial things to use XCB for. Signed, someone who actually did try this at one point and ended up reverting back to Xlib.
>But, yes, software using Xcb does have to actually do it correctly for it to work,
There isn't a way to do this correctly, it's a hack. The difference is that Qt attempts to do it automatically, compared to XCB that intentionally does nothing for the programmer because it's a low-level binding.
> There isn't a way to do this correctly, it's a hack
Hacks are often the correct way to do things.
JFC this is annoying. I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.
This doesn't work on Wayland. It does work on X11. You can stomp your feet until you're blue in the face but that won't change this basic fact.
If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.
>Hacks are often the correct way to do things.
In this case, it's not the correct way.
>I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.
No it's actually the other way around. You keep gaslighting and insisting that it's a valid solution because it works for a small subset of clients that you've picked for yourself. I'm telling you this isn't a valid solution for any X11 maintainer to put in place. I've already showed you where an X11 maintainer actually said this, but for some reason you think you know better. Well I'm sorry, but it's not a solution. When you maintain something like that, you don't get to pick and choose the clients you support. You have to support all of them. And yes, it is impossible for X11 maintainers to go and find and fix bugs in every single client from the last 35 years or port them all to XCB and rewrite the drawing code or whatever it is you'd like them to do.
>This doesn't work on Wayland. It does work on X11.
No, it doesn't work on X11 either. Refer back to the merge request I posted earlier. This isn't something you can just hack in. Your solution will break down if you ever need to use a different type of client.
>If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.
Where is this coming from? I've never said you should switch display servers. I'm only observing that you probably will once the limitations in your approach become apparent. You realistically don't get to even have preferences here, maintaining all of this is too much work for one person. Maybe you won't switch to Wayland, maybe it'll be something else entirely. Who knows? The point is, X11 doesn't do it.
And this is really my problem with talking about open source on HN. The well has been poisoned, I can't point out broken stuff without someone accusing me of having some kind of agenda. As if anyone who's developed for X11 for the last 36 years hasn't run into all these problems, repeatedly. Nothing is going to get fixed if everyone gets defensive and starts playing the blame game when bugs are pointed out. But that's all that happens here. If you ask me, it's yet another sign that the project is finished.
> One needs a way for users to configure the per monitor DPI.
xrandr --setmonitor has entered the chat
Simpler you can just scale lower dpi clients down from a higher resolution. Applications think every screen has the same DPI and draw accordingly. X scales such displays to the correct physical size.
I understand the reasoning here, and frankly supported. I've been using X11 while having an available Wayland session because some applications are subtly broken on Wayland - discord has weird text input issues, same thing with Emacs, and Wezterm just flat out doesn't work on Wayland with Nvidia GPUs. However, the slow breakage I've seen with X11 has caused me to start migrating. To explain, every now and then on X11 my screen will simply go black for a couple of seconds. It happens often enough where I'm no longer willing to accept in. And so thus I've moved to Wayland. And frankly, with a little bit of effort, I've found work-arounds for all of my issues - Wezterm works if you disable wayland, Emacs 29 works fine, and Discord is acceptable in the browser. And thus, I think that disabling X11 is a good idea because finally it would force people to actually make things work well under wayland, instead of being able to rely on X11 as a fallback.
This is going to leave so many people by the wayside. (Pun totally intended.) Late 2020, my jaw dropped on the floor when a developer from CERN showed up and said that X11 support was needed in ContainerSSH for their use case and then developed it. (The LxPlus service, which acts as a dev host for researchers.) I thought X11 forwarding was well and truly a thing of the past.
Yes, I know that waypipe is a thing, but it needs to be installed on both ends and I haven't seen any mention of non-Linux support either.
> I thought X11 forwarding was well and truly a thing of the past.
Am I misunderstanding what you're saying?
That's kind of the whole point of using X, the primary use case.
X forwarding over SSH always struck me as a bit of an edge case. I used it maybe 5 times in the last 20 years. Most people probably never knew this was a thing.
I use it every day all day ever since it was introduced in ssh (can't remember when). Before that used to just forward in plaintext over the network (different times).
When I explain this to people, they are usually very surprised.
With every year X is still in use more and more tech debt is being built up. It's a big problem in how slow this migration is going. The Linux desktop community should have made this migration its top priority and have had completed it a decade ago. It's sad to see how far behind the Linux desktop is compared to other operating systems.
You are wondering why other people didn't invest more of their time working for free for the abstract goal of moving someone else's vision forward.
If they wanted buy in the logical thing would be to provide a something usable and feature complete with wlroots like library inside of the first 5 years rather than producing something nobody would use, claiming it is usable, and then slowly evolving it towards usability slower than duke nukem forever while continually claiming it's ready to rock until the lie slowly becomes increasingly true.
I am not wondering that. There could have been corporate sponsors or community fund raisers to fund this essential work.
>If they wanted buy in the logical thing...
I already know that this was poorly handled. If Microsoft or Apple wanted to change rearchitect display servers I can assure you it would not take over 16 years.
It seems like this would effectively remove support for the BSDs which use X11. Am I missing something?
I think freebsd has some level of Wayland support. But yeah, I suspect that's at best a significant increase in patches needed for openbsd.
i’m working on a 240hz low latency game on linux.
currently i run on x11, either directly via startx or via dwm when developing.
i will switch to wayland in an instant if it demonstrably improves any metric i care about.
i continue to monitor the situation and look forward to improvements in either stack and in drivers.
Another case of GNOME living in la-la land. So glad KDE became kind of nice in recent years.
Reminds me of systemd: we "modern" developers despise anything that reminds us of "traditional" Unix, thus we need to rewrite it in such a way that is not only new, but actively punishes unwelcome users.
Then we will complain about "embrace and extend" while people try to replace their xdotool scripts and their perfectly working X11 setups.
Too bad for them: we don't care about custom applications, we still aim to just steal users from Windows. And 2024 will be the Year of Linux on the Desktop.
X11 has nothing to do with "traditional" Unix. Even back in the 80s the UNIX philosophy didn't work with a graphics stack and X11 itself is very un-Unix-like. This is even more true for the modern graphics stack. That being said, X11 is one of the few APIs that had a really long run and that everybody in the community agrees upon. This is extremely rare. 38 years of backwards compatibility and still being able to deliver performance on the most modern graphics stacks is a tremendously huge value that shouldn't be thrown away just because some IBM/Redhat or Collabora employee says so.
>X11 is one of the few APIs that had a really long run and that everybody in the community agrees upon
Outside of a very small niche of obscure window manager developers, this isn't true. GNOME and KDE have been trying to get rid of it for decades. The glaring flaws in the API have been known for that long.
>38 years of backwards compatibility and still being able to deliver performance
No, the Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream. At the time some of those may have been the best way to deliver performance on specific hardware but, like anything, they didn't hold up and were thrown away. It wasn't because an IBM/Redhat or Collabora employee said so. See also https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
> GNOME and KDE
Both are are really bad desktop environments and part of the reason the FOSS desktop never took off. Also they are mostly developed by full time paid employees with zero community involvement. As such they are the small niche.
> The glaring flaws in the API have been known for that long.
X11 has flaws but I wouldn't call them "glaring". They are a nuisance at best. You don't pay for functionality you don't need. Wayland has glaring flaws because it does not provide and standardize functionality that people need. It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
> Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream.
Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
>Also they are mostly developed by full time paid employees with zero community involvement.
No. Both of them have a good mix of community contributors to do the fun stuff, and paid employees to do the annoying tasks no one wants to do for free. A good project needs both. Are you really suggesting that another desktop is somehow going to spring up and succeed with no paid employees and no business case? If what you're saying is true, wouldn't that have already happened and left GNOME and KDE in the dust long ago?
>You don't pay for functionality you don't need.
You actually do if you're maintaining the X server and protocol.
>Wayland has glaring flaws because it does not provide and standardize functionality that people need.
These can be fixed by extending the protocol, unlike in X11 where the flaws can't be fixed because they're built into the core.
>It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
This is actually a kernel/driver problem. It also happens in X11 if you use a driver with implicit sync.
>Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
No that's not what's happening either. Lots of current X11 extensions (such as Big Requests, XC Misc, XFixes, XSync) actually exist only to paper over old cruft in the core protocol that can never be removed. It's possible to remove other extensions from the core and still keep the core intact. When the core X11 protocol itself becomes unused and unpopular (which it is) then it's time to remove the whole thing.
The API compatibility is not being thrown away. Xwayland will be with us for a long time for backwards compatibility (that includes stuff that lots of users care about, e.g. most Steam games). X11 will continue to be around, reduced to a more manageable size as a compatibility layer, within Wayland.
Xwayland only provides backwards compatibility for a very small subset of the X11 ecosystem (E.g. window managers or xdotool are not supported). As such it is only useful for very limited X11 clients on the level of GNOME applications and in most cases completely useless.
That's the same limitation as XQuartz or any other rootless X server. And you have this exactly backwards. The majority of X clients that users care about are ordinary programs, not window managers or xdotool.
> The majority of X clients that users care about are ordinary programs
This is simply not true. The only "odinary" programs according to your definition that I am running are a browser and a terminal. All other xclients I'm running go beyond that and can not work with Xwayland or XQuartz. (a quick ´grep "^[x,X]" .bash_history´ reveals xautolock, xbacklight, xbel, xcalib, xcape, xdpyinfo, xdotool, xkill, xmodmap, xrandr, xrdb, xsel, xset)
Replying again because you edited your comment.
xbacklight, xcalib, xcape, xmodmap, xrandr, xset: These are utilities specific to configuring the X server. They're needed on non-X11 window systems.
xbel: I don't know what this is.
xdotool: Some commands will still work. Other commands that require interaction from the window manager might not work, but they won't work on some X11 window managers either.
xrdb, xsel, xkill: These still work, although for obvious reasons they won't affect native Quartz or Wayland applications.
By the way, none of those are ordinary X applications. Notice how none of them actually display any windows or having graphical interactions with the user? You know, that thing that X11 is designed to do? Put windows on the screen?
Which X clients are these? You didn't name any so let's just look at some of the popular and recent flathub apps: https://flathub.org/
I see a lot of games, chat apps, text editors, photo apps, office apps. These all will work fine in XWayland and XQuartz. But also, it's relatively easy to get them running on Wayland natively.