18 ms·

Gnome developer proposes removing the X11 session

47 points by malobre 3y ago

jrm4 3y ago
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.
bitwize 3y ago
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.
- aumerle 3y ago
  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.
  - bitwize 3y ago
    > One needs a way for users to configure the per monitor DPI. xrandr --setmonitor has entered the chat
  - deleted 3y ago
    [deleted]
  - YarickR2 3y ago
    >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 & wait
    - E1Q6Y57O 3y ago
      If 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.
  - bandrami 3y ago
    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.
    - E1Q6Y57O 3y ago
      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.
      - bandrami 3y ago
        OFFS this is the most ridiculous reaction ever. Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.
        E1Q6Y57O 3y ago
        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/792 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.
        bandrami 3y ago
        And yet, it works better than in Wayland.
        E1Q6Y57O 3y ago
        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.
- pengaru 3y ago
  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.
  - YarickR2 3y ago
    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
    - pengaru 3y ago
      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.
- somat 3y ago
  The best article I have found about mixed dpi on x11 is. http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
  - E1Q6Y57O 3y ago
    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.
    - somat 3y ago
      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.
- michaelmrose 3y ago
  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.
v3ss0n 3y ago
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 A proper refactor of X11 should have been the way to go and there should had been X12 with modern technologies
- JoshTriplett 3y ago
  > 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.
  - redox99 3y ago
    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
    - JoshTriplett 3y ago
      > 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.
JoshTriplett 3y ago
GNOME (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.
- koito17 3y ago
  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"
  - JoshTriplett 3y ago
    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.
webkike 3y ago
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.
janosdebugs 3y ago
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.
- jjav 3y ago
  > 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.
  - janosdebugs 3y ago
    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.
    - jjav 3y ago
      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).
      - janosdebugs 3y ago
        When I explain this to people, they are usually very surprised.
fgsfds028374 3y ago
Another case of GNOME living in la-la land. So glad KDE became kind of nice in recent years.
charcircuit 3y ago
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.
- michaelmrose 3y ago
  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.
  - charcircuit 3y ago
    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.
MobiusHorizons 3y ago
It seems like this would effectively remove support for the BSDs which use X11. Am I missing something?
- yjftsjthsd-h 3y ago
  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.
uxp8u61q 3y ago
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.
- r0l1 3y ago
  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.
  - Fluorescence 3y ago
    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.
    - Gualdrapo 3y ago
      Then I don't understand why people blame about Wayland about this on its entirety.
olgeni 3y ago
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.
- sprash 3y ago
  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.
  - majewsky 3y ago
    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.
    - sprash 3y ago
      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.
      - E1Q6Y57O 3y ago
nathants 3y ago
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.

47 points by malobre 3y ago

jrm4 3y ago

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.

bitwize 3y ago

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.

aumerle 3y ago
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.
- bitwize 3y ago
  > One needs a way for users to configure the per monitor DPI. xrandr --setmonitor has entered the chat
- deleted 3y ago
  [deleted]
- YarickR2 3y ago
  >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 & wait
  - E1Q6Y57O 3y ago
    If 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.
- bandrami 3y ago
  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.
  - E1Q6Y57O 3y ago
    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.
    - bandrami 3y ago
      OFFS this is the most ridiculous reaction ever. Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.
      - E1Q6Y57O 3y ago
        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/792 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.
        bandrami 3y ago
        And yet, it works better than in Wayland.
        E1Q6Y57O 3y ago
        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.
pengaru 3y ago
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.
- YarickR2 3y ago
  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
  - pengaru 3y ago
    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.
somat 3y ago
The best article I have found about mixed dpi on x11 is. http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/
- E1Q6Y57O 3y ago
  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.
  - somat 3y ago
    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.
michaelmrose 3y ago
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.

v3ss0n 3y ago

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 A proper refactor of X11 should have been the way to go and there should had been X12 with modern technologies

JoshTriplett 3y ago
> 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.
- redox99 3y ago
  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
  - JoshTriplett 3y ago
    > 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.

JoshTriplett 3y ago

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

koito17 3y ago
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"
- JoshTriplett 3y ago
  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.

webkike 3y ago

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.

janosdebugs 3y ago

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.

jjav 3y ago
> 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.
- janosdebugs 3y ago
  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.
  - jjav 3y ago
    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).
    - janosdebugs 3y ago
      When I explain this to people, they are usually very surprised.

fgsfds028374 3y ago

Another case of GNOME living in la-la land. So glad KDE became kind of nice in recent years.

charcircuit 3y ago

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.

michaelmrose 3y ago
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.
- charcircuit 3y ago
  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.

MobiusHorizons 3y ago

It seems like this would effectively remove support for the BSDs which use X11. Am I missing something?

yjftsjthsd-h 3y ago
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.

uxp8u61q 3y ago

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.

r0l1 3y ago
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.
- Fluorescence 3y ago
  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.
  - Gualdrapo 3y ago
    Then I don't understand why people blame about Wayland about this on its entirety.

olgeni 3y ago

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.

sprash 3y ago
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.
- majewsky 3y ago
  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.
  - sprash 3y ago
    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.
    - E1Q6Y57O 3y ago

nathants 3y ago

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.