Summary: | Extra ("phantom") display | ||||||
---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | monnier | ||||
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
Severity: | normal | ||||||
Priority: | medium | CC: | intel-gfx-bugs, mkortstiege | ||||
Version: | unspecified | ||||||
Hardware: | x86-64 (AMD64) | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | HSW | i915 features: | display/DP | ||||
Attachments: |
|
Description
monnier
2015-10-21 12:36:49 UTC
Try adding video=DP-1:d to your commandline, or echo off | sudo tee /sys/class/drm/card0-DP-1/status "video=DP-1:d" did the trick, thank you very much! Does that mean that it's fundamentally a bug in my motherboard ('s BIOS)? Not really, something is very odd in the detection phase. If you remove the video= parameter and replace it with drm.debug=6 then please attach the dmesg from boot, we may be able to identify a problem in our code. Created attachment 119203 [details]
dmesg log with drm.debug=6
Here's the dmesg output from boot with drm.debug=6 and without any video=... parameter.
(In reply to monnier from comment #4) > Created attachment 119203 [details] > dmesg log with drm.debug=6 > > Here's the dmesg output from boot with drm.debug=6 and without any video=... > parameter. So there's definitely a DP device of some sort attached to the port since DPCD works. The EDID read doesn't seem to go too well though due to aux defers. Can you repeat the test with kernel version 4.3+, and attach the new log (with debugs enabled)? Timeout, closing. |
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.