You are not logged in.
Hi,
since I updated to the linux kernel 4.1.1 in testing my external monitor connected via vga with mini displayport to vga adapter is not detected anymore.
If I connect it via a mini displayport to hdmi cable everything is fine, also going back to linux 4.0.7 and using the vga adapter works.
Does anybody else have the same problem? Any suggestions on how to debug this?
Offline
Problem still there with linux-4.1.2-1
xrandr --output DP1 doesn't have any effect.
xrandr:
Screen 0: minimum 8 x 8, current 1280 x 800, maximum 32767 x 32767
LVDS1 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 286mm x 179mm
1280x800 60.22*+
1024x768 60.00
800x600 60.32 56.25
640x480 59.94
640x400 60.00
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Offline
I can confirm this with my XPS 13, Displayport to VGA adapter works with Kernel 4.0.7 and not with 4.1.2. Have you found a solution for this problem yet? I would report this bug but I am not sure who might be responsible for this?
Offline
I see this too... Does anyone feel like bisecting the commit that caused it?
Offline
Unfortunately no progress so far:
I have i915 loaded under MODULES in my mkinitcpio.con early at boot and with linux 4.0.7 can see the boot messages on the external monitor, but not with linux 4.1.2. Therefore I don't think is a problem of the X server. So maybe some problem with KMS? My Intel driver is xf86-video-intel 1:2.99.917+381+g5772556-1 at the moment. Suggestions for debugging? dmesg doesn't give much info...
Offline
dmesg | grep drm
with drm.debug=14 as kernel parameter finally gives some more info
[drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1]
[drm:intel_dp_detect] [CONNECTOR:40:DP-1]
[drm:drm_dp_dpcd_access] too many retries, giving up
[drm:drm_dp_dpcd_access] too many retries, giving up
[drm:drm_dp_dpcd_access] too many retries, giving up
[drm:drm_dp_dpcd_access] too many retries, giving up
Any idea what might be the problem? Should I fill a bug report?
Offline
I see this too... Does anyone feel like bisecting the commit that caused it?
I just started the first build, it will take some time though to get through all steps, so I don't know if I can finish it tonight.
Offline
Submitted a bug report https://bugs.archlinux.org/task/45733
Offline
Allan wrote:I see this too... Does anyone feel like bisecting the commit that caused it?
I just started the first build, it will take some time though to get through all steps, so I don't know if I can finish it tonight.
Woo! Means I don't have to do it...
Offline
GuyIncognito wrote:Allan wrote:I see this too... Does anyone feel like bisecting the commit that caused it?
I just started the first build, it will take some time though to get through all steps, so I don't know if I can finish it tonight.
Woo! Means I don't have to do it...
No problem, I never did this bisect thing but have been curious about how it works when I first read about it. I didn't thought it would take that much time though
So here is my result:
1d002fa720738bcd0bddb9178e9ea0773288e1dd is the first bad commit
commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date: Tue Feb 10 18:38:08 2015 +0000
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
:040000 040000 d2578947f3ce7a7f83562d3abfd3622728917c18 b5aa29ee827fe0f932f654f4d51698745665048d M drivers
:040000 040000 1c08c61febb31465d64d698aad36b3f1c799933d acc134748273f72de54f3c063e80d50626752b18 M include
One problem I had was that in the last few steps my system froze every single boot without showing any errors in the journal and without the second monitor working, although in the end it froze with the second monitor working so I think the test is still allright. I haven't reverted the patch yet to see if this is all it would take to fix the problem but I guess we're on the right track here since the commit is very related to the problem.
Offline
"Copy Windows's behaviour" <- why our screens do not work!
I'll make a note in the bug report.
Offline
Just out of curiosity, since those problems might be related to a individual DisplayPort-Dongle, are both of you using a Apple DP-VGA Dongle as well?
Offline
Just out of curiosity, since those problems might be related to a individual DisplayPort-Dongle, are both of you using a Apple DP-VGA Dongle as well?
Yes, I'm using an Apple one... Thanks for your efforts, I would not have been able to make much progress by myself.
Offline
GuyIncognito wrote:Just out of curiosity, since those problems might be related to a individual DisplayPort-Dongle, are both of you using a Apple DP-VGA Dongle as well?
Yes, I'm using an Apple one... Thanks for your efforts, I would not have been able to make much progress by myself.
No problem. If you are interested how I found out which commit created the problem, this wiki page basically explains it.
Reverting the patch did work by the way, I am currently running 4.1 with my second monitor working.
Offline
kitteboss wrote:GuyIncognito wrote:Just out of curiosity, since those problems might be related to a individual DisplayPort-Dongle, are both of you using a Apple DP-VGA Dongle as well?
Yes, I'm using an Apple one... Thanks for your efforts, I would not have been able to make much progress by myself.
No problem. If you are interested how I found out which commit created the problem, this wiki page basically explains it.
Reverting the patch did work by the way, I am currently running 4.1 with my second monitor working.
Thanks, I will have a look at it.
Offline
I also use the Apple dongle.
Offline
Hi, glad I found my corresponding issue too, I have a thinkpad T550 with i915 driver and display port stopped working after upgrading.
I see you people applied a patch to your kernel, but can you explain how to do it?
Offline
Hi, glad I found my corresponding issue too, I have a thinkpad T550 with i915 driver and display port stopped working after upgrading.
I see you people applied a patch to your kernel, but can you explain how to do it?
Before you try something else you might try a boot with "drm_kms_helper.dp_aux_i2c_transfer_size=1" on the kernel command line as suggested in the freedesktop bug report https://bugs.freedesktop.org/show_bug.cgi?id=91451
At the moment unfortunately I can't test it because I'm without external monitor
Last edited by kitteboss (2015-07-29 18:39:54)
Offline