Workaround: Applications not applying fractional scaling properly on multi-monitor setup Pop!_OS 24.04 COSMIC #3260
demcdonald2000
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all! Just spent the last couple days troubleshooting a fractional scaling issue and thought I'd share the workaround I landed on in case someone else is having a similar issue (and let's be honest, this is kind of a brain dump). This is probably not specific to Wayland on COSMIC / Pop!_OS, but it might be (I saw a similar issue on Fedora COSMIC #3070 but my situation was slightly different). I'm pretty new to Linux, as you'll probably be able to tell, so sorry in advance! Feel free to let me know where I'm wrong, misused terminology, or could have approached things differently.
TL;DR for each app
Obsidian (presumably on a new Electron version)
ELECTRON_OZONE_PLATFORM_HINT=autoenvironment variable to FlatsealTodoist, Signal, and Chrome (presumably on an older Electron and/or Chromium version)
.desktopshortcut configuration files for the flatpak, e.g.:~/.local/share/flatpak/app/com.todoist.Todoist/current/active/export/share/applications/com.todoist.Todoist.desktop~/.local/share/applications/Exec= ...line(s) to append argument--disable-features=WaylandPerSurfaceScaleBackground
I just installed Pop!_OS 24.04 LTS with the new COSMIC desktop environment (using Wayland) this weekend. I was previously using Pop!_OS 22.04 LTS with the GNOME desktop environment (using X11).
My system is a desktop PC in the following configuration:
After installing, I set up my monitors, installed applications (mainly flatpaks), and was having an issue with Monitor 2 scaling. All windows were displaying correctly on Monitor 1, but some were not scaling correctly on Monitor 2. Visually, the active hint was outlining the window as full screen, but the window would only take up some of that space (smaller than it should be). However, the mouse interface responded to clicks as though the window was taking up the full screen. Based on which apps were working and which were not, it seems like it might have been related to an issue with flatpak on Wayland; however, I tried downloading Google Chrome directly from Google as a .deb package and installing it, but it behaved the same way, so it doesn't appear to be purely a flatpak problem (I promptly uninstalled it and so haven't tested my workaround on a local install). Ultimately my working theory is that it is an older version of Chromium, but I'm not really that familiar with the underlying version of Chromium being used by each application and why a fresh install of Chrome wouldn't be using the latest version of Chromium (if that's actually how that works).
For reference, I've copied my
~/.local/state/cosmic-comp/outputs.rondisplay config file and an example full-screen screenshot of Google Chrome not scaling to the full monitor size.A non-exhaustive list of example apps scaling properly and not scaling properly is below:
Troubleshooting
I tried adjusting a variety of permissions and environment variables in Flatseal, and misc. other options. I've tried to list them below, but my brain has purged some of the weirder things I tried (probably for the best):
ELECTRON_OZONE_PLATFORM_HINT=autoFLAGS="<arguments here>", with variations of the the arguments--ozone-platform-hint=auto,--ozone-platform-hint=auto,--disable-features=WaylandPerSurfaceScaleand--enable-features=WaylandWindowDecorationsflatpak override --user --nosocket=x11 --socket=wayland com.todoist.Todoist <more arguments from aboveto make sure they were being taken up--ozone-platform-hint=auto,--disable-features=WaylandPerSurfaceScaleand--enable-features=WaylandWindowDecorations--disable-features=WaylandPerSurfaceScale.desktopfile and creating local (persistent?) shortcuts for each applicationfind ~ -name *.desktop | grep <app name>in order to locate them. seems like these could also be located in/var/lib/flatpak/...somewhere..desktopshortcut.After all of this, I made sure all of the configs in Flatseal were reset to defaults (except for Obsidian), so hopefully my experimentation didn't break anything.
Conclusion
Seems like this is a situation where older versions of Chromium are competing with cosmic-comp Wayland service to scale the application. In other words, both are applying the 0.85 screen scale in some way (somewhere the border space is visually added, as though Chromium rendered to max widow size of 1920x1080p in a 2258x1271p frame before handing that full frame off to cosmic-comp which just scaled the 2258x1271p frame to the 1920x1080p screen). It seems when the scale is 1 (like on my monitor 1), the issue doesn't present itself, but when it is not 1 (I've only tested 0.85), the issue arises. Having a tough time wrapping my mind around the frame transforms though. Regardless, the
solutionworkaround seems to be to pass a runtime argument of--disable-features=WaylandPerSurfaceScaleto the Chromium/Electron-based app every time it is launched (implemented via each app's.desktopshortcut file). The actual solution seems to have been implemented in newer versions of Chromium (or at least I assume that's why some of the Electron based apps worked while others did not). And for Obsidian, I guess it just wasn't getting the hint that it was running on Wayland and needed a little nudge.Maybe there is something the COSMIC team could implement as an enhancement to be a little more backward compatible; that is above my head if so. Either way, I'm just happy I found a solution and hope this helps someone else.
References
outputs.ron:
Beta Was this translation helpful? Give feedback.
All reactions