Any reason we don’t have a hybrid scaling option for legacy x11 applications?
If it’s impossible for the system to identify an application automatically, maybe include an override for specific programs? That way I can force system scaling, without all my applications appearing blurry.
What do you mean by this, exactly?
My best guess is “per application scaling options”? I’m not sure if something like this would be feasible through kwin application rules. I’m not really using many x11 applications anymore, so I don’t know how big a problem this really is.
One workaround is to use “Apply scaling themselves”, then launch those who doesn’t scale with Gamescope.
Yeah, that turns out to be really challenging. XWayland uses a global scale (just like good old X11 did) so to have per-app XWayland scaling, you’d need to run multiple XWayland instances, one per scale factor used. This is something we don’t have the ability to do right now, and if we did, the result would be higher background resource usage — potentially a lot, if you have multiple screens with different scale factors and you run more than a few XWayland-using apps with their own scale factors. You could easily wind up with 5 or 10 XWayland instances running!
Well, that makes sense. And I guess it would basically be @jinliu’s solution but with extra steps
jinliu’s recommendation will work for my use case, but I would imagine that it would be heavier than what I need. I would imagine only 1 or 2 XWayland instances would be necessary. I am not asking for “per application scaling.”
Here’s the proposal:
So basically the exact same as how the scaling already works, but just let me scale some apps to the system scale.
Since i saw other threads talking about the experience on 4K monitors, i’d like to show another experience: very small screens.
The device is a X-Plus Piccolo Series81x, it has a 1920x1200 8" display. It uses 190% scale and anything below gets too small. This can also turn into a tablet so scaling is really essential.
Most X11 applications gets basically unusable so i set it for system scaling as default, but it also regress on usability for applications that already worked great on per-app scaling.
The very first example is Netbeans 8.2. This is the best version to develop J2ME CLDC and CDC applications, it is a old software which only uses old X11 functionality and has almost no scaling properties. When using per-app scaling method, it won’t scale and everything looks too small to see without gluing my snout to the screen and becoming hunchback with time.
But if we go to $NETBEANS_DIR/etc/netbeans.conf, we can add “–fontsize 32”. It works, but we can clearly see this software was never meant to be scaled since everything looks so buggy and menu contexts starts to flicker
This is a software that can only look nice on scaling by system mode
But an X11 application that does work on per-app scaling mode, although not perfect, is KiCAD. The buttons are small (honestly, they’re better this way in this case) but everything else is easy to see.
But system scaling not only makes it look blurry: Boxes occupy too much spaces and it gets basically unusable. Texts are also bad to read without having to zoom in which wasn’t a problem on per-app scaling.
There’s also the case of X11 software that supports scaling, but has to be manually set. A popular one being Wine - I know, it’s not an app, but we can consider it’s basic graphical functionality. I’m testing it alongside q2mdlr9b for demonstration. Since not every Windows applications work alongside scaling, which is why Wine made it manual, it’s a case where system scaling could be used as default and some software could use per-app when it fits better. KDE wouldn’t detect it as “wine” but as the application name running it (MDL.EXE)
Of course, the default scaling with per-app mode is bad
But we can manually scale it thorough winecfg. We can also do it exclusively for this software by either using wine prefixes or adding a custom setting on the “Applications” tab on winecfg.
It also works on system scaling mode
This is a case where both works well but some could bring better experience over one option
Many games works really well with either option since their respective tools can alreay handle with Wayland, Steam games works well, OpenArena works well. But 2 games catches my attention due to having issues on one of options: Minecraft with system scaling and Unreal with per-app scaling.
Minecraft with per-app scaling looks really nice
But we lost all the beauty when we are in system-scaling mode, even in fullscreen. The game is rendering at a way lower resolution and rescaling to a higher one. Since it’s a small screen it doesn’t bothers much, but we lost the potential to use every pixel of the display. An workaround is to use a modified GLFW to force it to use Wayland instead of XWayland.
Now the next one get’s completely unplayable. This is Unreal Gold running in pure Wine in per-app scaling mode:
Even though the UMPC is at landscape, the display is a portrait tablet display. So the real resolution is 1200x1920. The game renders at this resolution and glitches out when it tries to fullscreen at 1920x1200.
But it works well on system-scaling mode. Yes, it looks blurry, but now it’s finally playable
For now, i have to constantly switch between these options or use workarounds.
I think instead of enabling a blacklist only if “Apply scaling themselves” is chosen, it could work for both options. The blacklist would work by application name like how it does on window rules, when “Apply scaling themselves” is chosen blacklisted apps would be scaled by the system, when “Scaled by system” is chosen, the compositor would let blacklisted apps scale by themselves. All using the global display scaling defined by the user, apps wouldn’t be able to use their own scaling factor.
That would mean: Use this scaling method as default EXCEPT for these names in the blacklist.
For user friendliness, i think the user could also have a list of running apps when adding to the blacklist, or access it via the Application Window Rules menu and have the X11 Scaling mode rule there.
That sounds the most logical place to me: you have a window that doesn’t look right wth defaults, you go to its window rules and make an override.
Similar to what is described for window frames/shadows in @zzag 's latest blog
¿Any plans how to implement that? Looking into how XWayland works i think there may be three ways to implement this, i am basing it without much technical knowledge on the X11 backend:
Run 2 X11 servers and switch which one the app is running on when the setting is changed (or require a app restart). X11 pass a global display resolution value to it’s running applications so there would be a conflict when multiple apps are running with different scaling settings as Plasma would be required to pass a fake value. A limitation would be when an X11 app uses an hardcoded DISPLAY variable value since we would have :0 and :1 IF there’s no other X11 server running, however i don’t know any software that actually does this bad implementation in purpose.
Use virtual displays. In example, when there’s a 1080p set to 150% scale and a 2160p display set to 100% scale, use virtual displays in 1080p display and a 720p for the real 1080p display, and two 2160p virtual displays. Switch the app to these displays according to it’s setting and it’s display position. Then mix the respective virtual displays and render on the real display. Limitation would be that X11 apps would have access to every display and they usually control where and how they’ll be display (ie an loading splash window), some even detect every display as if they were a single display by adding their resolutions, this could break rendering on some applications.
Maybe fork XWayland to catch and spoof server resolution to applications based in user settings in order to use the same server without the double virtual displays workaround. A limitation would be that distros would have to distribute the KDE fork and it could potentially break compatibility with standard XWayland implementation aswell.
I think the first implementation is more viable. You have a app scaling and a system scaling XWayland servers, then start the application on the respective server based on their settings, and if the user change their scaling rule (probably) apply it when they’re restarted. X11 apps wouldn’t be able to access composition of the apps on the other scaling method but Wayland apps already can’t do it anyways and XWayland can’t do it against Wayland apps aswell. Wayland to X11 Video Bridge would have to support bridging to 2 X11 servers.
Additionally, there could be a terminal command to start the X11 application on one of these servers manually, for applications that don’t obey the app scaling rules. I think this could be the case when DISPLAY is catch before the process that request a new window is forked with a new name and Plasma can’t detect it.
