Live data from Hacker News

Gnome developer proposes removing the X11 session

theregister.com

11–20 of 122 posts

Re: Gnome developer proposes removing the X11 session

#11
post #4
post #3

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

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.

> One needs a way for users to configure the per monitor DPI.

xrandr --setmonitor has entered the chat

Re: Gnome developer proposes removing the X11 session

#12
post #3

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

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.

Re: Gnome developer proposes removing the X11 session

#13
post #5

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

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

Re: Gnome developer proposes removing the X11 session

#14
post #8

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…

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

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.

Re: Gnome developer proposes removing the X11 session

#15
post #5

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

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

Re: Gnome developer proposes removing the X11 session

#16
post #4
post #3

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

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.

[deleted]

Re: Gnome developer proposes removing the X11 session

#17
post #8

Earlier quoted context omitted.

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

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

Except for the guy who tried to do that with Python2 and the Python Foundation threatened legal action

Re: Gnome developer proposes removing the X11 session

#18
post #3

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

The best article I have found about mixed dpi on x11 is.

http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/

Re: Gnome developer proposes removing the X11 session

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

Re: Gnome developer proposes removing the X11 session

#20
post #8

Earlier quoted context omitted.

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

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

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

Post reply on HN