It looks like the scaling computations on wayland went wrong: https://openqa.opensuse.org/tests/487014#step/start_wayland_plasma5/27
Can you tell me if Qt_force_font_dpi is set?
(In reply to David Edmundson from comment #1) > Can you tell me if Qt_force_font_dpi is set? The previous test module sets that up, so yes: https://openqa.opensuse.org/tests/487014#step/plasma5_force_96dpi/4
One thing that's changed very recently is I have different font DPI config vars for Wayland and x. That link seemed to show X?
(In reply to David Edmundson from comment #3) > One thing that's changed very recently is I have different font DPI config > vars for Wayland and x. > > That link seemed to show X? Yes, it sets the checkbox on X so that the scale after switching to wayland is already correct.
I now have that option on X, it affects X If you set that option on wayland, it affects wayland Reasons for that in the commit; it's not something I want to undo unless we have a reason. But since ages it would default to 96dpi if this value wasn't set (so that users don't need to do this stage). The other possibility is that we're hitting wayland scaling. Easy way to tell is open xterm and see if that's also massive. It doesn't make sense as I put the requirements as being dpi > ~150 and screen vertical size >= 1440pixels it's possible the virtual screen has messed up physical size, but the mode is clearly 768px... If you can run kscreen-console outputs that would tell us.
(In reply to David Edmundson from comment #5) > I now have that option on X, it affects X > If you set that option on wayland, it affects wayland That sounds like bad design, at the very least it should tell the user in the UI. Everyone setting that option expects it to behave exactly the same on wayland. > Reasons for that in the commit; it's not something I want to undo unless we > have a reason. But since ages it would default to 96dpi if this value wasn't > set (so that users don't need to do this stage). Not true, without it set X and wayland looked slightly different, just enough for openQA to reject. > The other possibility is that we're hitting wayland scaling. Easy way to > tell is open xterm and see if that's also massive. It doesn't make sense as > I put the requirements as being dpi > ~150 and screen vertical size >= > 1440pixels > > it's possible the virtual screen has messed up physical size, but the mode > is clearly 768px... > > If you can run kscreen-console outputs that would tell us. Ok, I'll do all that and report back.
(In reply to David Edmundson from comment #5) > I now have that option on X, it affects X > If you set that option on wayland, it affects wayland > > Reasons for that in the commit; it's not something I want to undo unless we > have a reason. But since ages it would default to 96dpi if this value wasn't > set (so that users don't need to do this stage). > > The other possibility is that we're hitting wayland scaling. Easy way to > tell is open xterm and see if that's also massive. It doesn't make sense as > I put the requirements as being dpi > ~150 and screen vertical size >= > 1440pixels xterm is massive as well. > it's possible the virtual screen has messed up physical size, but the mode > is clearly 768px... > > If you can run kscreen-console outputs that would tell us. kscreen-console says: > Pos: QSize(0,0) > MMSize: QSize(0,0) > Scale: 2 > Mode: "1" > Perferred modes: () > Modes: > ... > "1": "4096x2160@60" QSize(4096,2160) 60000 So it looks like it thinks the tiny 1024x768 display is actually 4k@60Hz. Note that this hits all wayland runs in a VM (nothing unique to openQA), so it should be relatively easy to reproduce.
I just tried to force the font dpi to 96 on wayland as well, no difference at all.
Font DPI was a red herring. (though I'm 95% convinced you can remove your setting it from X) >Scale 2 is the important line. Normally, if we are on a 4k screen we do want to double everything; that's my automatic scaling detection working perfectly as intended. The part that's wrong is that we're clearly not on a 4k scene; that's our bug not the scaling. It comes from a few different parts of the stack What VM tech are you using?
(In reply to David Edmundson from comment #9) > Font DPI was a red herring. > (though I'm 95% convinced you can remove your setting it from X) Not on Plasma 5.10 yet, AFAICT the default is not 96 there. > >Scale 2 > > is the important line. > > Normally, if we are on a 4k screen we do want to double everything; that's > my automatic scaling detection working perfectly as intended. > > The part that's wrong is that we're clearly not on a 4k scene; that's our > bug not the scaling. It comes from a few different parts of the stack > > What VM tech are you using? QEMU 2.9.0 (with KVM) and virtio as VGA.
Ping. This makes wayland unusuable in VMs.
Idea for a bodge to fix the symptoms? Is the output name for a virtual screen unique? (Ie not hdmi or EDP.) It'll be in the kscreen-console output that's not included here.
Created attachment 107993 [details] Output of kscreen-console I attached the full output of kscreen-console. (This is on an older version of plasma here, but the kscreen part shouldn't matter except for Scale: 1)
Git commit 2b869e687d775ab072ef87c96c665f461df3580f by David Edmundson. Committed on 25/09/2017 at 07:47. Pushed by davidedmundson into branch 'Plasma/5.11'. Don't auto scale outputs where we don't know the physical size Summary: We don't have enough data to calculate the DPI properly and the current code effectively ends up switching based purely on resolution. Reviewers: #plasma, fvogt Reviewed By: fvogt Subscribers: plasma-devel, fvogt Tags: #plasma Differential Revision: https://phabricator.kde.org/D7980 M +4 -0 kded/generator.cpp https://commits.kde.org/kscreen/2b869e687d775ab072ef87c96c665f461df3580f
Maybe that fixed it? Can we ask you to please see if you can reproduce the issue with Plasma 5.25 or 5.26? If you can, please change the status to CONFIRMED when replying. Thanks a lot!
It's been working fine for some time. I assume at some point the edid (reading or generation?) got fixed for virtio, so kwin has the right preferred mode selected.