Created attachment 58123 [details] dmesg when I execute xrandr with no options it blocks X until it is done. meaning nothing gets painted, my mouse does not move, keyboard is not reacting. This currently takes 4 seconds. When I use xrandr to activate my dual screen it blocks several times and overall takes 15 seconds until it has settled down again. This seems to be related to bug 41059, but the mentioned patch, while speeding up the switching, does not remedy the problrm Linux mkopp 3.1.10-gentoo-r1 #4 SMP Wed Mar 7 17:06:13 CET 2012 i686 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
Created attachment 58124 [details] xorg log Module intel: vendor="X.Org Foundation" [ 22.606] compiled for 1.11.2, module version = 2.18.0 [ 22.606] Module class: X.Org Video Driver
Created attachment 58125 [details] lspci
oh, forgot to mention, I have HDMI1 and DP2 and use them both in a dual screen setup xrandr --output DP2 --auto --primary --output HDMI1 --auto --pos 1920x176 Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 8192 x 8192 eDP1 connected (normal left inverted right x axis y axis) 1366x768 60.2 + 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1280x1024+1920+176 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 DP2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 320mm 1920x1200 60.0*+ 1600x1200 60.0 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1
time xrandr --output DP2 --auto --primary --output HDMI1 --auto --pos 1920x176 real 0m8.729s user 0m0.000s sys 0m0.002s
*** This bug has been marked as a duplicate of bug 29536 ***
Chris, I am not sure this is the same bug as the one you are pointing too. Just to make sure this is why: 1) I didn't have this issue in the 2.6 series of the kernel and I had 2.6.35,36,39 all running fine. I only had this since I upgraded to 3.1. 2) I don't have a stall every ten seconds, but only if something is requesting the EDID information (at least that is what it looks like from xorg.log) 3) I have this when running xrandr, after xrandr is done and KDE is still layouting the screen and when wine is starting programs, where I see that it is checking EDID as well for whatever reason 4) as long as nothing is checking EDID every thing is running fine That being said, if it is the same issue then your "patch" must have been regressed out of the kernel in the 3.1 series... I'l try your patch lets see
The essence of the problem that probing holds onto the config mutex which is also then acquired by the cursor updates (as well as other cases where we take the struct mutex) is the root cause of the stalls you observe. We've dreamt about fixing that for ages. You may have a further issue which has recently exacerbated the issue for you, however we already are tracking that as well.
can you tell me the other issue?
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.