GNOME Bugzilla – Bug 777470
Scale factor too large on wayland backend with tiled monitors
Last modified: 2017-09-04 08:33:01 UTC
I run Gnome on a tiled 4K display (meaning the monitor presents two 1920x2160 displays that are combined into an overall 3840x2160 display). When updating to Fedora 25, I was finally able to run wayland in this configuration. However, when doing so, the windows (and cursor) are scaled much too large. In X I use a scale factor of 2x, but the wayland scaling appears to be at least 8x, possibly more. This is only an issue with tiled displays. I can also run my monitor as a single 3840x2160@30Hz panel, and the scaling is normal there. Further, I have a 3840x2160@60Hz laptop that works as a single panel, and it acts normally. Hopefully I'm filing this against the right product. Other bugs of this sort seem to be filed against gtk's wayland backend, and I guess that's where the scaling information is calculated? As I recall, changing the scale factors in the tweak tool (which determines how things behave in X) has no effect when this is happening, so I guess the wayland backed ignores that setting. I'm running Gnome 3.22 (gtk+ 3.22.6). Let me know if any further information is needed.
(moving to mutter, since thats where calculating the scale is done) Could you run $ gdbus call --session --dest org.gnome.Mutter.DisplayConfig -o /org/gnome/Mutter/DisplayConfig -m org.gnome.Mutter.DisplayConfig.GetResources > monitor-resources.txt $ weston-info > weston-info.txt and attach those two files here?
(From within the abnormally scaled Wayland session. You could try to run them from xterm, since xterm will not be scaled)
Created attachment 343771 [details] monitor-resources wayland
Created attachment 343772 [details] weston-info output
Created attachment 343773 [details] monitor-resources X Windows Here are the requested files. I also attached the output for monitor-resources under X in case it's of interest.
Hmm. It looks like the correct scale (2) is calculated. When you ran those commands, what was your monitor setup? I can see 4 outputs, i.e. it looks like you have two identical Dell monitors with different serial numbers connected to 4 display ports. Is that correct? Could you run the same commands, but with using the non-tiled mode (i.e. the 3840x2160@30Hz mode) where the issue is not visible? Also, can you reproduce this issue with weston-terminal?
(In reply to Jonas Ådahl from comment #6) > Hmm. It looks like the correct scale (2) is calculated. When you ran those > commands, what was your monitor setup? I can see 4 outputs, i.e. it looks > like you have two identical Dell monitors with different serial numbers > connected to 4 display ports. Is that correct? That's how those monitors appear. Internally, they're four actual separate panels. You connect them over 2 DP cables, each carrying 2 MST streams, giving you the four outputs. Elegant, isn't it?
Created attachment 343800 [details] monitor-resources 30Hz + 60Hz
Created attachment 343801 [details] weston-info 30Hz + 60Hz
Actually, Jonas was correct. I have two identical 4K displays connected. Each takes one DisplayPort cable as input, and MST streams drive two panels in each. I reset one of the monitors to DisplayPort 1.1 mode, which renders it unable to expose the MST tiles, and thus it runs in the 3840x2160@30 mode. Hopefully that's good enough (otherwise I'll have to switch out video cards). I left the other in DP1.2 mode running at the 60Hz modes. You can see the command outputs in the "30Hz + 60Hz" files. Interestingly in this setup, everything is scaled properly on the 30Hz monitor, but when I drag (Gnome or weston) window to the 60Hz monitor, it suddenly becomes huge. It will stay huge until I get it back on the 30Hz monitor, and make it realize it is so (just dragging it there doesn't seem to be enough, but trying to make it snap to a side is). And yes, weston-terminal also displays this behavior.
Oh, also, not sure if this information will help, but... Now that I can easily compare the different scaling, I've noticed a 3 things. 1) The scaling is actually off by more than 2x vs 8x. It actually looks like the too-large scaling is 8x larger than the appropriate scaling. If I make a weston-terminal window that is 1/2 of the width of the normal scaling screen, it becomes big enough to be 4 screens wide with the extra scaling. 2) The too-large scaling is not just rendering at 16x or whatever. It actually looks like it's rendering at some lower scale factor and then being scaled up by some other interpolation algorithm. I can see the grayscale in anti-aliased text, for instance. 3) The mouse cursor acts oddly on the extra scaling monitor. On the 30Hz monitor it is the size I expect. On the 60Hz monitor it is double the size I expect when I hover over the desktop, and it is crisply drawn in that situation. However, when I move it over a (Gnome or weston) window, it increases in size again by arounnd 4x, and displays the same kind of interpolated scaling look as the window. So, it seems like the tiled display might be, somewhere, using both a 4x scaling factor, and doing two types of scaling---one where the window draws itself scaled, and one where the window image is blown up by 4x (perhaps intended for windows that aren't HIDPI aware?).
Created attachment 344332 [details] [review] monitor-manager: Get monitor info scale from main output tile We didn't ever set the monitor info scale for tiled outputs; lets do that by taking it from the main output. ---- I wonder if this will cause the issue you are seeing. I don't have the hardware to test this. Would it be possible for you to apply this patch against the newest 3.22 mutter release and see if it improves things?
So, I built and installed mutter with the patch, but nothing happened. However, I don't see 'mutter' literally running, and I'm not allowed to run 'mutter -r' for instance. How can I be sure it's using the patched mutter? Do I have to also build gnome-shell from source?
Run "ldd `which gnome-shell`" and check that the libmutter.so is the patched version.
Could you run: WAYLAND_DEBUG=1 gtk3-demo >& gtk3-demo.log and upload the attached file? Just to rule out it's not a client problem.
Created attachment 344431 [details] gtk3-demo output with bad scaling
So, I finally cobbled together a working setup that used mutter installed from source. I had to, for instance, symlink Xwayland to /usr/local to make things not crash, though, so I don't know how much of the still-bad behavior I saw was due to things like that. Anyhow, it appears that the patch setting info.scale does make GTK wayland programs scale correctly, so this is probably the fix. Some stuff wasn't properly scaled. For instance, firefox tab text was tiny. However, that's an X app, so my janky setup could have caused that problem. gnome-shell was also rendering things too small, which is odd, because it's actually the one thing that is appropriately scaled when gnome wayland things are over-scaled. However, I think even the gnome-shell behavior might be due to library/other mismatches. Back before symlinking Xwayland, I could only get X to run with the source mutter, and it would draw everything unscaled for a while, then fix the scaling, and then crash. And after symlinking, the wayland session crashed eventually. So even though I didn't see any scaling improvements, it's possible that the same delay was happening, and it's due to the weird system state. Anyhow, this looks like the right fix for the immediate issue. I'll see if I can get a patched mutter installed in a more reliable way to verify things better. Oh, I also attached the gtk3-demo output above. That was run under the over-scaled setup.
Okay, I managed to put together a copr repo that has the current fedora mutter plus the patch here. With that installed, everything scales as expected. So this is the proper fix.
Review of attachment 344332 [details] [review]: Right, you fixed this in master too. Btw, while reviewing this I noticed that, in master, after the refactoring, we no longer set the scale on X since that backend never sets MetaOutput->scale .
(In reply to Dan Doel from comment #18) > Okay, I managed to put together a copr repo that has the current fedora > mutter plus the patch here. With that installed, everything scales as > expected. So this is the proper fix. Thanks a lot for testing! (In reply to Rui Matos from comment #19) > Review of attachment 344332 [details] [review] [review]: > > Right, you fixed this in master too. > > Btw, while reviewing this I noticed that, in master, after the refactoring, > we no longer set the scale on X since that backend never sets > MetaOutput->scale . I'll take a look master. I don't think we ever use the scale on X11, but better have it set to something sane than invalid. Attachment 344332 [details] pushed as d4d3dbd - monitor-manager: Get monitor info scale from main output tile