Lid Close Suspend causes Graphical glitches

So all weekend I have been trying to solve this problem and went as far as disabling the lid close acpi state via upower and while that prevents sleep and the graphical glitches that is not a solution. (I lose my scaling every time and restoring the scaling when I log back in sometimes leaves artifacts.)

I want my system properly going to sleep without seeing this in my log - clearly something is dropping out with my display on the lid close acpi state that does not occur when I initiate a sleep to mem manually, of which I have tried 3 different methods to go to sleep, normal UI methods and terminal and they all work fine.

These are the type of errors I see in my log when the lid initiates the sleep. I’ve tried adding a script to initiate a normal sleep command like systemctl suspend - but it does not take this far.
gsd-color[1077]: failed to get edid: unable to get EDID for output

The closest solution I have come up with is leave the lid acpi detection enabled via upower and another config file but have it do nothing - but it still screws around with my EDID stuff and display. It loses the xrandr customization I have made, and I can even initiate a script to go in and fix that but then when it tries to execute “systemctl suspend” that fails. I’d really just like to prevent the EDID from dropping out when I am closing the lid. Is this possible, or is there something hardcoded in the Budgie Desktop that is firing off when the lid is closing & thus causing EDID/display issues?

I can safely say no - the desktop devolves all handling of this sort of stuff to gnome-settings-daemon/mutter and SystemD.

To backup slightly - please can you describe your setup in terms of

  • UB version (20.04?),
  • kernel (uname -a),
  • graphics driver (intel, amd, nvidia?),
  • any proprietary graphics driver in play?

You mentioned scaling. Is this fractional scaling or 100%/200% type of scaling?

You mentioned some-sort of xrandr customization - what is this and why? Do you see graphical glitches when xrandr customisation is removed?

Does just restarting the window manager clean on resume help/hinder/do nothing? i.e. nohup budgie-wm --replace &

Yes, I’m on the latest official release of UB 20.04.

uname -a
Linux UB2004-EBX3 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

grep ‘Setting driver:’ /var/log/Xorg.0.log
[ 9.665] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20200515

These are the scaling settings I am using on a 13" 1920x1080 display.

gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "[{'Gdk/WindowScalingFactor', <2>}]"
gsettings set org.gnome.desktop.interface scaling-factor 2
xrandr --output eDP1 --scale 1.6x1.6

Xrandr handles the fractional scaling and performs extremely well - but the moment the lid closes everything goes to hell. At first I thought maybe it was gnome-screensaver or the greeter lockscreen - but this gets triggered even if those things are not triggered. I have been able to remove suspend or any type of lockscreen but the reversion of my xrandr scale command still happens. I am left on my hugely oversized laptop at a full scale of 2. I can rescale it but then I introduce artifacts that requiring moving or resizing my windows - even then if you go through enough of these cycles you risk instability and the entire system rebooting or the artifacts around the edges of the windows increasing even after resizing or moving the window.

I really do need to find a resolution to this problem as it can lead to system instability and restarting the window manager via nohup budgie-wm --replace & has already been performed - it does not clean up the artifacts at all.

This command tends to quickly do the cleanup for me - I trigger the Window shade and toggle it, and to be honest - if all of this losing of xrandr scale and re-applying didn’t eventually lead to system instability then I would just work around the issue, but I would like to solve why xrandr is being undone on lid close.

wmctrl -l|awk '{$3=""; $2=""; $1=""; print $0}'| xargs -I % sh -c '{ wmctrl -r "%" -b toggle,shaded; sleep 0.1; wmctrl -r "%" -b toggle,shaded; }'

The 2 file names I modified, below, to make sure the system does not go to sleep, and I really do have to modify both - because if I just update logind.conf it may not go to sleep/suspend, but it will still lose xrandr 1.6x1.6 scaling on closing the lid. UPower appears to disable the acpi notification of the lid close altogether so that does stop the problem from happening on lid close - but I still want the lid close to trigger the sleeping and just remove whatever power management thing may be happening that is causing the screen to lose xrandr scaling.

/etc/systemd/logind.conf
/etc/UPower/UPower.conf

I want the system to simply trigger “systemctl suspend” when I close the lid - not whatever it is that it is actually doing. I have already scripted a solution to trigger a sh script on lid close but it doesn’t help because something else is still being triggered. As long as I suspend it manually via the UI everything appears to work fine, so something in the suspend process of lid close is being problematic and I don’t think it is hardware/BIOS related. It feels like a software problem.

UPDATE: Confirming that no other acpi events are happening.

$ acpi_listen     
button/lid LID close
button/lid LID open

If the device is disconnecting I am not seeing it…

while sleep .1; do xrandr | grep "eDP1 disconnected"; done

xrandr -q

xrandr -q
Screen 0: minimum 8 x 8, current 3072 x 1728, maximum 32767 x 32767
eDP1 connected primary 3072x1728+0+0 (normal left inverted right x axis y axis) 294mm x 165mm
   1920x1080     60.00*+  59.93  
   1680x1050     59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1600x900      60.00    59.95    59.82  
   1280x1024     60.02  
   1440x900      59.89  
   1400x900      59.96    59.88  
   1280x960      60.00  
   1368x768      60.00    59.88    59.85  
   1360x768      59.80    59.96  
   1280x800      59.81    59.91  
   1152x864      60.00  
   1280x720      59.86    60.00    59.74  
   1024x768      60.00  
   1024x576      60.00    59.90    59.82  
   960x540       60.00    59.63    59.82  
   800x600       60.32    56.25  
   864x486       60.00    59.92    59.57  
   640x480       59.94  
   720x405       59.51    60.00    58.99  
   640x360       59.84    59.32    60.00  
HDMI1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

This is the lid open and close script I have and it works fully, but yes the xrandr scale drops out still. I know this scripts works for triggering what I do want because I can set it to play sounds when I open or close the lid just fine.

The biggest mystery to me is why the EDID is dropping out on lid close. If I solve this then the issue will be resolved no doubt. One possibility is to simply extract the EDID and reference the bin file but even if that works that seems like a lot of work and something that can’t easily be applied as a fix for other users.

Mar 15 22:41:58 UB2004-EBX3 gsd-color[18653]: unable to get EDID for xrandr-eDP1: unable to get EDID for output
Mar 15 22:41:58 UB2004-EBX3 gsd-color[18653]: message repeated 2 times: [ unable to get EDID for xrandr-eDP1: unable to get EDID for output]

In theory the transformationmatrix should be the same as my xrandr scale 1.6x1.6 parameter… but it does not work.
/etc/X11/xorg.conf.d/20-intel.conf

Section "Monitor"
    Identifier "Intel Graphics"
    Option "TransformationMatrix" "1.6 0 0 0 1.6 0 0 0 1"
    Modeline "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
EndSection

Section "Device"
  Identifier  "Intel Graphics"
  Driver      "intel"
  Option      "TearFree" "true"
EndSection

Section "Screen"
   Identifier "Screen0"
   Device "Intel Graphics"
   Monitor "Intel Graphics"
   DefaultDepth 24
   SubSection "Display"
      Depth 24
      Modes "1920x1080"
   EndSubSection
EndSection

Update: While nothing appears under tail -f /var/log/syslog now, there is this under dmesg|less. I am not sure where to go next, this may only be due to the Upower config but atm I need that to debug this issue quickly/

[  116.398547] ACPI: button: The lid device is not compliant to SW_LID.

Fixed that specific log error, the problem still exists now - my logs are just quiet on now on lid close…

FYI I exported the EDID and applied it both to my grub loader and my xorg.conf.

Followed these guides, although trying to explicitly add a resolution to the EDID was not ideal, didn’t resolve the error but the other more typical edid bin extraction imo worked fine.

https://kodi.wiki/view/Archive:Creating_and_using_edid.bin_via_xorg.conf

The issue appears to be with mutter - I am not sure how to go about fixing this at this point :/.

gnome-shell --version
GNOME Shell 3.36.4

It does sound related. That bug is marked as fixed.

Your use-case is probably a little different in that you are using a custom xrandr rather than the fractional scaling settings in gnome-control-center. Please can you retest but without your custom xrandr.

Then retest with fractional scaling turned on in Displays and choose one of the values.

Yea, none of the built in fractional scalings work at all so it doesn’t really matter having that enabled.

While I probably can’t fix this existing bug inside mutter (or certainly don’t have the time at least), I have figured out a work around fyi. I will gather my findings and scripts though and make a separate post laying out how to do fractional HiDPI properly, reliably and with no high cpu usage from what I can tell under Ubuntu Budgie 20.04 for what I believe will work for any configuration.

Ultimately it required tapping into the lid close event as well as the dbus signals for logging in to reset everything. There’s a small risk that something may freeze still - especially if you are intentionally trying to crash it by repeatedly going through it all quickly. Under normal usage, spaced out by several seconds, or minutes though it should not be an issue.