Windows resized after resume

[William Maddler]

it appears that upon resumung after suspend windows are being resised (to a smaller resolution) instead of keeping same posizione and size they had before suspend.

The issues seems to only happen if the laptop stays on suspend for a few hours. Windows size is being left untouched aotherwise.

ubuntu version 17.10
ubuntu-gnome-desktop 0.81

I'm on a Thinkpad T470p laptop with Intel graphic card ("VGA compatible controller: Intel Corporation Device 591b").

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: ubuntu-gnome-desktop 0.81
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Oct 23 20:18:37 2017
InstallationDate: Installed on 2017-10-19 (3 days ago)
InstallationMedia: Ubuntu-Budgie 17.10 "Artful Aardvark" - Release amd64 (20171017.1)
SourcePackage: ubuntu-gnome-meta
UpgradeStatus: No upgrade log present (probably fresh install)

[William Maddler (news-maddler)]

Sorry, forgot to add screen is a hdpi screen.

[William Maddler (news-maddler)]

Just noticed that the issue seems to be only affecting certain apps (Firefox and Tilix so far) and only if the laptop is being put to sleep closind the lid.

[Launchpad Janitor (janitor)]

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

[Matthew Stephenson (bobstay)]

I am seeing the same on my Thinkpad T570 with a 4k screen running at 1080p resolution.

[hackel (hackel)]

I've just started noticing this behaviour as well, particularly with Firefox, after switching from Wayland to Xorg on a fresh install of 17.10, gnome-shell 3.26.2-0ubuntu0.1, 1920x1080.

[Peter Ludemann (pludemann)]

I'm also seeing this with Ubuntu 16.04 and emacsclient -c (Emacs 24.5.1) on a Dell Precision Tower 3620 - Intel® HD Graphics 630 (Kaby Lake GT2), Samsun 28" monitor 3840x2160 with "Scale for menu and title bars" set to 1.5.

I did not notice this behavior in January, when I bought the workstation.

One symptom with Emacs (this doesn't happen consistently) is that the window resizes to be much wider and higher than it was before suspend.

Another recent change in behavior is that when I change the "Scale for menu and title bars" to 1.38 or 1.25, the Emacs window fills the screen -- some other apps also change, but not the same way, e.g., some get huge fonts). I'e also have problems with getting the "scale" to remain the same over suspend/resume; eventually I fixed that by doing multiple "apply"s, followed by a "Restore Previous Configuration"

[Zane Selvans (zaneselvans)]

I am experiencing this bug on Ubuntu 18.04, running on a ThinkPad T470s, after setting the 2560x1440 display resolution to 100% (no pixel doubling). It's as if while the computer has been asleep, the display has been re-sized to 200% (pixel doubled), forcing all the existing windows to be shrunk to fit.

[Mark Fickett (markfickett)]

Same symptoms as others: Firefox and terminal windows (at least) get resized after I leave my laptop lid closed and then wake it up again. I was able to reproduce the issue by closing the laptop lid for maybe 10 seconds and then opening it again.

Attached is dmesg output from the suspend/wake.

[Fedor Manin (fmanin)]

I'm having the same problem as Zane Selvans. Dell XPS9360 with 3200 x 1800 resolution.

[Benjamin Melançon (v-ben-h)]

Same experience; System76 Oryx PopOS in LoDPI mode— gvim, atom, and others were at twice the size they ought to be. Firefox wasn't resized but it crashed trying to leave this remark.

[James (james-r-barker)]

This bug affects me as well.

I have only experienced the problem with Firefox and when...
--- closing my laptop lid and later opening it.

I have NOT experienced the issue when...
--- leaving the lid open and commanding the laptop to sleep.

I tried changing my resolution and scaling but the issue remains in all scenarios below:
  Resolution 3200x1800 (native resolution and my typical resolution)
    Scaling 100%
      Gnome Tweaks > Fonts > Scaling Factor 1.50
      Gnome Tweaks > Fonts > Scaling Factor 1.00 (default)
  Resolution 2880x1620
  Resolution 2560x1440

Dell XPS 13 9360
Ubuntu 18.04

[Pen Gale (pengale)]

I am also seeing this on a Thinkpad T480 running Bionic, with X-Windows. The laptop has an Nvidia optimus card, for which I've setup proprietary drivers and prime profiles using my package manager. The problem occurs with both Intel graphics and on the Nvidia gpu.

My laptop monitor has a native resolution of 1440p, but I run it at 1080p resolution (I'm going to be very happy when and if we get 1.5x scaling enabled for Gnome3!)

Like others in this thread, the problem occurs when I resume from suspend. gdm3 is running at 1440p with 2x scaling. It seems like emacs, gnome terminal, and other affected windows are picking up an appropriate size for that as the computer resumes and unlocks ...

[Daniel Zabari (danieldaz)]

I'm seeing this on my Lenovo Thinkpad X1 Carbon. The window resizes very strangely, like it's zoomed in at the top left corner and then a normal size along the rest of the screen. Definitely happens with nautilus and default document viewer. Happens when I close the lid and reopen it. I attached a screenshot, figure we may as well have one.

[reliable-robin-22 (nicolasdiogo)]

I have a Thinkpax X1 carbon gen 4 - and this is happening to me as well.

[Peter Haight (peterh-sapros)]

I was also having this problem on a System 76 laptop using Wayland with a hidpi screen (3200x1800) and scaling set to 150%. I was able to fix it by doing:
gsettings set org.gnome.desktop.interface scaling-factor 1

https://askubuntu.com/questions/1073568/preventing-window-resizing-after-resume

[Robert Altshuler (raltshuler)]

Running the command @peteh-sapros suggested fixed the problem for me as well (Lenovo X1 carbon 5th gen, Ubuntu 18.04).

[Yonatan Yehezkeally (yonatany)]

I have this issue on a desktop connected to a Dell 28" at a resolution of 3840x2160 and scale of 200%. Running `gsettings set org.gnome.desktop.interface scaling-factor 1` (or `2`) doesn't do the trick.

[gpothier (gpothier)]

Same thing here. Here are before/after screenshots.

[Matthew Wark (mtwark)]

Having the same issue here on a Dell Inspiron both when witha 4k display running at 1080p. Bug shows up with intel or nvidia graphics enabled.

[Jerome Covington (jeromecovington)]

Thinkpad X1 Carbon gen3, Ubuntu 19.04 same issue here as Daniel Zabari (danieldaz).

[Jerome Covington (jeromecovington)]

Actually `gsettings set org.gnome.desktop.interface scaling-factor 1` appears to have done the trick!

[Alan Mimms (alanm-unforgettable)]

I can confirm for Ubuntu 19.10 doing

`gsettings set org.gnome.desktop.interface scaling-factor 1`

has resolved my issue with Terminal windows on my Dell XPS13 set to 1920x1080 when the native LCD is capable of 3200x1800. I now have 100% scaling in the Display control panel thingie and my Terminal windows don't resize on their own after closing the lid and reopening.

Thanks for the tip.

[Nir Yeffet (nir-launchpad-net-8ff8)]

Confirming that executing

`gsettings set org.gnome.desktop.interface scaling-factor 1`

has resolved the same issue on Macbook pro 13" 2016 running Ubuntu 19.10.

[Matthew Weier O'Phinney (mweierophinney)]

This was affecting me both when resuming from suspend, as well as when resuming from lock screen. I'm running a Dell XPS 13 9370 under Ubuntu 19.10, with two UHD displays connected via a dock. I wasn't necessarily seeing screen resizing so much as anything on a secondary screen was being closed.

After calling `gsettings set org.gnome.desktop.interface scaling-factor 1`, everything works normally for both resume and unlock operations, and all windows previously in use are still present.

[Tim Lunn (darkxst)]

Ubuntu 17.10 (artful) reached end-of-life on July 19, 2018.

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

[Launchpad Janitor (janitor)]

[Expired for ubuntu-gnome-meta (Ubuntu) because there has been no activity for 60 days.]

[Erik Steiner (estebanium)]

I can confirm, that this bug still exists on Ubuntu 20.04. I recently switched to Manjaro (currently 20.1.1) with the same behavior.

Set the monitor to power save after 5 minutes.
Desktop resolution is 3840x2160 with 200 % scaling.

If I come back after some time. I move the mouse and the logon screen appears. I enter my password and I see File Manager (Files, Simple file manager for GNOME) and Firefox are resized. For instance the File Manager just shows the left half of the window, the other half is out of the screen. You can not see the Minimize/Maximize/Close buttons. Firefox looks strange as it is resized by some more factors. Want to contribute as it is pretty reproducible.

[Grzegorz Daniluk (dgregd)]

Some version of that bug exists on Ubuntu 20.04 as well. I have a 4k monitor and I have set the display scale to 200% in the Ubuntu Settings. After the monitor sleep/resume, the Google Chrome window scaling is wrong. The size of the window is the same as it was before but the contents is drawn with 100% scaling. I mean the fonts are very small. After the window is moved, the scaling is corrected to 200%. I even don't have to restart the Chrome, just a simple move or resize window operation fixes the problem.

[Nicholas Stommel (nstommel)]

This bug needs to be reopened, I have the same issue on Ubuntu 20.10 with a 4K laptop screen with 2x scaling. The same problem is found on Fedora 33. As @estebanium wrote, If the lid is closed to suspend, when the laptop is reopened, maximized windows are instead offscreen (only left half shows). Very annoying, the only solution is to manually suspend before closing the lid. This bug appears to be a Gnome/metacity problem and has persisted since 2017. Really needs a fix soon.

[William Maddler (news-maddler)]

After 4 years, there's little hope for this to get fixed.
I just stopped using Gnome, having to resize every single window on resume
is just crazy.

On 18 April 2021 23:35:45 Nicholas Stommel <email address hidden> wrote:

> This bug needs to be reopened, I have the same issue on Ubuntu 20.10
> with a 4K laptop screen with 2x scaling. The same problem is found on
> Fedora 33. As @estebanium wrote, If the lid is closed to suspend, when
> the laptop is reopened, maximized windows are instead offscreen (only
> left half shows). Very annoying, the only solution is to manually
> suspend before closing the lid. This bug appears to be a Gnome/metacity
> problem and has persisted since 2017. Really needs a fix soon.
>
> ** Changed in: ubuntu-gnome-meta (Ubuntu)
> Status: Expired => Confirmed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1726548
>
> Title:
> Windows resized after resume
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-meta/+bug/1726548/+subscriptions

[Milind V Purohit (mvpurohit57)]

I've had this issue for as long as I've had Ubuntu 20.04, which is about a year now. Having to re-size all terminal windows after suspend is distracting and takes time. Does anyone have a solution?

[Lance Tien (lance6716)]

confirmed in ubuntu 18 lts and 20 lts. I'll try `gsettings set org.gnome.desktop.interface scaling-factor 1` to see if it works.

updated: not worked

[Rael Gugelmin Cunha (rael-gc)]

On 22.04, I'm having this issue on Firefox in my desktop. After the display goes off, due Gnome power management, and I resume login, Firefox window is placed at the right bottom of the screen, in a minimal size.

[UsemosLinux (pablo-castagnino)]

confirmed in ubuntu 23.04. Same as previous comment: after the display goes off, due Gnome power management, and I resume login, windows are placed at the right bottom of the screen, in a minimal size.

[Jens Glathe (glathe)]

Confirm on Ubuntu 23.04, with quite odd results.

- Screen is attached via DisplayPort (to MiniDP on the box)
- trying to sleep for the Monitor most of the time goes okay
- reawakening puts the whole desktop into a small rectangle (top left corner) or with very low res (1024x768?) over the whole screen. Switching VTs doesn't resolve it.

One additional data point: This started with connecting the right GPIO to the Display Port in the DTS file (the box is Windows Dev Kit 2023, ARM64). Before this, wakeup worked with the right resolution, but unresposive (mouse stuck). Switching VT revived the session.

This is the dmesg -W from the wakeup:

[ 5903.388522] Console: switching to colour frame buffer device 80x30
[ 5903.388537] msm_dpu ae01000.display-controller: [drm] fb0: msmdrmfb frame buffer device
[ 5935.605411] audit: type=1400 audit(1690982650.836:68): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/19459/usr/lib/snapd/snap-confine" pid=4354 comm="snap-confine" capability=12 capname="net_admin"
[ 5935.605419] audit: type=1400 audit(1690982650.836:69): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/19459/usr/lib/snapd/snap-confine" pid=4354 comm="snap-confine" capability=38 capname="perfmon"
[ 5935.702043] event_q is full: pndx=0 gndx=1
[ 5938.771963] event_q is full: pndx=2 gndx=3
[ 5940.414504] event_q is full: pndx=7 gndx=0
[ 5955.299032] event_q is full: pndx=2 gndx=3
[ 5955.319046] event_q is full: pndx=2 gndx=3
[ 6027.273560] event_q is full: pndx=4 gndx=5
[ 6028.478737] event_q is full: pndx=5 gndx=6
[ 6073.971299] event_q is full: pndx=4 gndx=5
[ 6076.535566] audit: type=1400 audit(1690982791.760:70): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/19459/usr/lib/snapd/snap-confine" pid=4817 comm="snap-confine" capability=12 capname="net_admin"
[ 6076.535582] audit: type=1400 audit(1690982791.760:71): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/19459/usr/lib/snapd/snap-confine" pid=4817 comm="snap-confine" capability=38 capname="perfmon"
[ 6076.633963] event_q is full: pndx=2 gndx=3

and this is the dmesg regarding display:

sudo dmesg|grep display
[ 2.154537] msm-mdss ae00000.display-subsystem: Adding to iommu group 5
[ 2.208948] platform ae90000.displayport-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/display-controller@ae01000/ports/port@0/endpoint
[ 2.263689] platform ae98000.displayport-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/display-controller@ae01000/ports/port@4/endpoint
[ 2.294782] platform ae9a000.displayport-controller: Fixed dependency cycle(s) with /dp2-connector/port/endpoint
[ 2.294798] platform ae9a000.displayport-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/display-controller@ae01000/ports/port@6/endpoint
[ 2.347632] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with ae90000.displayport-controller
[ 2.359000] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with ae98000.displayport-controller
[ 2.378904] msm_dpu ae01000.display-controller: bound ae90000.displaypor...

[Jens Glathe (glathe)]

add some data with drm.debug=0x02, unplug/replug event on the display port:

sudo dmesg -W
[ 100.778637] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes
[ 107.863951] [drm:msm_fbdev_create [msm]] create fbdev: 640x480@32 (640x480)
[ 107.864074] [drm:msm_alloc_stolen_fb [msm]] allocating 1228800 bytes for fb 0
[ 107.864583] [drm:msm_fbdev_create [msm]] fbi=0000000043985575, dev=00000000597e5822
[ 107.864631] [drm:msm_fbdev_create [msm]] par=00000000c01b95f8, 640x480
[ 107.864651] [drm:msm_fbdev_create [msm]] allocated 640x480 fb
[ 107.865595] Console: switching to colour frame buffer device 80x30
[ 107.865616] msm_dpu ae01000.display-controller: [drm] fb0: msmdrmfb frame buffer device

It looks like the first event (cannot find crtc data) is the culprit in my case.

[Jens Glathe (glathe)]

An update from my POV, and a possible trace: I played around a lot with drm.debug (best use for this case is apparently 0x106), and eventually deliberately disabled the HPD gpio in the device tree (Windows Dev Kit 2023). This changes the behaviour to sleep/resume works, but with a hang of ~30 secs until the screen gets responsive again. Everything works, only indication in dmesg is this message:

[42858.743906] [drm:dp_aux_isr [msm]] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy

which in itself is pretty ambiguous. DP AUX is one of the interrupt handlers that get called from the gpu interrupt or the HPD interrupt handler (now disabled) and appears to be a case that has no explicit handling, but an explicit WARN coding. For me this looks like a race condition worsened by the HPD interrupt handler, and things from user space (Wayland) and kernel (DP link status). Without HPD, you can see that the right EDID gets detected again, an link training starts, link gets enabled eventually. With HPD it looks like the former gets triggered twice, invalidating EDID data, leading to default CRT modeline (640x480). Pretty odd.

[Siavash Safi (hosted-run)]

I'm experiencing same issue with Evolution, Firefox and Tilix on Gnome Desktop on Arch Linux, so I assume this is an upstream bug.