Individual GNOME applications [LWN.net]

Individual GNOME applications

Posted Jun 24, 2025 6:58 UTC (Tue) by ebee_matteo (guest, #165284)
In reply to: Individual GNOME applications by SiB
Parent article: GNOME deepens systemd dependencies

No, I don't think this will be a problem in the short term.

At some point the move to wayland will kinda kick in, and then I expect X11 to slowly go away simply because there seem to be a strong dip in number of commits/bugfixes. Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11. But wayland is quickly closing the gap. Running old applications requiring X under Wayland is mostly fine by now.

But at the end, it's a matter of effort and distro support. As long as there are enough sysv or openrc users around willing to support them, it will keep working. Maybe not with GNOME, but there are other DEs out there. Systemd also has a compatibility layer for sysv.

The reality is that Linux is becoming more successful also for enterprise workstations. Which is what most of us always wished for, right? More "market share". That means that covering a lot of use cases that are "enterprise" in nature (e.g. Microsoft Entra ID interoperability) is mandatory to stay relevant. These were not as important before. Now businesses which are financing development are strongly pushed to cater for these requirements. Read Red Hat, for instance, from governments and companies around the globe.

At some point, we need to understand that we are somewhat victims of our own success. The system becomes more complicated because it needs to, not just because some youngsters think reimplementing everything is fun. This is an hobbyist system becoming finally mainstream, and having to respond to regulatory and interoperability constraints.

Individual GNOME applications

Posted Jun 24, 2025 8:19 UTC (Tue) by pabs (subscriber, #43278) [Link] (3 responses)

I thought RedHat was moving away from workstation stuff towards cloudy things?

Individual GNOME applications

Posted Jun 24, 2025 17:36 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (2 responses)

Workstation is certainly not a major revenue source but it still exists.

What you might remember is moving away from supporting all apps in favor of flatpak—one major example being LibreOffice.

Individual GNOME applications

Posted Jun 25, 2025 5:28 UTC (Wed) by ebee_matteo (guest, #165284) [Link]

Government contracts, especially in some European and Asian countries, are consistent.

Individual GNOME applications

Posted Jun 26, 2025 3:35 UTC (Thu) by pabs (subscriber, #43278) [Link]

Yeah, and some other apps like Evolution that they were funding. I wonder if they just dropped those apps, or are funding the Flatpak versions instead?

Individual GNOME applications

Posted Jun 24, 2025 9:56 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

> Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11.

That's news to me. I've been running X11 on my Dell XPS laptop with (very) HiDPI and plugging in and out of external monitors since I got that laptop - and it's at least a decade old. (There were HiDPI issues initially, they are largely gone - before Wayland was a useable thing).

Individual GNOME applications

Posted Jun 24, 2025 9:57 UTC (Tue) by paulj (subscriber, #341) [Link]

Oh, and multi-monitor support works _better_ in X11 than it does in MS Windows (which I was forced to use at an employer - which I did mostly as a GUI shell around WSL; but Windows _really_ sucks at multi-monitor, constantly forgetting which windows had been on which monitors particularly, very very annoying).

Individual GNOME applications

Posted Jun 24, 2025 16:32 UTC (Tue) by smurf (subscriber, #17840) [Link] (1 responses)

It's not news to me. There's still lots of programs that don't work correctly with HiDPI under X11. No, not just games.

Also, don't even think about trying to span monitors of disparate resolution with a single window.

Also² don't get me started on other silly assumptions in the X11 codebase. Simple example: Wayland thinks that negative pointer coordinates are a perfectly cromulent thing to have. Xwayland does not. You guess what happens on my monitor setup, where monitor #2 is mounted 120 pixels higher than #1.

Individual GNOME applications

Posted Jul 19, 2025 14:27 UTC (Sat) by daenzer (subscriber, #7050) [Link]

FWIW, per the discussion starting at https://gitlab.freedesktop.org/xorg/xserver/-/merge_reque... , while this could be fixed in Xwayland in theory, it would be really tricky to catch all affected code. And it could likely still confuse some X clients.

Making the Wayland compositor not advertise any outputs at negative locations to Xwayland, while technically a workaround, should be a much easier solution overall.

Individual GNOME applications

Posted Jun 25, 2025 8:38 UTC (Wed) by patrick_g (subscriber, #44470) [Link] (6 responses)

> Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11

How can we be sure it's true? Have you seen that post from Ted Unangst?
https://flak.tedunangst.com/post/forbidden-secrets-of-anc...

Individual GNOME applications

Posted Jun 25, 2025 8:48 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (5 responses)

The problem is having mixed resolutions, stuff at one high DPI external monitor and a low DPI laptop screen. Bonus points for rendering at one resolution and zooming to the other when a window is moving between one screen and the other.

Individual GNOME applications

Posted Jun 25, 2025 10:06 UTC (Wed) by smurf (subscriber, #17840) [Link] (4 responses)

For even more fun, try a window that spans both screens. Doesn't work: depending on the phase of the moon you either have a half window that's way too large, or one that's way too small.

This is a fundamental X11 protocol limitation.

Granted that you could "fix" this by creating a virtual high-res screen that replaces your low-res one, then downscale onto the latter, but (a) the result looks somewhere between ugly and unusable if you want do to Real Work, (b) we're way beyond the point where the heap of hacks and extensions that has been piled onto the original X11 protocol stopped being maintainable in a meaningful way.

Individual GNOME applications

Posted Jun 25, 2025 12:37 UTC (Wed) by dskoll (subscriber, #1630) [Link] (3 responses)

I have an X11 setup with four monitors, and I can move a window so half of it is on one monitor and the other half on another and it works just fine. Perhaps I am not quite getting what you mean when you write "try a window that spans both screens."

Individual GNOME applications

Posted Jun 25, 2025 13:29 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

If you have different scale factors for each screen, so that windows appear the same size as they cross the boundary even though the screens have different native PPI, you'll see the issue on X11, but not Wayland. You won't see this with 4 monitors of same diagonal size and resolution.

Under X11, the display is represented as a single large buffer, rectangular sections of which are sent to scanout. Scaling is applied to content as the window content goes from the application's internal representation to the buffer, and this scale factor is the same for all monitors (whether that's the 200 PPI laptop display I'm using as a second screen, or the 150 PPI external monitor I use as my primary display). As a result, I cannot set a scale factor that's right for both monitors - there will always be a discontinuity at the seam, because X11 assumes that something 1,000 pixels high on my laptop screen is visually the same height as something 1,000 pixels high on my external screen, and that's not true (on my laptop screen, that's about 5 inches, on my external screen, it's a bit over 6.6 inches).

Wayland's architecture works differently; the display is considered as-if it's composited from individual windows at scan-out time. The compositor and the application negotiate the window's scaling factor, so the application knows that it's rendering something that's visually meant to be 1,000 abstract units high, but that it's being expected to render (say) a 2,000 pixel high buffer that will be scaled down by the compositor. The compositor can then scale that down to 1,500 pixels on my external monitor (10 inches), and display it at 1:1 on my laptop screen (10 inches), making it look the same on both monitors.

Wayland can also renegotiate the scaling as windows move; so when a window is on my external monitor only, the application can know that it'll be rendering a 1,500 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units of space, while moving that window to my laptop screen gets the same application told to render to a 2,000 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units.

Individual GNOME applications

Posted Jun 25, 2025 15:00 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Hmm... the thing is, you can still change the resolution on external monitors to suit. You don't per se need to have Linux do the scaling.

The only time I notice scaling issues now is with xpra to apps running on a server and I havn't set dpi to 48 with xrandr. It doesn't seem to affect any local apps on the HiDPI laptop, but scaling of /1/ particular app (which seems to use some custom toolkit in Java that renders via OpenGL) can be off. Other than, things have been fine for years, with my HiDPI laptop and the monitors I plug into anyway (1 of which is one of those large, v wide Dell ones).

Individual GNOME applications

Posted Jun 25, 2025 15:12 UTC (Wed) by farnz (subscriber, #17727) [Link]

Well, depends on the display and the attachment method; my external monitor flickers wildly at any resolutions other than CEA-861 predefined resolutions (and I've not bothered to work out why - there's a firmware update available, but I'd have to get a Windows machine sorted to apply it). No trouble at 640x480, 2880x576, 1280x720 or 3840x2160, but huge trouble at 2560x1440@60Hz. I therefore need Linux to do the scaling, because the scale I'm asking for would need the monitor to run at 2560x1440.

And I also find that Linux is better at doing the scaling than the monitor is; text is easier to read when the application renders for a 5120x2880 monitor, and then the compositor downscales to 3840x2160, than it is when the application renders for 2560x1440, and the monitor or the compositor upscales to 3840x2160.