[i915] Maximum resolution not available after suspend / screen detach

Now I have a related problem at work, where the external monitors were not detected after plugging in the laptop in the docking station and opening the lid. Turning off and on one monitor resulted in detection (in poor resolution) but not the second external one. When both are turned off and on, the system hangs until I disconnect the USB-C cable to the docking station.

A terminal window was open where lsusb was my previous command. During the unresponsive period whilst the docking station was connected, I could press <arrow up>,<enter> without seeing anything on the screen, but after disconnecting the docking station again the command and output where shown:

$ lsusb -tv
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 2: Dev 26, If 0, Class=Hub, Driver=hub/4p, 5000M
        ID 04b4:6504 Cypress Semiconductor Corp.
        |__ Port 1: Dev 27, If 0, Class=Hub, Driver=hub/4p, 5000M
            ID 04b4:6504 Cypress Semiconductor Corp.
        |__ Port 2: Dev 28, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
            ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
        |__ Port 3: Dev 29, If 3, Class=Audio, Driver=snd-usb-audio, 5000M
            ID 17e9:600a DisplayLink
        |__ Port 3: Dev 29, If 1, Class=Application Specific Interface, Driver=usbfs, 5000M
            ID 17e9:600a DisplayLink
        |__ Port 3: Dev 29, If 4, Class=Audio, Driver=snd-usb-audio, 5000M
            ID 17e9:600a DisplayLink
        |__ Port 3: Dev 29, If 2, Class=Audio, Driver=snd-usb-audio, 5000M
            ID 17e9:600a DisplayLink
        |__ Port 3: Dev 29, If 0, Class=Vendor Specific Class, Driver=usbfs, 5000M
            ID 17e9:600a DisplayLink
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 0c45:6723 Microdia
    |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 0c45:6723 Microdia
    |__ Port 6: Dev 58, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 04b4:6506 Cypress Semiconductor Corp. CY4603
        |__ Port 1: Dev 59, If 0, Class=Hub, Driver=hub/4p, 480M
            ID 04b4:6506 Cypress Semiconductor Corp. CY4603
            |__ Port 1: Dev 60, If 0, Class=Hub, Driver=hub/4p, 480M
                ID 05e3:0608 Genesys Logic, Inc. Hub
                |__ Port 2: Dev 64, If 1, Class=Vendor Specific Class, Driver=, 12M
                    ID 03f0:0867 HP, Inc
                |__ Port 2: Dev 64, If 0, Class=, Driver=, 12M
                    ID 03f0:0867 HP, Inc
                |__ Port 3: Dev 65, If 0, Class=Mass Storage, Driver=usb-storage, 480M
                    ID 0ea0:2272 Ours Technology, Inc.
                |__ Port 1: Dev 62, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
                    ID 413c:301a Dell Compu...

Thanks for the bug report. This sounds like it might be a kernel bug in the i915 driver. Next time you are stuck in a poor resolution, please run:

  grep . /sys/class/drm/*/modes > modes.txt

and attach the resulting text file here.

Thanks, Daniel.
The modes output file is in attach.
As you can see, it doesn't display the 3840x2160 mode for the external screen (card0-DP-1), which is however still found in the EDID info.

Hi Daniel et al,

Do you have any news or further requests on this? Now I'm having the problem even after a reboot, I guess after an automatic kernel update:

$ uname -a
Linux omer 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:53:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Same drm modes of course

Sounds like either a kernel bug or a kernel feature whereby it detects which modes the attached cable actually provides enough bandwidth for, and removes the modes that probably can't be sustained reliably.

If it is just a bandwidth problem then replacing the display cable might fix it.

Also newer kernels may already contain a fix. Providing you are not using secure boot you can try newer kernels like:

https://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2022-11-18/amd64/

This change was made by a bot.

Thanks Daniel,

As I currently have a correct resolution setting at work (see #2) without any hardware replacement, I don't think this is a hardware (cable) problem. I'll test this evening at home again, as well as with a new kernel.

Hi Daniel,

I just tested with the new kernel:
$ uname -a
Linux omer 6.1.0-060100rc5drmtip20221118-generic #202211180211 SMP PREEMPT_DYNAMIC Fri Nov 18 03:02:15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

But still the same issue. The cable should be OK, as it didn't change since the time it was working perfect for more than a year.

Is there a way to run/debug the cable bandwidth test?

> Is there a way to run/debug the cable bandwidth test?

I don't know but excellent question. AFAIK it's just invisible logic in the kernel which will hide modes that require too much bandwidth.

OK, since the upgrade to kernel 6.1 I cannot use the external monitors at work (through the HP DisplayLink device) anymore. I reinstalled the DisplayLink driver without success.

$ sudo get-edid | parse-edid
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
No EDID on bus 8
No EDID on bus 9
No EDID on bus 10
1 potential busses found: 7
256-byte EDID successfully retrieved from i2c bus 7
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
 Identifier ""
 ModelName ""
 VendorName "SHP"
 # Monitor Manufactured week 42 of 2018
 # EDID version 1.4
 # Digital Display
 DisplaySize 290 170
 Gamma 2.20
 Option "DPMS" "false"
 Modeline "Mode 0" 533.25 3840 3888 3920 4000 2160 2163 2168 2222 -hsync -vsync
 Modeline "Mode 1" 426.60 3840 3888 3920 4000 2160 2163 2168 2222 -hsync -vsync
EndSection

I'll return to kernel 5.15...

The latest DisplayLink driver 5.6.1 appears to only support up to kernel 5.18 according to the release notes:

https://www.synaptics.com/products/displaylink-graphics/downloads/ubuntu

I recommend using that version because it (still) appears to be years ahead of the driver in the Ubuntu archive.

Hi Daniel,
I replaced the DP cable. After inserting the cable, the full resolution was immediately back available. However, the problem/bug still remains: after a suspend, the screen only gives a poor resolution and the full resolution is not available. After a reboot, the full resolution is back available.

Are you sure about kernel 5.18.19 as it no longer gets security updates whilst the previous 5.15.0 is the one maintained by the Ubuntu team.

Any other options/possibilities to resolve the issue? Thanks!

Hi Daniel et all,
Only a few days after the previous post, the problem got worse again: after a reboot I get a poor resolution but see the full 4K resolution available in the settings. However, after selecting this one, the poor resolution stays and the 4K disappears. The new cable can't be broken after a few days though?

Is there a way to resolve or trace down this bug? Thanks!

Hi Daniel et al,

Happy new year if you're already in the new year!

Yesterday, I got the same issue: poor resolution with the (new) DP cable. Unplugging and reconnection without success.

However, just unplugging and inserting the cable in another port did some magic and brought the full resolution back. Reconnecting in the right port again caused a restart of Wayland, but again in full resolution.

After a recovery from suspend later today, I got no mousse functioning, neither the external USB one, neither the internal mousepad. Pressing the windows key caused only the main display to show both workspaces, whilst all open windows at the external display stayed in place. Reconnecting the USB made no difference. However, unplugging and reconnecting the external monitor (USB-C - DP cable) made the mousse work again.

What could be wrong or debugged in this weird situation? Thanks!

Hi Daniel et al,

After a few days of working in the full resolution (even after hibernating and display swapping) today a resume from suspend again resulted in a poor resolution on my 4K screen. Disconnecting, swapping cables, rebooting,... didn't solve the issue. I'm stuck in the poor resolution again.

As there is a commit for kernel 6.0 compatibility in the DisplayLink git repository, I installed this version and upgraded to kernel 6.0.9. Unfortunately, the poor resolution stayed...

Is there anything I can further do or test in order to debug or resolve this issue? Thanks a lot.

Hi Daniel et al,

The past months I could get the full resolution back by waiting a longer time before inserting the DP cable. However, since the installation of a bunch of updates last week, this doesn't work anymore. I stay stuck in the poor resolution. The cables are brand new and were working perfect before the updates.

How can we solve/debug this?