Ubuntu

monitor flickers black for a second after each program launch

Reported by Erki Hallingu on 2008-07-09
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
High
xorg-server (Ubuntu)
Undecided
Unassigned

Bug Description

Hi,

my monitor flickers black for a second after each program launch. In Hardy it flickered only when launching wine but in Intrtepid it flickers with every program, regardless.

I have configured extended virtual desktop with laptop(1024x768@60) and external monitor (1280x1024@60), Intel i945GM video.

Flickers only external monitor laptop screen stays ok at the same time.

>>>
root@ubuntu:~# lsb_release -rd
Description: Ubuntu intrepid (development branch)
Release: 8.10

root@ubuntu:~# apt-cache policy xorg
xorg:
  Paigaldatud: 1:7.4~0ubuntu1
  Kandidaat: 1:7.4~0ubuntu1
  Version table:
 *** 1:7.4~0ubuntu1 0
        500 http://archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

Erki Hallingu (erkiha) wrote :

Also with every program launch two lines are added to the end of Xorg.0.log:

(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.

Jon Packard (jonpackard) wrote :

This may be related to bug 245383.

djtm (djtm) wrote :

I still have this problem. Can you confirm this?

So either the other bug can't be a duplicate or it's not really fixed.

Oibaf (oibaf) wrote :

I am confirming this issue on an updated 8.10. I am using the open source -ati driver on a RV530.

Changed in xorg-server:
status: New → Confirmed

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.

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

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.

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.

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.

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.

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.

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

commit 10f26957f8392eb7913172f482f66eb71252761d
Author: Eric Anholt <email address hidden>
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)

Oibaf (oibaf) wrote :

Seems this is now fixed in jaunty.

Changed in xorg-server:
status: Unknown → Fix Released
Oibaf (oibaf) on 2009-02-12
Changed in xorg-server:
status: Confirmed → Fix Released
Mustafa Mesanovic (mcigam75) wrote :

hi,

monitor flickers in jaunty - I use opensource ati driver

my ati card:
01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5200]

regards

Ab3L (himura-kenshin) wrote :

Hi,

In jaunty with opensource ati driver, my screen seems to flicker black for a second each random intervals, not only when I launch a new program.

In the beta of Karmic, I noticed that this seems depend on the size of the window: the bigger the windows are, the shorter the intervals between black screens are.

Anyway, this problem is also more frequent with softwares to chat, like kvirc or xchat.

My graphic card is (from lspci):
01:00.0 VGA compatible controller: ATI Technologies Inc RV516 XT Radeon X1600 Series (Primary)
01:00.1 Display controller: ATI Technologies Inc RV516 XT Radeon X1600 Series (Secondary)

(and from technical sheet):
ATI Radeon X1650SE
    * Mémoire DDR 512 Mo
    * Ports E/S : S-Vidéo, DVI, VGA

dave_est_2009 (siefert-david) wrote :

I am getting the same behavior that Ab3L reported. Everytime it happens, my /var/log/Xorg.0.log shows:

(II) RADEON(0): EDID vendor "DEL", prod id 40995
(II) RADEON(0): Using hsync ranges from config file
(II) RADEON(0): Using vrefresh ranges from config file
(II) RADEON(0): Printing DDC gathered Modelines:
(II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
(II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz)
(II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
(II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz)
(II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz)
(II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz)
(II) RADEON(0): EDID vendor "DEL", prod id 40995
(II) RADEON(0): Using hsync ranges from config file
(II) RADEON(0): Using vrefresh ranges from config file
(II) RADEON(0): Printing DDC gathered Modelines:
(II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
(II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz)
(II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
(II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz)
(II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz)
(II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz)

Hardware: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series]

Changed in xorg-server:
importance: Unknown → High
Changed in xorg-server:
importance: High → Unknown
Changed in xorg-server:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.