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.