Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gnome developer proposes removing the X11 session

theregister.com

Post reply on HN
Print view View original

71–80 of 122 posts

Re: Gnome developer proposes removing the X11 session

#71

Post by r0l1 »

Fluorescence wrote: post #64
r0l1 wrote: post #51

Earlier quoted context omitted.

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.

Re: Gnome developer proposes removing the X11 session

#72

Post by adastra22 »

jeroenhd wrote: post #44
adastra22 wrote: post #37

Earlier quoted context omitted.

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!

Re: Gnome developer proposes removing the X11 session

#73

Post by majewsky »

sprash wrote: post #70
olgeni wrote: post #59

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

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

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.

Re: Gnome developer proposes removing the X11 session

#74

Post by sprash »

majewsky wrote: post #73
sprash wrote: post #70

Earlier quoted context omitted.

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

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.

Re: Gnome developer proposes removing the X11 session

#75

Post by yjftsjthsd-h »

MobiusHorizons wrote: post #43

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.

Re: Gnome developer proposes removing the X11 session

#76

Post by E1Q6Y57O »

somat wrote: post #18
bitwize wrote: 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/

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.

Re: Gnome developer proposes removing the X11 session

#77

Post by E1Q6Y57O »

bandrami wrote: post #56
aumerle wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Gnome developer proposes removing the X11 session

#78

Post by E1Q6Y57O »

sam_lowry_ wrote: post #58
mongol wrote: post #38

Earlier quoted context omitted.

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?

Re: Gnome developer proposes removing the X11 session

#79

Post by E1Q6Y57O »

sprash wrote: post #70
olgeni wrote: post #59

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

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

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

Re: Gnome developer proposes removing the X11 session

#80

Post by E1Q6Y57O »

YarickR2 wrote: post #23
aumerle wrote: post #4

Earlier quoted context omitted.

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

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.
Post reply on HN