← Back to team overview

registry team mailing list archive

[Bug 307306] Re: upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow

 

Launchpad has imported 9 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=19037.

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 2008-12-11T23:51:52+00:00 William Grant wrote:

Running Ubuntu jaunty on an i915 laptop, I've recently upgraded to
libxrandr2 1.2.99.2. Upon login in the the first new X session after
that, my screen started flickering constantly. Analysis of the xserver
log showed that it was requesting the EDID lots of times. libxrandr
1.2.3 didn't show that problem, and downgrading to it returns sanity.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/1

------------------------------------------------------------------------
On 2008-12-12T09:24:35+00:00 Timo Aaltonen wrote:

*** Bug 19047 has been marked as a duplicate of this bug. ***

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/2

------------------------------------------------------------------------
On 2008-12-12T09:30:32+00:00 Timo Aaltonen wrote:

my 965 isn't affected, but apparently 945 is:

https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/307306

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/3

------------------------------------------------------------------------
On 2008-12-30T15:55:45+00:00 Colin Watson wrote:

My i965 (PCI ID 8086:2a02/8086:2a03) is affected. Downgrading libxrandr
to 1.2.3 is awkward (I'm running Ubuntu Jaunty and a bunch of other
stuff depends on it, which I don't really want to downgrade), but I
looked through the changes between 1.2.3 and 1.2.99.2 and made a guess:
forcing XRRGetCrtcTransform to think it's talking to a pre-1.3 server
seems to be helping so far.

In my case, it was a little bit sluggish to start with although not
hugely, but the EDID request storm really took off after unplugging my
laptop from power and Ethernet and taking it away from my desk.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/4

------------------------------------------------------------------------
On 2008-12-31T00:41:22+00:00 Bryce Harrington wrote:

Ubuntu is currently using the 1.5.99.3 server, however there are a
number of randr fixes in the git tree for the 1.6 branch subsequent to
this version:

commit a82f10c5dd9fa74ff18759ab288bbd9c8b7ac4de
    randr: clear primaryOutput when the output is deleted

commit 2bc53ce66828b6c177e3298fa2f326c77c93e136
    randr: use primary output for RRFirstOutput()

commit f0234a9eb88ed103bca7db73a833c472ab95b48f
    randr: Mangle GetScreenResources sort order based on primary output

commit 2ef02833d614c42693e019a444560e84f501b5dc
    randr: Mangle compat Xinerama reply based on primary output

commit 0bdfdaa7df8105c7ffc3248a4fdd5f64da67103c
    randr: Add [GS]etOutputPrimary

Looking at the diffs, none jump out at me as obvious fixes for this
problem, but especially the first two sound to me like potentially
relevant.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/5

------------------------------------------------------------------------
On 2009-01-01T09:45:28+00:00 Martin Pitt wrote:

I confirm the behaviour that Colin describes on my GM945: As long as I
have the laptop docked (no battery) or undocked with power, it works
reasonably, and I "only" get some 30 EDID detects in Xorg.0.log. But as
soon as I unplug the power (I guess it's any change to power source
which triggers this), the flood starts and the desktop becomes mostly
unusable.

I tested Bryce's proposed workaround
(http://launchpadlibrarian.net/20825929/disable_transform.patch) and it
didn't work. No noticeable change.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/8

------------------------------------------------------------------------
On 2009-01-17T16:18:45+00:00 Peter Clifton wrote:

Tracked this down with some of the ubuntu-x team..

The code in question is gnome-desktop / gnome-settings-daemon / gnome-
power-manager / gdk.

g-p-m is sending a load of brightness change requests to produce a
dimming effect when it chanes the backlight brighness.

For each change, we get an output property notification which is picked
up by several listening clients.

gnome-settings-daemon listens to the Xrandr notifications directly, and
reprobes information on recieving each backlight change notification.

gnome-power-manager's code-paths to listen directly to the Xrandr
notifications seem to be disabled (if (FALSE)), however code _is_ called
to attach to GDK's "monitors-changed" signal. When that is triggered,
g-p-m probes Xrandr for events.

GDK is emitting a "monitors-changed" event for every Xrandr event
encountered. As an _untested_ theory.. I'm wondering if the bug relating
to the "window" property on some Xrandr notifications - (fixed in the
noted libxrandr update), might have previously been causing GDK to drop
some of those events?

Alberto Milone has worked up patches to g-s-d and g-p-m following my
discovery that Xrandr 1.3 now supports an API to query for the "Current"
data, rather than triggering a re-probe of the hardware.

I'm also a little suspicious that GDK's "monitors-changed" event is
triggering rather more often than it needs to be, given the description
of that event.) Alberto wonders if any TV-out output property changes
are relevant to that though. My local fix to workaround the problem
patches GDK to ignore Xrandr notifications for changes to output
properties.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/22

------------------------------------------------------------------------
On 2009-01-30T18:53:24+00:00 Eric Anholt wrote:

So is there any evidence of the server actually doing anything wrong?
It sounds like we have at least some instances of common clients
misbehaving.

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/54

------------------------------------------------------------------------
On 2009-01-30T19:37:13+00:00 Eric Anholt wrote:

keithp pointed out that in fact the server *was* doing the wrong thing.

commit 10f26957f8392eb7913172f482f66eb71252761d
Author: Eric Anholt <eric@xxxxxxxxxx>
Date:   Fri Jan 30 19:06:17 2009 -0800

    randr: Avoid re-querying the configuration on everything but GetScreenResources.
    
    The new path should only re-query on the other requests when we haven't
    gathered the information from the DDX yet (such as with a non-RandR 1.2 DDX).
    
    Bug #19037.

(confirmed that with this patch I can xrandr --current --props without
hitting the re-query)

Reply at: https://bugs.launchpad.net/gnome-
desktop/+bug/307306/comments/55


** Changed in: xorg-server
   Importance: Unknown => High

-- 
upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow
https://bugs.launchpad.net/bugs/307306
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for gnome-desktop.