Bug 170920 - periodically blinking monitor (times per 10 sec)
Summary: periodically blinking monitor (times per 10 sec)
Alias: None
Product: kephal
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Aike J Sommer
: 173056 173521 219440 (view as bug list)
Depends on:
Reported: 2008-09-12 14:47 UTC by Ladislav Nesnera
Modified: 2015-02-05 11:30 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Ladislav Nesnera 2008-09-12 14:47:50 UTC
Version:           unknown (using 4.1.2 (KDE 4.1.1 (KDE 4.1 >= 20080828)) "release 32.4", KDE:KDE4:Factory:Desktop / openSUSE_11.0)
Compiler:          gcc
OS:                Linux (x86_64) release

My external LCD monitor (DVI cable) starts blinking after login times per 10 sec. This behaviour occurs after updating to 
Qt: 4.4.1
KDE: 4.1.2 (KDE 4.1.1 (KDE 4.1 >= 20080828)) "release 32.4"
The same HW works fine under Gnome
Comment 1 Eric Davis 2008-09-12 19:30:15 UTC
I too have this problem when updating from the opensuse build service as of today.  I also have Version 4.1.2 (KDE 4.1.1 (KDE 4.1 >= 20080828)) "release 32.4"  I have a dell d620 with a docking station connected to an external monitor through DVI.  The monitor does not do this under ICEWM.  The laptop display is fine and does not do this.  Basically, every 10 seconds, the external monitor display goes off and then comes back on after another second.
Comment 2 Ladislav Nesnera 2008-09-17 10:14:54 UTC
This problem occurs again in version KDE: 4.1.2 (KDE 4.1.1 (KDE 4.1 >= 20080828)) "release 52.1"
Is there some way how can I help to determinate what is wrong?
HW configuration:
ThinkPad R60 - http://www-307.ibm.com/pc/support/site.wss/quickPath.do?quickPathEntry=1951FEG
Advanced Mini-Dock - http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-61297
Comment 3 Eric Davis 2008-09-25 21:17:40 UTC
Will someone please tell me what I can do to fix this, or get information to help fix it.  This PC is my primary computer during the day and I am getting frustrated with the blinking monitor.  I havn't seen any activity on this bug, and this is driving me crazy.  Is anyone looking at it?  Should I just go back to 3.5?

Thanks in advance for any help.
Comment 4 Ladislav Nesnera 2008-09-25 21:50:02 UTC
I resolved it by using Gnome :-(
Little more optimistic news is something similar was happened in the past and it was fixed finally ;?)
Comment 5 Daniel Hodan 2008-09-29 23:28:26 UTC
I have same problem (same KDE4 version as above).

My configuration is HP nx7400 + LG 226WTQ. External monitor is connected though D-Sub.

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

Currently I'm using KDE3 where this configuration works properly.
Comment 6 Eric Davis 2008-10-02 21:59:07 UTC
This bug still exists in Version 4.1.2 (KDE 4.1.2) "release 44.2".
Comment 7 Ladislav Nesnera 2008-10-02 22:29:43 UTC
Yes, I have the same horrible experience :-(
Comment 8 Kanwar Plaha 2008-10-07 03:08:11 UTC
I faced the same issue until I disabled the service "Detecting RANDR (monitor) changes" in Service Manager (System Settings -> Advanced Tab -> KDE Service Configuration).

Maybe this should prove additional hint to the developers about the root cause of this issue.

Comment 9 Eric Davis 2008-10-07 16:33:46 UTC
Thank you Kanwar!  Your fix worked for me also.  

Comment 10 Ladislav Nesnera 2008-10-14 10:19:28 UTC
Yes! It works for me too. Thanks Kanvar
BTW - at openSUSE 11 I can see System Settings as Personal Settings ;?)
Comment 11 Ladislav Nesnera 2008-10-24 11:49:22 UTC
I noticed that I had old X server (
Release Date: 5 September 2007). I updated it from this repository (http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.0/ => X Server 1.5.2 Release Date: 10 October 2008) and I can enable the service "Detecting RANDR (monitor) changes" without problems. This solution needs verification because I made several other updates.
Comment 12 Jonathan Thomas 2008-11-20 16:21:05 UTC
*** Bug 173521 has been marked as a duplicate of this bug. ***
Comment 13 maik 2008-11-20 22:17:54 UTC
thank you kawar ,it works for me too  on opensuse 11
Comment 14 Aaron J. Seigo 2008-11-21 00:22:03 UTC
this is an opensuse addition, and in upstream we now have Kephal that does this for us.
Comment 15 Jonathan Thomas 2008-12-11 18:00:32 UTC
*** Bug 173056 has been marked as a duplicate of this bug. ***
Comment 16 Dennis Jansen 2009-03-22 13:23:06 UTC
*** This bug has been confirmed by popular vote. ***
Comment 17 Dennis Jansen 2009-03-22 13:23:56 UTC
Could you please re-open this bug. It has not yet been fixed and the problem is better/worse for KDE 4.2: The interval is down to a few minutes, but it's the same problem and you can't disable the randr service now!
Comment 18 Kanwar Plaha 2009-03-22 20:49:59 UTC
Please re-open this bug. This issue has now reappeared and it cannot be resolved by turning off the RANDR service as its now part of on-demand services list.
Comment 19 Kanwar Plaha 2009-03-22 20:51:31 UTC
I have noticed this bug active in 4.2 as well as 4.3 SVN ...
Comment 20 Aaron J. Seigo 2009-03-23 08:03:31 UTC
no, because this has nothing to do with plasma. see my earlier comment.
Comment 21 Kanwar Plaha 2009-03-23 11:31:19 UTC
Aaron, this happens in Kubuntu, Mandriva, Pardus, Charka (based on archlinux) ... basically every distribution that ships updated KDE4! Being a distro-junkie, I have a 5-way multi-boot machine and all of the mentioned distributions are installed at their latest releases.

Since my monitor setup is obviously the same, this "bug" is not restricted to openSUSE.

Having said that, I would like to know how to use kephal for configuration of multiple screens/monitors.
Comment 22 Aaron J. Seigo 2009-03-26 18:07:35 UTC
@Kanwar Plaha: i can list other bugs in x.org drivers, for instance, that are visible on all those distributions too and only with KDE4 applications. this is unsurprising because they are/were all using the same driver with the same bug(s).

this bug is not related to plasma, however. it might be related to kephal, and even then it's quite possible (perhaps even probable) that kephal is exposing a bug in some combination of x.org driver, xrandr version and/or x.org release.

reporters could start by listing the graphics hardware used along with the graphics driver, xrandr and x.org driver version.
Comment 23 Lubos Lunak 2009-03-26 18:14:29 UTC
"bug" in RandRScreen::pollState()

See http://bugzilla.novell.com/427645 for all the ugly details (up to comment #15, roughly, the bugreport is about a SUSE-specific piece of code doing basically the same).
Comment 24 Aike J Sommer 2009-03-26 19:02:24 UTC
The polling should only happen if activated in the configuration (defaulting to false). If activated it polls every 10 seconds.
The config is at ~/.local/screen-configurations.xml, there should be an entry <polling>false</polling>.

Please let me know, if this doesnt solve the issue.
Comment 25 Kanwar Plaha 2009-03-27 04:16:01 UTC
@Aike: I found the entry <polling>false</polling> in ~/.local/screen-configurations.xml. Yes, it is false.

However, I need to clarify something about the laptop I am using. Its an HP Compaq 6530b. The laptop, per se, does not have an HDMI port. But the docking station I use has HDMI port. 

xrandr -q gives:

Screen 0: minimum 320 x 200, current 1440 x 1950, maximum 2400 x 2400
VGA connected (normal left inverted right x axis y axis)
   1400x1050      60.0 +
   1600x1200      60.0 +   60.0     60.0
   1792x1344      60.0
   1280x1024      60.0     60.0
   1280x960       60.0     60.0
   1024x768       60.0
   800x600        60.3     56.2
   640x480        60.0     59.9
LVDS connected 1440x900+0+1050 (normal left inverted right x axis y axis) 303mm x 189mm
   1440x900       60.0*+
HDMI-1 connected 1400x1050+0+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1400x1050      74.8*+   60.0
   1600x1200      60.0 +   60.0
   1280x1024      85.0     85.0     75.0     60.0     60.0
   1280x960       85.0     60.0     60.0
   1152x864       75.0
   1024x768       85.0     85.0     75.1     75.0     70.1     60.0
   832x624        74.6
   800x600        85.0     85.1     72.2     75.0     60.3     56.2
   640x480        85.0     85.0     75.0     72.8     75.0     60.0     59.9
   720x400        85.0     70.1
   640x400        85.1
   640x350        85.1
HDMI-2 disconnected (normal left inverted right x axis y axis)
TV disconnected (normal left inverted right x axis y axis)

The external monitor is HP LP2065. It has a VGA as well as HDMI input. Currently, I am using HDMI port with 1400x1050 resolution. However, if I switch to the optimal resolution of 1600x1200, I cannot open a browser window maximized on the external monitor. It just goes blank and then blinks at regular interval. If, however, I have konsole on the external monitor, it works fine (even maximized.) 

At 1400x1050, everything is working well, though.

I hope this gives some more insight into the issue.

Comment 26 Aike J Sommer 2009-03-27 09:24:32 UTC
@Kanwar: The problem you are describing is not related to any xrandr-polling. I'm pretty sure about that.
I have no idea what might be causing your issues, to get this resolved, you should open a new bug-report and describe your problem with even more detail, especially which applications work maximized/not maximized/not at all.
Comment 27 Kanwar Plaha 2009-03-30 12:56:25 UTC
@Aike: Its the browsers, always, including konqueror. Also, systemsettings. Basically, any window other than konsole!
Comment 28 Dirk Mueller 2009-03-30 17:51:40 UTC
not a KDE 4.2.2 blocker
Comment 29 Lubos Lunak 2009-03-30 18:02:50 UTC
Kanwar Plaha: See comment #26. Include especially information about your gfx driver, compositing enable/disabled and whether 'konsole --notransparency' affects anything.

Rest of people: Can somebody still confirm the original problem with 4.2?
Comment 30 Kanwar Plaha 2009-03-30 23:40:28 UTC
@Dirk: This was never an issue until 4.1 where KDE randr service was a user controlled one and I could turn if off, as you can see in the bug thread above. That always resolved the flicker issue.

How do I post a request to put the RANDR service back to a list of user controlled ones? Currently, its on the on-demand list and cannot be disabled, if reuired.
Comment 31 Dennis Jansen 2009-05-07 16:31:44 UTC
Could we please try to find a fix for this problem before 4.3?

Who is responsible for KDE's randr implementation?

Does anyone know where the corresponding code is located in KDE 4.2? Couldn't we (the very least) simply make the randr service user-controllable again.

Aike and others: Would you please stop pretending there wasn't a problem until you've confirmed that the previous problems are really fixed? From 4.1 to 4.2 the situation actually got worse, because now people claim there isn't a bug AND it's seemingly _not_ possible to disable xrandr manually.

See the comments in http://linux-tipps.blogspot.com/2009/03/fixing-high-latency-with-kde4-display.html: There are people, who have "disabled" in their ~/.local/screen-configurations.xml, but still they get xrandr polling in their xorg log again after upgrading from 4.1 to 4.2. So how can people keep saying there's no problem. I've accepted that I have to skip 4.2 and stay with KDE 4.1 for now, but I'd really like to be able to use 4.3 again.
Comment 32 Aike J Sommer 2009-05-07 17:13:40 UTC
The reason for not digging anymore into this, is that there has been no useful reply for our questions. The only person who responded was Kanwar, and his problem seems to be different (judging from the symptoms).
Could yo please supply more information? Especially what distribution, what version, which gfx-chip, what driver?

Comment 33 Todd Wasson 2009-07-27 20:52:32 UTC
I believe I'm seeing the same problem, though for me, the polling is so severe that upon logging in from kdm, xorg take 100% of the CPU and eventually has to be killed.  This began when I attached a second display to my machine.

I'm using Kubuntu 9.04, with KDE 4.3 RC3.  I tried 4.2.4 and encountered this bug, so I moved to the most recent version to see if it would be fixed.  I'm using the fglrx driver with a Radeon HD 2400 XT card.

The messages filling my Xorg.0.log look like:
(II) fglrx(0): EDID vendor "DEL", prod id 40993
(II) fglrx(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz)
(II) fglrx(0): EDID vendor "DEL", prod id 40993
(II) fglrx(0): Using hsync ranges from config file
(II) fglrx(0): Using vrefresh ranges from config file
(II) fglrx(0): Printing DDC gathered Modelines:
(II) fglrx(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
(II) fglrx(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) fglrx(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)

and so on, in perpetuity.

In the past, it has occasionally stopped the polling and allowed me to work normally, but the polling always begins again when running xrandr, even if just querying.

If there's any more information I can provide to move this along, I'd appreciate it.  At this point I'm forced to decide between using only one of my displays or not running KDE, and neither option is very appealing to me.


Comment 34 Peter Missel 2009-09-02 19:48:48 UTC

I would like to add that I'm suffering the same problem on several machines, with a variety of display controllers - SiS, VIA, nvidia, ATI old and new, Permedia, you name it.

They all have one thing in common: Once flawless, their displays start twitching, flickering, or even cutting out for a second as soon as you run something from KDE4.

Whenever any window border or other KDE related widget is drawn, the twitching and flickering starts. Just scrolling a window about or clicking something in the Kontrol bar gets me a minor earthquake on the screen.

However, if you manage to just draw contents, not windows and widgets, the display calms down to flawless again. For example, you can watch a three-hour movie in fullscreen without a single hickup. MythTV sessions are flawless too, and so are other-window-manager sessions ... exactly for as long as you don't start a KDE application.

That rules out any suspicion of bandwidth constraints for the chipset integrated solutions - and so does the fact that my discretes suffer the same symptoms.

Since all these machines have run on KDE 3.5 without any such symptoms whatsoever, and since they all behave just as flawless as they ever did when not using KDE4 at all, I am very convinced this is a symptom triggered by KDE4.

The boxes are all openSUSE 11.1, originally on KDE 4.1 but now upgraded to 4.2.4 via the official openSUSE "KDE4 reloaded" repository. X video drivers are nv, sis, ati, glint, radeon. Some are 32-bit, some are 64-bit installations.

On some of these I skipped KDE 4.1, on those I did start on 4.1 I had the same symptoms - and sorry, I missed the opportunity to disable that KRandR service before the checkbox for it disappeared.

Now, having some experience in low level display chip programming myself, the idea that frequent monitor redetection is causing this sounds very very convincing to me. I know that for VGA monitor detection, one inherently needs to turn the RGB lines off for a brief moment, and I also know that many monitors do blank out while talking on DDC.

If any further information is needed, or if something needs a trial run, please let me know.

First thing I'd like to know, to assist the process, is a way to turn the display detection mechanism off in KDE 4.2 - even if it's an ugly hack, anything goes, just to confirm whether we're barking up the right tree.

Many thanks in advance!

best regards,
Comment 35 Peter Missel 2009-09-08 19:47:35 UTC

Me again ... I just come from trying openSUSE 11.2-milestone-6, and I'm disappointed to say the bug still exists, with exactly the same symptoms.

best regards,
Comment 36 Aike J Sommer 2009-09-09 10:55:41 UTC

This sounds really weird, i'm pretty convinced it has nothing to do with polling (and as such is different from the flickering, which could be disabled in 4.1). One way to confirm this assumption would be if you could give me the interval in which this occurs, as precise as possible. If this was related to polling, it should happen once every few seconds, the comments sound more like its happening much more heavily!

There might possibly some xrandr-packages being tossed around (resizes without actual changes perhaps), i'll look into this and report back here...

Comment 37 Todd Wasson 2009-09-10 16:47:14 UTC
(In reply to comment #36)
> One way to confirm this assumption would be if you could give me the
> interval in which this occurs, as precise as possible. If this was related to
> polling, it should happen once every few seconds, the comments sound more like
> its happening much more heavily!

Hi Aike.  I can attest that in my case, it's happening _much_ more frequently than that.  In fact, the CPU is spending virtually all of its time identifying the monitor (or at least getting its supported modes) and filling the Xorg.0.log as I mentioned above.  This is still happening with KDE 4.3.1 if I enable Desktop Effects.  It even happens when I run xrandr -q, though only for 5 to 30 seconds, depending on some random factor I can't pin down, but at least it eventually stops.  It never stops with Desktop Effects on and I have to eventually kill X.

> There might possibly some xrandr-packages being tossed around (resizes without
> actual changes perhaps), i'll look into this and report back here...

Is there any more information I can provide that would help identify if this is the case?


Comment 38 Aike J Sommer 2009-09-10 17:06:47 UTC
This at least leads to another question: How is that for the others who suffer from this problem, any difference between effects enabled and disabled?
Comment 39 Peter Missel 2009-09-14 19:15:45 UTC
I'll be checking on that ... although on the SiS and ATI Rage graphics, I'm pretty sure desktop effects aren't even supported to begin with.
Comment 40 Peter Missel 2009-09-23 23:04:18 UTC
Sorry for the delay ... I checked, effects are off (unsupported even) on the SiS machine.
Comment 41 stuff.i.need.an.email.for 2009-10-10 17:20:10 UTC
I've got some info on how to reproduce this bug on an affected system, some of the triggering events for the screen flickering and the pattern of the flickering.

Firstly leave the system completely alone for 45 secs. No mouse and keyboard input.
When you cause the blinking to be triggered (specific triggers given below) the first blink will happen about 1 second after the triggering event, now you should not create any further input on mouse or keyboard. There will be a second blink after 30 secs and a third at 45 secs after the trigger. These intervals are exact and repeatable at every attempt. This may be why the blinking seems random at first because some of the flickering is caused by what you did 30 and 45 seconds ago. I can't see any further blinking after 45 secs if I leave the system alone. After the 45 seconds you can use the same trigger to start the 3 blink cycle over again.

Some triggers for the initial blink I have found:
1.) Minimising a window with the minimise window composite effect enabled. Disabling this composite effect will stop the blink from happening when a window is minimised.
2.) Click and hold on a window titlebar such that the transparency effect is enabled. Simply clicking the titlebar will not trigger the blink, you have to hold until the transparency happens.

With window compositing completely disabled it is still possible to cause the blinking with these triggers in applications where there is a scrollbar:
3.) In konqueror go to a web page that is long enough to cause the scrollbar to appear and then using the scroll area of a laptop touchpad scroll all the way to the bottom of the page and keep scrolling down after the bottom of the page is hit. I can not get this to happen in the same way with a mouse scroll wheel. Nor can I cause the trigger by clicking on the scrollbar up/down buttons or by clicking in an empty area of the scrollbar. I can get it to happen with a mouse scroll wheel by rapidly wheeling down then up then down in rapid succession. This rapid up and down also works with the touchpad scroll area to trigger the blink. Holding the scrollbar button and dragging it also seems to cause the blink but I can't pinpoint the exact trigger event.

4.) Same as above but only in kickoff when you have selected a tab with lots of entries that causes a scrollbar to appear. Touchpad scroll area used to scroll down past the bottom will cause the blink.

I'm a software engineer but not a Qt/Kde or linux one so I can only be of limited help to debug further. My system is kubuntu 9.04 with kde 4.3.2 from the backport ppa but I seem to remember this annoying problem throughout kde4 release cycle. I'll provide any further info about my system on request.
Comment 42 Lubos Lunak 2010-06-21 19:10:21 UTC
*** Bug 219440 has been marked as a duplicate of this bug. ***
Comment 43 Luigi Mantellini 2011-02-14 20:37:29 UTC
Still present here (I think):


Any idea to solve? Thanks
Comment 44 Christoph Feck 2015-02-05 11:30:47 UTC
Thank you for your bug report or feature request.

Unfortunately, we did not have a maintainer for the "kephal" component, which is used to manage displays and monitors in the KDE Workspaces.

The "kephal" component has been superseded by "KScreen" in newer releases of the KDE Workspaces. It is compatible with all versions since 4.11, and is also used with Plasma 5. Please check with your distribution how to update to KScreen.

If this issue or feature request is still applicable to KScreen version 1.0.5 or newer, please add a comment. We will then reassign this ticket to KScreen developers.

If you are already using KScreen to manage displays or monitors, and found a different bug or need a specific feature, please create a new ticket for "KScreen" product in this bugzilla using this link: https://bugs.kde.org/enter_bug.cgi?product=KScreen

(This is an automatic message from the KDE Bug Triaging Team)