| Bug ID | 107393 |
|---|---|
| Summary | 4.18.0-rc6 amdgpu framebuffer problems with DisplayPort |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | lkd-fdo@sky-haven.net |
Created attachment 140848 [d= etails] combined kernel dmesg for two boot sessions, one in 4.17.0 and the other in 4.18.0-rc6 On kernel 4.17.0, amdgpudrmfb functions correctly; taking the fb from efifb On kernel 4.18.0-rc6 (and previous), the framebuffer proper doesn't start; monitor doesn't get a valid display signal. If I log in and blind-start a Wayland compositor (sway in my case), the display gets a desktop and things work normally. Once I exit out back to FB, the display is blanked. Everything works normally if I connect the monitor with HDMI instead. This was a problem with 4.18.0-rc5 as well. I was pointed to the patch at https://lists.freedesktop.org/archives/amd-gfx/2018-July/023920.html<= /a> and applied it to 4.18.0-rc5, but it had no effect on behavior. GPU: Vega64 Monitor: Acer XR341CK
Additional new wrinkle (old bug but just for completeness) The monitor I use (Acer XR341CK) evidently has a built-in DisplayPort MST, = and it's controllable for either extending the display or cloning it to the oth= er DP connector. All the issues from this bug report disappear provided the MST mode is set = to clone the incoming signal.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- 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/468.