ubuntu-x-swat team mailing list archive
-
ubuntu-x-swat team
-
Mailing list archive
-
Message #148428
[Bug 855124] Re: XRANDR operations very slow unless (phantom) HDMI1 disabled
Launchpad has imported 50 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=41059.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2011-09-20T22:41:42+00:00 Bryce Harrington wrote:
Forwarding this slow-boot bug from Ubuntu reporter Soren Hansen:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/855124
[Problem]
Any operation that probes stuff over XRANDR is really slow. Running just "xrandr" takes slightly less than 4 seconds. A bit of experimentation reveals that adding:
Section "Monitor"
Identifier "HDMI1"
Option "Ignore" "True"
EndSection
...to xorg.conf fixes it. I have no HDMI ports at all, so this is not a
problem.
Only HDMI1 seems to be the problem.
DistroRelease: Ubuntu 11.10
Package: xorg 1:7.6+7ubuntu7
ProcVersionSignature: Ubuntu 3.0.0-11.17-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
ApportVersion: 1.22.1-0ubuntu2
Architecture: amd64
CompositorRunning: None
Date: Wed Sep 21 00:10:26 2011
DistUpgraded: Log time: 2011-08-09 13:47:39.295432
DistroCodename: oneiric
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:20e4]
Subsystem: Lenovo Device [17aa:20e4]
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100202)
MachineType: LENOVO 7465CTO
ProcEnviron:
PATH=(custom, user)
LANG=da_DK.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-11-generic root=UUID=9c822cf3-46f9-426f-9fab-13ba9053c1ef ro quiet splash vt.handoff=7
SourcePackage: xorg
UnitySupportTest: Error: command ['/usr/lib/nux/unity_support_test', '-p', '-f'] failed with exit code -11:
UpgradeStatus: Upgraded to oneiric on 2011-08-09 (42 days ago)
dmi.bios.date: 05/16/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 6DET70WW (3.20 )
dmi.board.name: 7465CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6DET70WW(3.20):bd05/16/2011:svnLENOVO:pn7465CTO:pvrThinkPadX200s:rvnLENOVO:rn7465CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7465CTO
dmi.product.version: ThinkPad X200s
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.5.94+bzr2803-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu20
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/3
------------------------------------------------------------------------
On 2011-09-20T22:44:26+00:00 Bryce Harrington wrote:
Created attachment 51432
BootDmesg.txt
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/4
------------------------------------------------------------------------
On 2011-09-20T22:44:42+00:00 Bryce Harrington wrote:
Created attachment 51433
XorgConf.txt
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/5
------------------------------------------------------------------------
On 2011-09-20T22:45:44+00:00 Bryce Harrington wrote:
Created attachment 51434
XorgLog.txt
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/6
------------------------------------------------------------------------
On 2011-09-20T22:47:24+00:00 Bryce Harrington wrote:
User reported that by disabling HDMI1 as described, it returns boot
speed performance to what it was under natty.
Presumably HDMI1 could be quirked off in the kernel for this particular
laptop, but is there a better solution?
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/7
------------------------------------------------------------------------
On 2011-09-21T08:39:34+00:00 Chris Wilson wrote:
Right, let's have a look at drm.debug=0xe for starters. Though I don't
think that will tell us anything more than the probe is slow. We can try
the initcall_debug trick here (again requires a builtin i915.ko I think)
to narrow down the offending function. The most likely suspect is that
it is the EDID discovery that is slow.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/12
------------------------------------------------------------------------
On 2011-09-22T07:39:36+00:00 Soren Hansen wrote:
Created attachment 51505
dmesg with debug output
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/16
------------------------------------------------------------------------
On 2011-09-22T08:31:49+00:00 Chris Wilson wrote:
Well, that pinpoints it entirely on the EDID probe for the HDMI port. So
it would appear to be that we valiantly try to read the EDID through a
sea of noise.
Just on the off-chance this helps and points us in the right direction,
can you try:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d98cee6..1b14504 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -401,7 +401,7 @@ int intel_setup_gmbus(struct drm_device *dev)
bus->reg0 = i | GMBUS_RATE_100KHZ;
/* XXX force bit banging until GMBUS is fully debugged */
- bus->force_bit = intel_gpio_create(dev_priv, i);
+ //bus->force_bit = intel_gpio_create(dev_priv, i);
}
intel_i2c_reset(dev_priv->dev);
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/17
------------------------------------------------------------------------
On 2011-09-22T21:46:53+00:00 Eugeni Dodonov wrote:
*** Bug 41061 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/18
------------------------------------------------------------------------
On 2011-09-23T13:56:43+00:00 Hernando Torque wrote:
I'm the original reporter of the dupe. The patch actually worsen the
time by a bit. From only my LVDS1 activated, I successively un-ignored
the other outputs via xorg.conf and checked the time `xrandr` needed to
finish (mean over 10 runs):
* Ubuntu kernel (3.0.0-11.18) and 3.1-rc7 w/o patch (using the Ubuntu
config):
LVDS1 5 ms (connected)
+ VGA1 6 ms (disconnected)
+ DP3 120 ms (not present)
+ DP2 240 ms (not present)
+ DP1 360 ms (disconnected)
+ HDMI3 380 ms (not present)
+ HDMI2 400 ms (not present)
+ HDMI1 2000 ms (not present)
* 3.1-rc7 patched (using the Ubuntu config):
LVDS1 5 ms (connected)
+ VGA1 6 ms (disconnected)
+ DP3 120 ms (not present)
+ DP2 240 ms (not present)
+ DP1 360 ms (disconnected)
+ HDMI3 380 ms (not present)
+ HDMI2 590 ms (not present)
+ HDMI1 2200 ms (not present)
Besides: are 120 ms for the (disconnected and non-existent) DisplayPort
ports okay?
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/19
------------------------------------------------------------------------
On 2011-09-23T14:09:47+00:00 Chris Wilson wrote:
Well that rules out the possibility that the hardware GMBUS handles the
failure more graceful.
To determine if VGA is connected we first check a hotplug status bit in
a register. So determining if it is disconnected is quick and easy.
For everything else, we more or less, probe for an EDID and check that
EDID corresponds with the limitations of the link. (There are many
machines out there that share a single DDC bus between multiple devices,
and so the EDID you receive might be for a different encoder.)
Next step is to dive into the specs and see if there is a method for
quickly determining unconnected status that we've overlooked all these
years...
Besides which the timeout for the HDMI is inexplicably long.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/20
------------------------------------------------------------------------
On 2011-09-23T21:58:50+00:00 Leann Ogasawara wrote:
For anyone else interested (ie Soren), I've built an Ubuntu test kernel
with the patch from comment #7 applied. It's available at the following
location:
http://people.canonical.com/~ogasawara/fdo41059/
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/21
------------------------------------------------------------------------
On 2011-09-23T22:12:02+00:00 Soren Hansen wrote:
Wow, how awesome is that? :) I'll take it for spin right away.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/23
------------------------------------------------------------------------
On 2011-09-23T22:33:41+00:00 Soren Hansen wrote:
It certainly made a difference.
If I don't disable any of the outputs, xrandr takes nearly 4 seconds
without the patch, and around 0.6 with the patch.
If I disable HDMI1, xrandr runtime gets down to 0.125 seconds or
thereabouts.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/24
------------------------------------------------------------------------
On 2011-09-26T23:45:04+00:00 Eugeni Dodonov wrote:
Created attachment 51643
Patch to ignore non-existent i2c buses
Could you please try with this patch?
It should allow kernel to ignore non-existent i2c communication lines.
On my machine, the xrandr probing with this patch went from 4s to
0.366s.
To enable it, please also add the following line into /etc/modprobe.conf
(or /etc/modprobe.d/i2c_algo_bit.conf file (creating it when necessary):
options i2c_algo_bit bit_test=1
Also, if it works (or if it does not works) for you, please paste the
result of 'dmesg' with the patch applied.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/25
------------------------------------------------------------------------
On 2011-09-27T21:24:49+00:00 Eugeni Dodonov wrote:
Created attachment 51687
Patch to detect stuck bits directly in i915 driver
This patch avoids going through i2c_algo_bit to do the bus testing and
performs the testing directly in the i915 driver.
It tests only for the bits which are stuck as high, which seems to be
the case if this issue.
Please test with both patches (this and the previous one), and report if
they fix the issue for you. At least on my machine, I haven't
experienced delays in xrandr and video output detection with any of
those patches anymore.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/26
------------------------------------------------------------------------
On 2011-09-27T22:12:45+00:00 Eugeni Dodonov wrote:
(In reply to comment #15)
> Please test with both patches (this and the previous one)
Err.. clarifying, I meant "please test each of those patches". They do
similar thing, but in two different ways, let's find out which one works
better for this specific case.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/27
------------------------------------------------------------------------
On 2011-09-28T03:55:33+00:00 Leann Ogasawara wrote:
Hi Soren,
I've built Ubuntu test kernels for each of the patches mentioned in
comment 14 and comment 15. They are available at the following
locations. Please test and let Eugeni know your results. Thanks.
http://people.canonical.com/~ogasawara/fdo41059/comment14/
http://people.canonical.com/~ogasawara/fdo41059/comment15/
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/28
------------------------------------------------------------------------
On 2011-09-29T00:45:31+00:00 Soren Hansen wrote:
Awesome! Thanks, Leann!
I'll try them out right away.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/29
------------------------------------------------------------------------
On 2011-09-29T01:22:16+00:00 Soren Hansen wrote:
These are the timings for running xrandr with hdmi1 enabled and disabled
for the patches from comment 14 and 15:
comment14/with-hdmi1-disabled:real 0m0.115s
comment14/with-hdmi1-enabled:real 0m0.646s
comment15/with-hdmi1-disabled:real 0m0.040s
comment15/with-hdmi1-enabled:real 0m0.041s
So the one from comment15 is clearly the winner. Switching feels
instant.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/30
------------------------------------------------------------------------
On 2011-09-29T12:58:48+00:00 Eugeni Dodonov wrote:
(In reply to comment #19)
> These are the timings for running xrandr with hdmi1 enabled and disabled for
> the patches from comment 14 and 15:
>
> comment14/with-hdmi1-disabled:real 0m0.115s
> comment14/with-hdmi1-enabled:real 0m0.646s
> comment15/with-hdmi1-disabled:real 0m0.040s
> comment15/with-hdmi1-enabled:real 0m0.041s
>
> So the one from comment15 is clearly the winner. Switching feels instant.
Great to know that it works! :)
Could you also post the dmesg output with both of those patches please?
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/31
------------------------------------------------------------------------
On 2011-09-29T16:48:43+00:00 Soren Hansen wrote:
(In reply to comment #20)
> (In reply to comment #19)
> > So the one from comment15 is clearly the winner. Switching feels instant.
> Great to know that it works! :)
> Could you also post the dmesg output with both of those patches please?
Of course, sorry.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/32
------------------------------------------------------------------------
On 2011-09-29T16:49:52+00:00 Soren Hansen wrote:
Created attachment 51766
debug dmesg (patch from comment 14)
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/33
------------------------------------------------------------------------
On 2011-09-29T16:50:13+00:00 Soren Hansen wrote:
Created attachment 51767
debug dmesg (patch from comment 15)
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/34
------------------------------------------------------------------------
On 2011-10-01T07:56:50+00:00 Hernando Torque wrote:
Sorry for the late answer. I also tested with Leann's kernels (thanks
for providing them!) and got different (but not too bad) results:
Ubuntu kernel 3.0.0-12.19
* HDMI1 enabled: 1400 ms
* HDMI1 ignored: 800 ms
Ubuntu kernel 3.0.0-12.20~fdo41059cmt14 + bit_test=1
* HDMI1 enabled: 150 ms
* HDMI1 ignored: 150 ms
Ubuntu kernel 3.0.0-12.20~fdo41059cmt15
* HDMI1 enabled: 150 ms
* HDMI1 ignored: 150 ms
So both cases are equally better than the original one (I have no idea
why those numbers changed so much from Ubuntu's kernel 3.0.0-12.18 to
3.0.0-12.19).
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/36
------------------------------------------------------------------------
On 2011-10-01T07:58:27+00:00 Hernando Torque wrote:
Created attachment 51835
dmesg_cmt14_enabled
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/37
------------------------------------------------------------------------
On 2011-10-01T07:59:15+00:00 Hernando Torque wrote:
Created attachment 51836
dmesg_cmt15_enabled
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/38
------------------------------------------------------------------------
On 2011-10-01T08:11:58+00:00 Hernando Torque wrote:
Re-tested with DisplayPort ports DP1-3 ignored (so only LVDS1, VGA1 and
HDMI1-3 enabled) and got decent results for both patches:
Ubuntu kernel 3.0.0-12.20~fdo41059cmt14 + bit_test=1, DP1-3 ignored
* HDMI1 enabled: 6 ms
* HDMI1 ignored: 4 ms
Ubuntu kernel 3.0.0-12.20~fdo41059cmt15, DP1-3 ignored
* HDMI1 enabled: 6 ms
* HDMI1 ignored: 6 ms
I wanted to test this with a second system (Z68 based with an Intel HD
Graphics 3000), but xrandr shows HDMI1 being in use (monitor is
connected via DVI), so I got no idea what to do there.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/39
------------------------------------------------------------------------
On 2011-10-01T13:54:38+00:00 Hernando Torque wrote:
The patch from comment 15 is causing trouble on my second system
(monitor connected via DVI, shown as HDMI1 by xrandr): the monitor loses
the signal early in the boot process.
Times with the patch in comment 14 didn't change (170 ms for VGA1,
HDMI1-3, and ignored DP1-3).
Attaching both dmesg logs.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/40
------------------------------------------------------------------------
On 2011-10-01T13:55:57+00:00 Hernando Torque wrote:
Created attachment 51842
dmesg_sys2_cmt15_fail
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/41
------------------------------------------------------------------------
On 2011-10-01T13:57:09+00:00 Hernando Torque wrote:
Created attachment 51843
dmesg_sys2_cmt14_good
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/42
------------------------------------------------------------------------
On 2011-10-06T21:00:38+00:00 Eugeni Dodonov wrote:
Created attachment 52057
Give up on DDC detection when i2c tells us
Ok, so we got mixed results with the previous patches, and after some
investigation I finally found out why they don't work.
What happens with some of the hot-pluggable connectors is that while
they are not ready, the bits stay "stuck" (and the patches were
detecting that correctly). As soon as they are, they are no longer stuck
- but it is too late now, because previous patches already marked them
as ignored.
So by checking all the events I am getting, I can consistently detect
whether the connection is not there earlier - it is being indicated by
the -ENXIO error code being returned by the i2c_transfer call. In this
case, I modified drm_do_probe_ddc_edid to return earlier and avoid
having try repeatable to talk over those pins.
With this patch, each time a display detection is being performed (for
example, by running xrandr), the kernel should list the pins that are
being ignored into the dmesg output, so please attach it with the
testing results.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/43
------------------------------------------------------------------------
On 2011-10-06T22:45:56+00:00 Hernando Torque wrote:
Just for safety: this patch shouldn't be combined with the other two,
right?
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/44
------------------------------------------------------------------------
On 2011-10-06T23:05:29+00:00 Eugeni Dodonov wrote:
No, only this patch. The other patches are not necessary anymore.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/45
------------------------------------------------------------------------
On 2011-10-06T23:15:47+00:00 Eugeni Dodonov wrote:
Created attachment 52062
Another way to do the check if bus is alive
Besides the previous patch, if you could test this one as well, it would
be great!
It does a similar thing to the previous patch, but only affects i915
driver, while the previous one also modifies the edid detection for
other drm drivers (nouveau, radeon, ...).
This patch adds a check for i2c connectivity prior to getting the edid
data. It could be slightly faster than the previous one in case the
connection is not there (e.g., it could greatly reduce the delay with
xrandr with phantom outputs), and potentially a bit slower when the bus
is present (e.g., it could increment by some ms the xrandr time for
valid outputs).
As with the previous patch, this one should be tested on its own.
Sorry for all those patches, I am trying to figure out a way to fix it
properly, once and for all :).
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/46
------------------------------------------------------------------------
On 2011-10-07T01:03:00+00:00 Hernando Torque wrote:
Again both patches are equally fast (but slower than the previous ones):
Ubuntu kernel 3.0.0-12.19:
- HDMI1 enabled: 840 ms (690 ms with DP1-3 ignored)
- HDMI1 ignored: 200 ms ( 50 ms with DP1-3 ignored)
With patch from comment 31 (abort early/drm):
- HDMI1 enabled: 290 ms (140 ms with DP1-3 ignored)
- HDMI1 ignored: 160 ms ( 15 ms with DP1-3 ignored)
With patch from comment 34 (valid bus/i915):
- HDMI1 enabled: 290 ms (140 ms with DP1-3 ignored)
- HDMI1 ignored: 160 ms ( 15 ms with DP1-3 ignored)
Will test the second system with active HDMI1 (really DVI) tomorrow.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/47
------------------------------------------------------------------------
On 2011-10-07T01:04:27+00:00 Hernando Torque wrote:
Created attachment 52065
dmesg w/ patch comment 31
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/48
------------------------------------------------------------------------
On 2011-10-07T01:04:57+00:00 Hernando Torque wrote:
Created attachment 52066
dmesg from xrandr w/ patch comment 31
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/49
------------------------------------------------------------------------
On 2011-10-07T01:05:19+00:00 Hernando Torque wrote:
Created attachment 52067
dmesg w/ patch comment 34
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/50
------------------------------------------------------------------------
On 2011-10-07T01:05:48+00:00 Hernando Torque wrote:
Created attachment 52068
dmesg from xrandr w/ patch comment 34
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/51
------------------------------------------------------------------------
On 2011-10-07T01:48:20+00:00 Eugeni Dodonov wrote:
Great, thanks a lot for the testing and the feedback!
The patches are a bit slower than the previous one because they attempt
to improve performance while still detecting all the possible output
consistently all the time. For some outputs (such as hdmi), it turned
out that it is impossible to say whether they are present or not without
at least one ddc query - so it should take some ms. But with those
patches, we can detect if an output is not really there, so we do not
keep retrying until the final timeout and give up faster.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/52
------------------------------------------------------------------------
On 2011-10-07T10:17:42+00:00 Hernando Torque wrote:
Here are the results for the second system:
Ubuntu kernel 3.0.0-12.19:
- All: 315 ms (175 ms with DP1-3 ignored)
- Only HDMI1: 130 ms
With patch from comment 31 (abort early/drm):
- All: 280 ms (140 ms with DP1-3 ignored)
- Only HDMI1: 130 ms
With patch from comment 34 (valid bus/i915):
- All: 280 ms (140 ms with DP1-3 ignored)
- Only HDMI1: 130 ms
I obviously couldn't test with HDMI1 ignored, so that's all outputs vs.
only HDMI1. Both patches were equally fast again.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/53
------------------------------------------------------------------------
On 2011-10-07T10:18:27+00:00 Hernando Torque wrote:
Created attachment 52074
PC dmesg w/ patch comment 31
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/54
------------------------------------------------------------------------
On 2011-10-07T10:18:55+00:00 Hernando Torque wrote:
Created attachment 52075
PC dmesg from xrandr w/ patch comment 31
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/55
------------------------------------------------------------------------
On 2011-10-07T10:19:22+00:00 Hernando Torque wrote:
Created attachment 52076
PC dmesg w/ patch comment 34
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/56
------------------------------------------------------------------------
On 2011-10-07T10:19:41+00:00 Hernando Torque wrote:
Created attachment 52077
PC dmesg from xrandr w/ patch comment 34
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/57
------------------------------------------------------------------------
On 2011-10-07T18:59:47+00:00 Leann Ogasawara wrote:
Hi Soren,
In case you are interested in testing the patches from comments #31 and
#34, I've built an Ubuntu test kernel for each patch and placed them at
the following locations. Thanks.
http://people.canonical.com/~ogasawara/fdo41059/comment31/
http://people.canonical.com/~ogasawara/fdo41059/comment34/
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/58
------------------------------------------------------------------------
On 2011-10-10T07:23:42+00:00 Soren Hansen wrote:
(In reply to comment #46)
> In case you are interested in testing the patches from comments #31 and #34,
> I've built an Ubuntu test kernel for each patch and placed them at the
> following locations. Thanks.
>
> http://people.canonical.com/~ogasawara/fdo41059/comment31/
>
> http://people.canonical.com/~ogasawara/fdo41059/comment34/
Lovely, thanks!
comment31
With HDMI1 disabled, xrandr takes 0.086s on average to complete.
With HDMI1 enabled, xrandr takes 0.185s on average to complete.
comment34
With HDMI1 disabled, xrandr takes 0.085s on average to complete.
With HDMI1 enabled, xrandr takes 0.184s on average to complete.
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/59
------------------------------------------------------------------------
On 2011-10-18T11:04:09+00:00 Eugeni Dodonov wrote:
Final patches landed into intel-gfx list, thank you all for testing and
feedback!
Hopefully they will reach kernel soon :).
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/60
------------------------------------------------------------------------
On 2011-10-26T16:37:09+00:00 Seanius-e wrote:
Hi, after getting hinted to this from the kind folks in #debian-x, I'd
like to report that this does also affect radeon systems as well. I
have a radeon HD5770, and somewhere around 3.0ish I started seeing this
behavior too.
I'd like to confirm that the non-intel-specific patch also helps on my
system, though the problem is still clearly there. Instead of a dozen
(or more) 2-second stutter/hangs as the system comes up, it's a dozen
half second hangs, or feels something roughly like that. But to add
some objective measures, here's some "time xrandr" outputs from the
different combinations of patch/xorg config:
without patch, no xorg.conf "Ignore":, 3.210
with patch, no xorg.conf "Ignore": 1.060
with patch, with xorg.conf "Ignore": 0.120
without patch, with xorg.conf "Ignore": 0.117
I'd say the last two are statistically equivalent, but there is still an
obvious problem even with the patch, though it seems to be much less of
one.
This is running master as of this morning, using the radeon HD5770 card
connected over HDMI. The following is the "Ignore" config referenced
above:
Section "Monitor"
Identifier "DisplayPort-0"
Option "Ignore" "True"
EndSection
Section "Monitor"
Identifier "DVI-0"
Option "Ignore" "True"
EndSection
Section "Monitor"
Identifier "DVI-1"
Option "Ignore" "True"
EndSection
Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/62
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/855124
Title:
XRANDR operations very slow unless (phantom) HDMI1 disabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/855124/+subscriptions
References
