I'm on Ubuntu 18.04 desktop, with Intel HD Integrated Graphics and a single 2560x1440 screen connected with a DP (DisplayPort) cable. I've not had this problem using the same desktop with smaller monitors.

On this large monitor, each time I resume from locking the screen (entering my password for the system's only user account), the highest available resolution is progressively eliminated from the list of choices in both GNOME Settings and the options displayed by xrandr. Initially, after the system boot:

$ xrandr
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 699mm x 393mm
   2560x1440     59.95*+
   2880x1620     60.00
   2048x1152     60.00
   1920x1200     59.88

... then after the first screen lock & resume, a higher than natural resolution is eliminated (through having no visible effect yet):

Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192 ...
   2560x1440     59.95*+
   2048x1152     60.00
   1920x1200     59.88

... then the second screen lock & resume reduces the current resolution to 2048x1152:

Screen 0: minimum 320 x 200, current 2048 x 1152, maximum 8192 x 8192 ...
DP-1 connected primary 2048x1152+0+0 (normal left inverted right x axis y axis) 699mm x 393mm
   2048x1152     60.00*
   1920x1200     59.88

... and the third reduces the screen to 1920x1200, going further down the list each time: progressively eliminating the highest pair of available screen resolution & video frequency with each screen lock.

The monitor is an Acer EB321HQU - turning it off & on again has no effect on the resolutions available unless the system is also rebooted. There are related bug reports but only confirmed for nVidia graphics cards, not applicable in my case. I've also tried these so far, with no effect on the problem:

  • switching from default gdm3 to lightdm
  • upgrading video driver xserver-xorg-video-intel/bionic from native 2:2.99.917+git20171229-1 to newer version at Open Graphics Drivers PPA 2:2.99.917+git1903011933.6afed3~oibaf~b amd64
  • EDIT: disconnecting & reconnecting the DP cable reduces the maximum resolution even further, to 1024x768.
  • Similar problem here with an iiyama ProLite X4071UHSU connected via DisplayPort to Intel chipset graphics. Each time the display system wakes up from power saving, the video mode drops to the next lower resolution. – Markus Kuhn Jul 5 '19 at 19:38
  • @MarkusKuhn the "my own solution" below of building a custom EDID worked for some time, but I've abandoned it recently because the generated xorg.conf file somehow doesn't permit screen enlargements to a virtual resolution (X usually crashes). My system is nearly 10 years old with Ironlake graphics so I'm assuming it's because of lack of current testing on that platform. I'd be interested in whether the EDID method itself works on your newer system. – rphair Jul 7 '19 at 8:00

First generate a template xorg.conf file as follows (which should work even if you're running X / GNOME / display manager already):

sudo X :2 -configure

Then copy the resulting file /root/xorg.conf.new to /etc/X11/xorg.conf which will be a new file on latter versions of Ubuntu since X parameters are automatically determined by default. Here's where my own solution diverges from a more simpler, general one:

1, general) Users of some graphics cards may be able simply to fix this by adding lines appropriate for the misbehaving monitor in the section beginning with Section "Monitor":

Modeline "2560x1440" 241.50  2560 2608 2640 2720 1440 1443 1448 1481 -hsync -vsync
Option "PreferredMode" "2560x1440"

The X server uses a system called EDID to query the resolutions automatically and there are many reported problems of both external and laptop displays getting incomplete results (I first thought this was happening to me after screenlock/unlock and suspend/resume). Explicitly setting the Modeline tends to ensure this resolution is available to the X server no matter what the EDID response. I was able to get this Modeline in 2 ways (there are others):

  • reading it from the X server startup log file in /var/log/Xorg.0.log
  • confirming it with the PowerStrip program in Windows (tutorial)

The Ubuntu doc page X/Config/Resolution > statically setup in xorg.conf gives a good overview of X configuration and relevant issues.

2, my own solution) However, in the Xorg log file I found that

  • the Modeline was being ignored in favour of the information from EDID (appearing in the log as DDC gathered Modelines)
  • the PreferredMode was properly parsed but then rejected.

I realised I had to replace the broken EDID my display card was getting from the monitor with one containing only the Modeline for my proper resolution. But my system is on Intel HD graphics, for which most of the options dealing with EDID (UseEDID, UseEDIDFreqs, IgnoreEDID) are unsupported (marked is not used in the log file) so I had no success suppressing EDID altogether.

There were both positive and negative reports (stemming from this bug report) of using another EDID Xorg option CustomEDID to supply one's own EDID configuration. I tried the procedure here (for compiling and edid.bin file with only my own modeline in it) and it worked, despite reports that it wouldn't: Creating and using edid.bin via xorg.conf > Method 2: Generate edid.bin from an Xorg modeline (edid-generator)

My currently working configuration, with the problem fixed, therefore has these two lines added to the "Screen" section (instead of the corresponding "Monitor" lines in solution #1):

Option  "ConnectedMonitor" "DP1"
Option  "CustomEDID" "DP1:/etc/X11/2560x1440.bin"

... where DP1 matches the Identifier tag in the "Monitor" section and therefore the output of xrandr. Next time rebooting with this xorg.conf I had a much shorter list of resolutions in xrandr, which now persists no matter how many times the screen goes blank on the monitor.

BTW if the reports all over the Internet about the Intel driver not recognising the CustomEDID option had turned out to be true for me (!NOTE! I am using the open source drivers mentioned in the OP!), I would have had one more option in specifying the custom EDID data as a kernel parameter: ArchLinux > Kernel mode setting > Forcing modes and EDID

Why was this happening in the first place? (Short answer: the monitor EDID was produced & left broken by Acer, but this would be fixed for the Windows majority by a "driver" which is really just registry entries to hard-code the EDID config onto the computer itself.) A program get-edid, referred to in the linked procedure above, extracted the broken EDID from my monitor:

sudo get-edid -m 0 > edid.bin

... and when running its output through edid-decode it showed that only the lower resolutions were classified as either "Established timings" or "Standard timings" and the higher resolutions which kept dropping only appeared as sets of timing characteristics. Also, when putting that output through a third program parse-edid it showed the mode 1920x1080 was actually the PreferredMode, which finally explained why the screen restarts eventually returned to that mode.

EDIT: As of mid-January 2020, an updated Xorg server with the Intel driver will crash, or not start, when any of the EDID options are used. There are a few open bugs about this which can be found in a first-look Internet search. So the solution above no longer works in this particular case, though it still might be of more general use.

I would advise anyone experiencing this problem to immediately contact their hardware manufacturer to swap the monitor if the firmware cannot be upgraded any other way. Ironically Microsoft offers the best explanation why this problem can really only be solved in a manufacturing plant, not on the desktop: Overriding Monitor EDIDs

EDIT 2: As of end-February 2020, I've tested setting EDID with Kernel Mode Setting (Forcing modes and EDID), registering the Custom EDID file by adding a boot option:

GRUB_CMDLINE_LINUX_DEFAULT="splash drm.edid_firmware=edid/2560x1440.bin"

Under the conditions above (my monitor, display, and DP connection) this works perfectly to keep the ideal display resolution when waking after suspend/sleep, but whenever the display is unblanked without waking from sleep then the X screen gets scrambled.

In summary: I can only hope the above provides some options to help with this problem on other platforms, rather than providing a universal solution.


I had a very similar issue: highest resolution has lost Sometimes after suspend. The root cause seems to be a somewhat faulty EDID in the monitor.

Solution 1.: upgrade firmware of your monitor or replace it. Solution 2.: when you have the highest resolution (when you can change to that resolution with e.g. xrand), then read the EDID of your monitor and set it as CustomEDID in xorg.conf.

The 2. solution is working for me (AOC 24" display with intel/i915 graphics card on 4.19 kernel). Both solution from above are very well detailed by @rphair, thanks a lot! (I still can not add it as a comment yet..)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.