Bug 106735

Summary: [amdgpu] all displays reconnect after failed EDID read
Product: DRI Reporter: Matthias <mail>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: major    
Priority: medium CC: harry.wentland, mail
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:
Description Flags
Xorg.log none

Description Matthias 2018-05-30 15:05:04 UTC
Created attachment 139861 [details]

I am on ubuntu 18.04 LTS on gnome3 with X.org. I am using amdgpu with a Raden RX 580.

> $ lspci -k | grep -EA3 'VGA|3D|Display'
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480] (rev e7)
> 	Subsystem: ASUSTeK Computer Inc. Ellesmere [Radeon RX 470/480/570/580]
> 	Kernel driver in use: amdgpu
> 	Kernel modules: amdgpu

> $ uname -r
> 4.15.0-22-generic

>  $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 18.04 LTS
> Release:	18.04
> Codename:	bionic

Two screens for working are connected via DVI and HDMI.
One HDMI output is connected to a PlayStation VR Headset. The Headset redirects all input to the TV but it is mostly turned off.

When turned off but connected to the HDMI output, frequent EDID read fails are reported to syslog:

> [drm:log_to_debug_console [amdgpu]] *ERROR* No EDID read.

When un-plugging the PSVR Headset from HDMI the errors vanish. After the EDID read there is the HMD related messages like

> [    3.066968] [drm:log_to_debug_console [amdgpu]] *ERROR* No EDID read.
> [    3.091884] [drm] SIE  HMD *08: [Block 0] 
> [    3.091886] [drm] SIE  HMD *08: [Block 1] 
> [    3.091890] [drm] dc_link_detect: manufacturer_id = D94D, product_id = B403, > serial_number = 1010101, manufacture_week = 38, manufacture_year = 27, display_name = SIE  HMD *08, speaker_flag = 15, audio_mode_count = 4
> [    3.091896] [drm] dc_link_detect: mode number = 0, format_code = 1, channel_count = 6, sample_rate = 87, sample_size = 7
> [    3.091899] [drm] dc_link_detect: mode number = 1, format_code = 2, channel_count = 6, sample_rate = 7, sample_size = 80
> [    3.091902] [drm] dc_link_detect: mode number = 2, format_code = 7, channel_count = 6, sample_rate = 7, sample_size = 188
> [    3.091905] [drm] dc_link_detect: mode number = 3, format_code = 10, channel_count = 8, sample_rate = 4, sample_size = 0

All connected Screens then reconnect: They turn black and the position of the screens (which is left and which is right screen) is sometimes also reset. This is annoying during productive work.

My point is that I don't mind if there is no EDID from the PSVR HeadSet or any of the connected devices. The headset is turned off and As I see it, it should only check for the EDID when I turn it on.

The only quick solution here is to unplug the Headset while on Linux.
Comment 1 Matthias 2018-05-30 15:05:43 UTC
Created attachment 139862 [details]
Comment 2 Matthias 2018-05-30 15:14:26 UTC
Should I try to force a binary EDID for the connected PSVR? maybe like the solution proposed here:
Comment 3 dwagner 2018-05-30 20:15:43 UTC
(In reply to Matthias from comment #2)
> Should I try to force a binary EDID for the connected PSVR?

At this time, I would recommend against this: I experience consistent crashes on evey S3 resume if use the kernel command line parameter to force a certain binary EDID.

Which is a pity, because (a) this worked fine with prior kernel versions until early October 2017 and (b) it was useful when waking up the computer remotely while the connected display is still switched off.

See also: https://bugs.freedesktop.org/show_bug.cgi?id=103277
Comment 4 Martin Peres 2019-11-19 08:40:18 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/408.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.