Gnome resizes framebuffer when playing fullscreen video over and over again (when using X11 fractional scaling)

Bug #1862081 reported by Jonas Jelten
90
This bug affects 19 people
Affects Status Importance Assigned to Milestone
mutter (Ubuntu)
Fix Released
High
Marco Trevisan (Treviño)

Bug Description

When I play a video with mpv (or e.g. Firefox), it works just fine.

When this video is fullscreened (e.g. in mpv by pressing f), the screen quickly turns off, and switches resolution modes in such a rate the screen is unusable.

The native resolution of the screen is 1440p, but Xorg somehow increases the size to 3424x1926 for the fullscreen, then quickly switches back to 1440p, before increasing it again.

As soon as the video is de-fullscreened (by pressing f again in mpv, or esc in Firefox), the funny resolution switching stops and the system is usable again.

This also happens with the modesetting 2d-driver. This does not happen with Wayland.

This can be seen in the Xorg-log:
[ 20.215] (II) intel(0): EDID vendor "JDI", prod id 0
[ 20.215] (II) intel(0): Printing DDC gathered Modelines:
[ 20.215] (II) intel(0): Modeline "2560x1440"x0.0 245.12 2560 2608 2640 2720 1440 1443 1449 1502 +hsync -vsync (90.1 kHz eP)
[ 258.869] (II) intel(0): resizing framebuffer to 3424x1926
[ 258.905] (II) intel(0): switch to mode 2560x1440@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[ 268.955] (II) intel(0): resizing framebuffer to 2560x1440
[ 269.097] (II) intel(0): switch to mode 2560x1440@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[ 270.383] (II) intel(0): resizing framebuffer to 3424x1926
[ 270.400] (II) intel(0): switch to mode 2560x1440@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[ 271.852] (II) intel(0): resizing framebuffer to 2560x1440
[ 271.858] (II) intel(0): switch to mode 2560x1440@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none
[ 273.294] (II) intel(0): resizing framebuffer to 3424x1926
[ 273.314] (II) intel(0): switch to mode 2560x1440@60.0 on eDP1 using pipe 0, position (0, 0), rotation normal, reflection none

When the resolution is increased, the Kernel complains about the framebuffer size:

[ 269.830034] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu13
ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
Uname: Linux 5.4.0-12-generic x86_64
ApportVersion: 2.20.11-0ubuntu16
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Thu Feb 6 00:00:07 2020
DistUpgraded: 2020-02-05 22:21:13,002 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py'
DistroCodename: focal
DistroVariant: ubuntu
DpkgLog:

ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller])
   Subsystem: Lenovo UHD Graphics 620 [17aa:2259]
MachineType: LENOVO 20LES01W00
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-12-generic root=/dev/mapper/hostname-ubunturoot ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: Upgraded to focal on 2020-02-05 (0 days ago)
dmi.bios.date: 11/27/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N25ET52W (1.38 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20LES01W00
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 31
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN25ET52W(1.38):bd11/27/2019:svnLENOVO:pn20LES01W00:pvrThinkPadX1Yoga3rd:rvnLENOVO:rn20LES01W00:rvrNotDefined:cvnLENOVO:ct31:cvrNone:
dmi.product.family: ThinkPad X1 Yoga 3rd
dmi.product.name: 20LES01W00
dmi.product.sku: LENOVO_MT_20LE_BU_Think_FM_ThinkPad X1 Yoga 3rd
dmi.product.version: ThinkPad X1 Yoga 3rd
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.100-4
version.libgl1-mesa-dri: libgl1-mesa-dri 19.3.3-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.7-2ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

Revision history for this message
Jonas Jelten (jonas-jelten) wrote :
summary: - xorg resizes framebuffer when playing fullscreen video
+ xorg resizes framebuffer when playing fullscreen video over and over
+ again
description: updated
Revision history for this message
Jonas Jelten (jonas-jelten) wrote : Re: xorg resizes framebuffer when playing fullscreen video over and over again

It seems to be caused by fractional display scaling: The display is configured to use 150% scaling.

When the scaling is set to 100% (native DPI), mpv and Firefox can play the video in fullscreen without triggering the bug, everything fine just like it should be.

When the scaling is set to 200%, there's another bug: The player goes to fullscreen without flicker or framebuffer changes, but only plays the video in the upper left quarter of the screen. The other three quarters are not updated and keep the buffer data from the point where the fullscreen was invoked.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thanks for the bug report. I think this is related to a family of scaling bugs in gnome-shell I've only discovered recently:

https://gitlab.gnome.org/GNOME/mutter/merge_requests/1004
https://gitlab.gnome.org/GNOME/mutter/issues/849

Those are not this bug, but I think it's related whereby display scaling is confusing mutter/gnome-shell into creating textures of the wrong size.

affects: xorg (Ubuntu) → mutter (Ubuntu)
summary: - xorg resizes framebuffer when playing fullscreen video over and over
+ Gnome resizes framebuffer when playing fullscreen video over and over
again
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: Gnome resizes framebuffer when playing fullscreen video over and over again

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mutter (Ubuntu):
status: New → Confirmed
summary: Gnome resizes framebuffer when playing fullscreen video over and over
- again
+ again (when using X11 fractional scaling)
tags: added: xrandr-scaling
no longer affects: mutter
Revision history for this message
pheidrias (5-launchpad-net-pheidrias-info) wrote :

I'd like to add that the problem doesn't occur, when there is another (pinned) window in the foreground! E.g., open a terminal and make it to stay "on top" and the video plays fine in fullscreen mode (behind the terminal).

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

That would probably be because a window in the foreground prevents fullscreen unredirect from being used.

I suggest if you need both fullscreen window support and fractional scaling then logging into "Ubuntu on Wayland" might be a better option right now.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Though if you use "Ubuntu on Wayland" then you need to set:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Revision history for this message
pheidrias (5-launchpad-net-pheidrias-info) wrote :

Hello Daniel,

I'd love to use Wayland - but the graphics are worse. Even in unscaled mode, there is horrible text-rendering and when scaling, some apps go blurry (I know,that this can be handled for e.g. firefox - but there are other apps, which aren't "fixed")...

Would it be a workaround to have a one-pixel-sized (maybe even transparent?) always-on-top app without window decorations etc., which you would place somewhere "out-of-sight", like a corner?
Is something like this maybe already available?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It sounds like fixing this bug is the least difficult issue. It also sounds like you should subscribe to bug 1825625.

Your suggestion of a workaround for this bug is not necessary because with the same amount of effort we could just write a patch to disable fullscreen unredirect during fractional scaling, to work around this bug. Or fix it properly somehow.

Revision history for this message
pheidrias (5-launchpad-net-pheidrias-info) wrote :

Okay...so there is hope to get this at least "bypassed" for 20.04 - this would be awesome!

btw: before this became a regular problem (don't ask me when - but I didn't have this problem some 2-3 month before), I had this effect when I detached my keyboard from my 2-in-1 Toshiba z20t-c. Interestingly, the keyboard should only add a second battery to the computer (and the keyboard + trackpad). I don't understand, why this triggered this strange fullscreen-video-behaviour -> I wouldn't attribute it to some energy-management, as the problem persisted when attaching the power cable directly to the PC...

Revision history for this message
Ksawery Wieczorkowski-Rettinger (ksawery) wrote :

I'm having the exact same issue, it's also caused by 150% fractional scaling in my case. I'm also noticing a lot of screen tearing when playing videos. All problems (resolution switching and screen tearing) disappear when I revert the scaling to 100%.

Changed in mutter (Ubuntu):
importance: Undecided → High
tags: added: champagne rls-ff-incoming
Revision history for this message
Ksawery Wieczorkowski-Rettinger (ksawery) wrote :

The screen tearing that I mentioned happens when playing videos in VLC and mpv Media Player (with 150% fractional scaling). It occurs when using the applications in windowed mode (since fullscreen mode causes the resolution switching bug). I'm assuming the same problem will also occur in other media players.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Please don't discuss screen tearing here. That is bug 1846398 and/or bug 1754284.

Changed in mutter (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: Confirmed → Triaged
tags: added: rls-ff-tracking
removed: rls-ff-incoming
Changed in mutter (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Jonas Jelten (jonas-jelten) wrote :

Thanks! Would you mind sharing the commit that fixed the bug?

Revision history for this message
Vlad Svitlichniy (vsv-dev) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mutter - 3.36.1-3ubuntu1

---------------
mutter (3.36.1-3ubuntu1) focal; urgency=medium

  * Merge with debian, with new upstream releases and cherry-picked fixes:
    - Screens turn off when setting display scaling to 200% (LP: #1869750)
    - Use hardware cursor for DisplayLink devices (LP: #1867757)
    - Fix popup menus with using focus-follow-mouse (LP: #1871107)
    - Window manager key events are sent to the terminal (LP: #1866094)
    - Ensure assertion 'window->unmanaging || workspace != NULL' (LP: #1864326)
    - Shell crash on meta_wayland_surface_role_get_window (LP: #1869837)
  * d/p/x11-Add-support-for-fractional-scaling-using-Randr.patch:
    - Refreshed to respect upstream changes
    - Fixed a bug causing windows using direct-rendering to be continuously
      resized, keeping ability to use shell UI (LP: #1862081)
  * Remaining changes with debian:
    - debian/control:
      + Update VCS flags to point to ubuntu salsa branch
    - debian/gbp.conf: update branch to point to ubuntu/master
    - debian/patches/x11-Add-support-for-fractional-scaling-using-Randr.patch:
      + X11: Add support for fractional scaling using Randr

mutter (3.36.1-3) experimental; urgency=medium

  * Team upload
  * Update to upstream gnome-3-36 branch, commit 3.36.1-16-gdb164bcfa
    - Fix a crash during X11 drag-and-drop, for example when dragging
      a JPEG file onto GIMP's splash screen
    - Fix a crash in X11 input device handling
    - Translate coordinates of absolute input devices for rotated screens

mutter (3.36.1-2) experimental; urgency=medium

  * Team upload
  * Standards-Version: 4.5.0 (no changes required)
  * d/copyright: Consolidate entries and update
  * Update to upstream gnome-3-36 branch, commit 3.36.1-13-gbc47f0a1a

mutter (3.36.1-1) experimental; urgency=medium

  * Team upload
  * New upstream release
  * d/copyright: Update
  * Refresh patches
  * Update symbols file.
    Note that this includes ABI breaks: some symbols that are only used
    internally have disappeared from mutter's private fork of Clutter and
    Cogl. The only user of this version of mutter is GNOME Shell, which
    does not use these symbols.
  * d/patches: Update from gnome-3-36 branch up to 3.36.1-8-ge339a57dd
  * d/p/clutter-stage-Don-t-assume-stage-relayouts-reallocate-eve.patch:
    Add patch proposed upstream to fix a gnome-shell crash with the
    "Native window placement" extension.

 -- Marco Trevisan (Treviño) <email address hidden> Thu, 09 Apr 2020 14:40:58 +0200

Changed in mutter (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Vlad Svitlichniy (vsv-dev) wrote :

Thank you for the fix!
After having my mutter updated, I can finally watch the fullscreen videos while having the fractional scaling enabled

However, there is one minor issue. Whenever I switch to the fullscreen mode, the scaling factor is changed from 150% to 200%, so all the widgets are unnecessarily large. This isn't a deal breaker for me, because I use the fullscreen mode only for watching the videos; I just wanted to confirm that it's the intended behavior

Revision history for this message
Ksawery Wieczorkowski-Rettinger (ksawery) wrote :

Thank you for your work on the issue. How can I update to the new version? I ran all package updates and upgrades in Ubuntu, but my version of mutter is still 3.43.3.

Regards
Ksawery

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

Vlad,

So, when full screen videos or games are played what we do is disabling the down-scaling everywhere (as to scale at 150% we've to scale everyting at 200% and then scale it down again), not to affect the performances, however this could be probably applied just to the monitor that is full-screen.

Before we were setting the scale back to 100%, but this was causing some relayouting that I would consider worse in general, as if a monitor is scaled up, it's better to have bigger widgets than smaller.

I need to look at this a bit further, feel free to open another bug.

Ksawery, 3.43.3? How is it possible? That version doesn't exist :)

Revision history for this message
Sebastian Astra (legol2) wrote :

The bug still persists for factorial scaling, for example 125%

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This bug is closed. If you have any ongoing problems then please open a new bug by running:

  ubuntu-bug mutter

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Continued in bug 1890141.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.