Created attachment 1667283 [details]
system logs

Proposed as a Blocker and Freeze Exception for 32-beta by Fedora user mikhail using the blocker tracking app because:

 3.35.92-1 version of gnome-shell is a big disaster for users of 4K monitors.
This update made the system completely unworking on 4K monitors and break hardware acceleration and Wayland.

Can't be a release blocker yet, since 3.35.92 is not in the Beta yet. It's in updates-testing.

I think you need to grab mutter-3.35.92-2.fc33 which should fix this. The 3.35.92 megaupdate already includes the fixed mutter build. You are on rawhide so you have a bit different versions.

(In reply to Kalev Lember from comment #4)
> I think you need to grab mutter-3.35.92-2.fc33 which should fix this. The
> 3.35.92 megaupdate already includes the fixed mutter build. You are on
> rawhide so you have a bit different versions.

Thanks, after upgrade mutter to 3.35.92-2.fc33 all described issues was gone.

The first problem still reproduces in X11 session.

$ rpm -qa | grep mutter
mutter-debugsource-3.36.0-1.fc33.x86_64
mutter-debuginfo-3.36.0-1.fc33.x86_64
mutter-3.36.0-1.fc33.x86_64


$ rpm -qa | grep gnome-shell
gnome-shell-extension-window-list-3.36.0-1.fc33.noarch
gnome-shell-debuginfo-3.36.0-3.fc33.x86_64
gnome-shell-extension-horizontal-workspaces-3.36.0-1.fc33.noarch
gnome-shell-3.36.0-3.fc33.x86_64
gnome-shell-extension-common-3.36.0-1.fc33.noarch
gnome-shell-debugsource-3.36.0-3.fc33.x86_64
gnome-shell-extension-apps-menu-3.36.0-1.fc33.noarch
gnome-shell-extension-places-menu-3.36.0-1.fc33.noarch
chrome-gnome-shell-10.1-7.fc32.x86_64
gnome-shell-extension-launch-new-instance-3.36.0-1.fc33.noarch

Proposed as a Blocker for 32-final by Fedora user tuna using the blocker tracking app because:

 Really bad user experience.

Just tested this on AMD Polaris (RX 580). So, whenever you have 4k with scaling on GNOME Xorg session, I get video output only to either 1/4 or 1/2 of the displays. This happens to both FHD and 4k displays, if I set scaling on the 4k display.

I just tested this on Intel i7-8650U (Kaby Lake R with UHD 620), GNOME session works as expected without problems (both Wayland and Xorg, 100% and 200% scaling).

mutter-3.36.0-1.fc32.x86_64
nome-shell-3.36.0-3.fc32.x86_64

Discussed during the 2020-03-23 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as the remaining issue here is 4K display on X11 not working properly. This would be a significant issue if it affects a reasonable range of hardware. We will send out a call for people to test 4K-on-X11 on various graphics hardware and see how widespread the issue is.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-23/f32-blocker-review.2020-03-23-16.00.txt

Frantisek: can I ask you to clarify this a bit: "This happens to both FHD and 4k displays, if I set scaling on the 4k display"?

I guess you meant "This happens to both FHD and 4k displays, if I set scaling on the FHD display", right? i.e. it happens on 4k display by default because scaling is automatically enabled, but you found the bug also happens on an FHD display if you enable scaling manually, thus suggesting the bug is with scaling not with the 4k resolution?

I think this may be https://gitlab.gnome.org/GNOME/mutter/-/issues/1128 (but it's hard to tell thats a bit of a train wreck)

If so, it would already have an upstream fix.

I had seen that, and I don't *think* it is. At least, most or all of the affected people in that bug appeared to be using NVIDIA adapters with the proprietary driver (the strings 'amd' and 'radeon' do not appear in that issue at all), and their symptom was that affected displays were *entirely* (not just partially) blank. I suppose it's possible the same changes will fix both bugs, but they do seem to be different on the face of it.

Answering the call for testing sent to desktop@.

RPM Versions:
gnome-shell-3.36.0-3.fc32.x86_64
mutter-3.36.0-1.fc32.x86_64
(Fedora 32 Silverblue)

GPU: Intel Corporation UHD Graphics 630 (Mobile) + NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q]
Drivers: mesa + binary NVidia
Display: 3480x2190

Testing GNOME-on-X11 (Wayland is disabled with the NVidia drivers):

- Out of the box (no monitors.xml), the display is correct (full) and scaled at 100%
- I can change the scaling, and the display is still correct at the new scaling.

If I change the underlying resolution to 1920x1080, then I experience the bug: only a quarter of the screen is visible.
Changing it back has no effect, until monitors.xml is removed and the session restarted. Restarting the shell is not enough.

During the bug, xrandr says:
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 344mm x 194mm

That is, mutter is programming a 1920x1080 framebuffer for a 3840x2160 monitor.
This is not a GPU or driver specific bug, I think.

I am not seeing this running qtile with nvidia graphics (nouveau)

(In reply to Adam Williamson from comment #11)
> Frantisek: can I ask you to clarify this a bit: "This happens to both FHD
> and 4k displays, if I set scaling on the 4k display"?
> 
> I guess you meant "This happens to both FHD and 4k displays, if I set
> scaling on the FHD display", right? i.e. it happens on 4k display by default
> because scaling is automatically enabled, but you found the bug also happens
> on an FHD display if you enable scaling manually, thus suggesting the bug is
> with scaling not with the 4k resolution?

Hmm, so. By default, I have one FullHD and one 4k display. Scaling is not enabled on any of them. Then, if I set scale to... say 200 % on the 4k display, the video gets cut and only 1/4 or 1/2 of displays is filled. I didn't set any scaling on FUllHD display, will try it soonish.

*** Bug 1814205 has been marked as a duplicate of this bug. ***

Reproduced on AMD gfx card (radeon rx 570) with FOSS drivers (Bug 1814205). Can't reproduce with any Intel card HD (620/630).

(In reply to Martin Stransky from comment #18)
> Reproduced on AMD gfx card (radeon rx 570) with FOSS drivers (Bug 1814205).
> Can't reproduce with any Intel card HD (620/630).

Err, sorry, actually I can reproduce it also on Intel - Dell XPS 15, Intel HD 630, Fedora 32.

So, there's also this upstream issue:

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2442

both issues are reported to be Mysteriously Fixed (TM) in latest mutter master, so I'll do a scratch build of that and ask folks to try it out.

OK, here's the scratch build of mutter:

https://koji.fedoraproject.org/koji/taskinfo?taskID=42742364

can folks who could reproduce some version of this bug please try it out and report back whether it solves the problem? Thanks!

(In reply to Adam Williamson from comment #21)
> OK, here's the scratch build of mutter:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42742364
> 
> can folks who could reproduce some version of this bug please try it out and
> report back whether it solves the problem? Thanks!

So, it fixes the issue but makes it impossible to set different scales in for different displays on X11. Doesn't break anything on Wayland (even per display scale continues to work just fine there).

IDK if that's desired.

(In reply to František Zatloukal from comment #22)
> (In reply to Adam Williamson from comment #21)
> > OK, here's the scratch build of mutter:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=42742364
> > 
> > can folks who could reproduce some version of this bug please try it out and
> > report back whether it solves the problem? Thanks!
> 
> So, it fixes the issue but makes it impossible to set different scales in
> for different displays on X11. Doesn't break anything on Wayland (even per
> display scale continues to work just fine there).
> 
> IDK if that's desired.

Different scale on different monitors is X11 has never worked in Fedora or GNOME. There is no sane way to do that on X11.

(In reply to Jonas Ådahl from comment #23)
> Different scale on different monitors is X11 has never worked in Fedora or
> GNOME. There is no sane way to do that on X11.

Okay, I wasn't sure, so in this case, it's fixed, thanks!

Created attachment 1673198 [details]
Proof that issue still not fixed

I am couldn't confirm that issue was fixed with latest mutter-3.36.0-2.fc33.x86_64 build.

That's not the build I asked you to test. I asked for testing of https://koji.fedoraproject.org/koji/taskinfo?taskID=42742364 . That is versioned mutter-3.36.1-0.20200324git7fa7c2a.1.fc32.

Created attachment 1673200 [details]
Now all looking good with mutter-3.36.1-0.20200324git7fa7c2a.1.fc32

Oh sorry, my fault, I downloaded from koji the other version of mutter.
With mutter-3.36.1-0.20200324git7fa7c2a.1.fc32 all looking good, except playing 4K videos in Totem player, but this is yet another known issue: https://gitlab.gnome.org/GNOME/clutter-gtk/-/issues/6

OK, sent out https://bodhi.fedoraproject.org/updates/FEDORA-2020-9ca13f551b as an official update bumped to latest git master (by backporting all patches rather than changing the tarball, but result should be the same). Please confirm and karma it, thanks!

FEDORA-2020-9ca13f551b has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9ca13f551b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9ca13f551b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

mutter-3.36.0-3.fc32 fixes the issue.

FEDORA-2020-9ca13f551b has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.