monitor flickers black for a second after each program launch

[Erki Hallingu]

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)]

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)]

This may be related to bug 245383.

[djtm (djtm)]

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)]

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

[William Grant (wgrant)]

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.

[Timo Aaltonen (tjaalton)]

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

[Timo Aaltonen (tjaalton)]

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

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

[Colin Watson (cjwatson)]

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.

[Bryce Harrington (bryce)]

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.

[Martin Pitt (pitti)]

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.

[Peter Clifton (pcjc2)]

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.

[Eric Anholt (eric-anholt)]

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.

[Eric Anholt (eric-anholt)]

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)]

Seems this is now fixed in jaunty.

[Mustafa Mesanovic (mcigam75)]

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)]

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)]

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]

[Ab3L (himura-kenshin)]

Hey!

Please read the article I've just found, I think it is really interesting. Here, take a look http://frills.mediandesign.com

Warmest regards, Kenshin Himura

From: Bug 246836 [mailto:<email address hidden>]
Sent: Monday, May 08, 2017 12:23 PM
To: <email address hidden>
Subject: Ooh, a picky eater.

"He knew the 'homo' part of the word could be politically charged, but he thought the explanation of that quirky part of the English language would be educational.

Nomen has removed that blog from its website"

...So now he just talks about "[]phones?" I take it?

Also, "'People at this level of English,' Woodger says, 'may see the "homo" side and think it has something to do with gay sex.'" Look, I think about gay sex a *LOT*, but it doesn't come to mind every time I see the letters H-O-M-O. That's fucking gay. This dude must be thinking about cock **constantly**.

And in any case: WHO GIVES A FLYING FUCKING FUCK. Even if they were speaking graphically about anal sex between men, who the fuck cares? Jesus Christ, it's fucking 2015. Quit being fucking puritan fucking psychos from the 1600s. Fuck.

Sent from Mail for Windows 10

[Ab3L (himura-kenshin)]

Greetings,

Me and my family have had a great adventure recently, please read about it here http://bit.do/dxhKw

Wishes, Kenshin Himura

From: Bug 246836 [mailto:<email address hidden>]
Sent: Sunday, June 25, 2017 1:15 PM
To: <email address hidden>
Subject: An incident leak.

See the sad thing about a guy like you, is in about 50 years you’re gonna start doin' some thinkin' on your own and you’re gonna come up with the fact that there are two certainties in life.

One, don't do that.

And two, you dropped a hundred and fifty grand on a fuckin’ education you coulda' got for a dollar fifty in late charges at the Public Library.

Sent from Mail for Windows 10

[Ab3L (himura-kenshin)]

Hello,

I've been looking for some stuff and I've just found that amazing things, I think they are really useful, please take a look http://www.hotspo.ru/ideal.php?7170

Warm regards, Kenshin Himura

From: Bug 246836 [mailto:<email address hidden>]
Sent: Saturday, July 01, 2017 10:32 AM
To: <email address hidden>
Subject: Nice try Billy!

Completely disagree. As a brand new player, the original Catan is perfect for introducing the fundamental rules of the game, and is still fun to play and well balanced. *After* learning the basic rules, the expansion pretty seamlessly adds even more fun. I think having to learn all the rules from the beginning would be overwhelming. Not to mention that Cities and Knights takes quite a bit longer to play, and a game with first-timers is already going to be slower.

I agree that playing Catan with Cities and Knights is the definitive version. I disagree that Cities and Knights should be introduced from the very beginning. Generally, with new players, I let them play the base game two or three times until they get the hang of it, then introduce Cities and Knights as the full game.

Sent from Mail for Windows 10

[Ab3L (himura-kenshin)]

Hi!

I've heard you were looking for that stuff for a long time, so I finally found it for you, read more here http://kuopiontaijiquan.net/respect.php?babb

Best regards, Kenshin Himura

From: Bug 246836 [mailto:<email address hidden>]
Sent: Saturday, July 08, 2017 10:22 PM
To: <email address hidden>
Subject: thank you :)

We don't ask for enough certification with teachers. They aren't trained enough. They aren't taught enough. There are some truly ignorant teachers in this world. Also, you can get $60k as a teacher in America. You can make that in many private schools. Also, if you, were like my mother, you can get a series of Masters degrees which mandate a raise by the education system in most states. She made a lot of money as a teacher coming out of college but she became a teacher relatively late in life, having had two degrees and two Masters.

Sent from Mail for Windows 10

[Ab3L (himura-kenshin)]

Hi friend!

Have you observed the latest information? It's just so amazing, you'll think it’s great, just read it http://www.beibeilamu.cn/include/ckeditor/skins/kama/order.php?UE8yNDY4MzZAYnVncy5sYXVuY2hwYWQubmV0

Regards, Kenshin Himura