> 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.
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"
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.
What fraction is that? I thought X still had the larger user share.
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.
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.
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.
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
Not if they remove X from gtk+ too. That is the logical next step.
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.
- 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
> 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.
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
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.
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.
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.
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.
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.
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.
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.
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 &
waitxrandr --setmonitor has entered the chat
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.
Am I misunderstanding what you're saying?
That's kind of the whole point of using X, the primary use case.
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.
>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.
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.
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.
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_...