When I use my Dell U2414H connected via DisplayPort the polling for hardware takes more than a second (using xrandr). Unfortunately this seems to be done by several Gtk applications and every qt application on startup. This is dmesg with drm.debug=0xe commandline. I cut about a million "drm:drm_dp_i2c_do_msg] native defer" lines to make it cleaner http://pastebin.com/H4Zh9Dny Environment: Intel i5-4590, MSI b85i, no dedicated graphics, 8GB, Samsung SSD 840 Evo. Archlinux, Kernel 3.15.5-1-ARCH, using i915 This happens as well under Ubuntu Live 14.04. Please contact me if you need more information.
Can you post the raw log? I'd like to see when/where/how many native defers the monitor is issuing. Is your display set up in Displayport 1.2 mode or 1.1a? -T
http://pastebin.com/Hxg4GVwk Display is set to Displayport 1.2.
Can you file a bug against any application that is slow as well? XRRGetScreenResourcesCurrent() is the call they should be using (which uses the known configuration rather than forcing the redetection).
Does this make sense? This is rather a core problem. I reported a bug at Qt because polling hardware on every program start is not optimal. A Gtk example is the gnome systemsettings, which makes sense though. This bug is flagged with NEEDINFO. Which info do you need?
Both are issues. At best hardware polling will take ~0.2s (obviously this scales with the number of attached displays). Almost all software doesn't care about forcing the detection of new outputs, but only wants to know the current configuration - the difference is ~0.2s for every single unnecessary call. I am tempted to make all such queries slow to try and teach application developers to use the right interfaces.
Yes, I agree, but polling with DisplayPort takes about 2 seconds, even with all other outputs set to ignore in xorg.conf, and it would not be that crucial if the X server would not freeze completely. I gave the Qt developers a hint to use current ressources (https://bugreports.qt-project.org/browse/QTBUG-40207?focusedCommentId=250727&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-250727)
Don't worry! It is not an excuse for us to try and fix the hw/driver issues. The extra probing are just a nuisance for when we are trying to get down to a few tens of milliseconds startup time.
Can you switch your monitor back to 1.1a and see if it still issues all those defers? From the log, it looks like we're spending an inordinate amount of time waiting for the display to respond to the EDID request(s). From the beginning to the end of the first block of defers if about 0.65 seconds. That's just for the first EDID read. Part of the reason for this is the number of retries and the transaction delays required by the Displayport specification. Each deferred transaction must be reattempted 7 times and each time it waits the normal 400us plus an additional 500-600us to give the sink more time to respond. So each defer costs roughly 1ms of time. A minimum of 8 transactions is required to read an entire 128-byte EDID block (16 bytes maximum per I2C-over-AUX transaction). However, the sink device is not required to reply with all of the data for the transaction. It can ACK with partial data and continue the transaction on the next request. So what should have been a single 16-byte transaction could turn into five 3-byte transactions and one 1-byte transaction. Each of these transactions can also be deferred up to 7 times, so those individual transaction delays that seem somewhat insignificant can really start to add up. -T
Created attachment 105098 [details] dmesg|grep drm (1.1)
Created attachment 105099 [details] dmesg|grep drm (1.2)
Sorry that I abandoned this thread, I had to write my exams. Meanwhile I use 3.16.1-1-ARCH, xf86-video-intel 2.99.914-4 and intel-dri 10.2.6-1. But I still have this problem. I attached the logs of a boot and login with both configurations of the screen (DP 1.1 and DP 1.2). If you need more info, let me know.
Bump
Todd, any idea? New logs shows the native defer and along with the message on the code there is the wait 500-600 us you had mentioned.
Also, any chance for a full dmesg without grepping, and all the way from boot with drm.debug=0xe set.
Created attachment 106772 [details] journalctl with DP1.1
Created attachment 106773 [details] journalctl with DP1.2
I added the logs. This time from journalctl since dmesg seemed to display only drm stuff.
How do you connect the monitor? What kind of adapters do you have? Do you have a dual display setup; can you try with only one display connected?
My monitor Dell U2414H is connected to my mainboard MSI B85I directly with a Display Port cable. Normal DP at the mainboard MiniDP at the monitor. No adapters. I use only one monitor, since I read that MST will be supported not until kernel 3.17
Odd. By the logs it looks like you have a DP branch device and also a HDMI monitor... What does xrandr --verbose say?
Created attachment 106789 [details] journalctl with DP1.2 HDMI disconnected
Created attachment 106790 [details] journalctl with DP1.1 HDMI disconnected
Created attachment 106791 [details] xrandr --verbose HDMI disconnected
Damn. Sorry for stealing your time. I had the HDMI cable connected. I have to switch everytime because the KDE desktop is unusable with this two bugs. I added attachments with HDMI disconnected and xrandr --verbose.
On linux 3.17.1, mesa-dri 10.3.1, xf86-video-intel 2.99.916 still the same. I hoped that with 3.17 this will change since MST was added... :(
Is this still an issue with v3.18 or v3.19-rc kernels? How about with patch http://mid.gmane.org/1422373429-10137-1-git-send-email-simon.farnsworth@onelan.co.uk
Created attachment 112976 [details] dmesg (DP1.1a)
Created attachment 112977 [details] dmesg DP1.2
Yes this is still an issue. KDE is unusable. I experience several freezes at X start. Hangs at start of Qt apps. Login Manager is completely screwed up with DP 1.2. Things are even worse than before.
Did you try the patch from comment #26?
Sorry I am just an average user. I dont know whow to patch. Maybe you can help me?
(In reply to Manuel Schneider from comment #31) > Sorry I am just an average user. I dont know whow to patch. Maybe you can > help me? Sorry, we pretty much expect the users filing bugs here to be able to try the fixes. Otherwise your best bet is your distro's bug tracker. In order to patch the kernel, you'd need to learn a bunch of things, like how to download kernel sources (preferrably using git), how to patch the source, how to configure the kernel, how to build the kernel, and how to install the kernel. Here are a few pointers on how to get started, if you're still interested: https://wiki.archlinux.org/index.php/Kernels#Patches_and_Patchsets http://kernelnewbies.org/KernelBuild
To be honest I understated the case. I am familiar with git and know how to use compilers although I am always avoiding makefiles. I built a lot of things but I never touched the kernel. I will try as soon I have a bit more time.
We've fixed plenty of issues with the DP aux/i2c-over-aux code lately; I presume this is fixed upstream too. Please reopen if the problem persists with latest kernels.
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.