Bug 427645

Summary: KDE4 desktop (likely some RANDR tool) triggers DDC scan every 10 seconds
Product: [openSUSE] openSUSE 11.0 Reporter: Peter B <auxsvr>
Component: KDE4 WorkspaceAssignee: Lubos Lunak <llunak>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P2 - High CC: alinm.elena, eich, f.leerink, felix, jdelvare, mlatimer, monkey9, sndirsch, stefan.bruens, varkoly
Version: Final   
Target Milestone: ---   
Hardware: x86   
OS: openSUSE 11.0   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Xorg log
xorg configuration file
testcase

Description Peter B 2008-09-19 09:37:16 UTC
Created attachment 240499 [details]
Xorg log

I'm using xorg-x11-7.4-4.1 and xorg-x11-driver-video-7.4-1.5 from the Xorg repository.

Every 10 seconds Xorg freezes for ~1 second, i.e. keyboard input and display are delayed. It appears that Xorg performs a DDC scan every 10 seconds, because after the freeze the following is added to Xorg.0.log:

(II) RADEON(0): EDID vendor "HTC", prod id 40000
(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 "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz)
(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 "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 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   31.50  640 664 704 832  480 489 491 520 -hsync -vsync (37.9 kHz)
(II) RADEON(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz)
(II) RADEON(0): Modeline "640x480"x0.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) RADEON(0): Modeline "720x400"x0.0   35.50  720 738 846 900  400 421 423 449 -hsync -vsync (39.4 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 "1024x768"x0.0   78.80  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.1 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 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 "1024x768"x0.0   44.90  1024 1032 1208 1264  768 768 776 817 interlace +hsync +vsync (35.5 kHz)
(II) RADEON(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 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 "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 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): Modeline "640x480"x85.0   35.71  640 672 736 832  480 481 484 505 -hsync +vsync (42.9 kHz)
(II) RADEON(0): Modeline "800x600"x85.0   56.55  800 840 928 1056  600 601 604 630 -hsync +vsync (53.5 kHz)
(II) RADEON(0): Modeline "1024x768"x85.0   94.39  1024 1088 1200 1376  768 769 772 807 -hsync +vsync (68.6 kHz)
(II) RADEON(0): Modeline "640x480"x70.0   28.56  640 664 728 816  480 481 484 500 -hsync +vsync (35.0 kHz)
(II) RADEON(0): Modeline "1280x960"x60.0  102.10  1280 1360 1496 1712  960 961 964 994 -hsync +vsync (59.6 kHz)
(II) RADEON(0): Modeline "1024x768"x60.0   64.11  1024 1080 1184 1344  768 769 772 795 -hsync +vsync (47.7 kHz)
(II) RADEON(0): Output: VGA-0, Detected Monitor Type: 1
(II) RADEON(0): EDID data from the display on output: VGA-0 ----------------------
(II) RADEON(0): Manufacturer: HTC  Model: 9c40  Serial#: 0
(II) RADEON(0): Year: 2003  Week: 10
(II) RADEON(0): EDID Version: 1.1
(II) RADEON(0): Analog Display Input,  Input Voltage Level: 0.700/0.700 V
(II) RADEON(0): Sync:  Separate
(II) RADEON(0): Max Image Size [cm]: horiz.: 33  vert.: 25
(II) RADEON(0): Gamma: 2.22
(II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) RADEON(0): redX: 0.631 redY: 0.328   greenX: 0.275 greenY: 0.600
(II) RADEON(0): blueX: 0.143 blueY: 0.057   whiteX: 0.280 whiteY: 0.311
(II) RADEON(0): Supported VESA Video Modes:
(II) RADEON(0): 720x400@70Hz
(II) RADEON(0): 720x400@88Hz
(II) RADEON(0): 640x480@60Hz
(II) RADEON(0): 640x480@67Hz
(II) RADEON(0): 640x480@72Hz
(II) RADEON(0): 640x480@75Hz
(II) RADEON(0): 800x600@56Hz
(II) RADEON(0): 800x600@60Hz
(II) RADEON(0): 800x600@72Hz
(II) RADEON(0): 800x600@75Hz
(II) RADEON(0): 832x624@75Hz
(II) RADEON(0): 1024x768@87Hz (interlaced)
(II) RADEON(0): 1024x768@60Hz
(II) RADEON(0): 1024x768@70Hz
(II) RADEON(0): 1024x768@75Hz
(II) RADEON(0): 1152x870@75Hz
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported Future Video Modes:
(II) RADEON(0): #0: hsize: 640  vsize 480  refresh: 85  vid: 22833
(II) RADEON(0): #1: hsize: 800  vsize 600  refresh: 85  vid: 22853
(II) RADEON(0): #2: hsize: 1024  vsize 768  refresh: 85  vid: 22881
(II) RADEON(0): #3: hsize: 640  vsize 480  refresh: 70  vid: 18993
(II) RADEON(0): #4: hsize: 1280  vsize 960  refresh: 60  vid: 16513
(II) RADEON(0): #5: hsize: 1024  vsize 768  refresh: 60  vid: 16481
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 108.0 MHz   Image Size:  300 x 225 mm
(II) RADEON(0): h_active: 1152  h_sync: 1216  h_sync_end 1344 h_blank_end 1600 h_border: 0
(II) RADEON(0): v_active: 864  v_sync: 865  v_sync_end 868 v_blanking: 900 v_border: 0
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 108.0 MHz   Image Size:  300 x 225 mm
(II) RADEON(0): h_active: 1280  h_sync: 1328  h_sync_end 1440 h_blank_end 1688 h_border: 0
(II) RADEON(0): v_active: 1024  v_sync: 1025  v_sync_end 1028 v_blanking: 1066 v_border: 0
(II) RADEON(0): Ranges: V min: 50 V max: 160 Hz, H min: 30 H max: 70 kHz,
(II) RADEON(0): Monitor name: CM621F
(II) RADEON(0): EDID (in hex):
(II) RADEON(0): 	00ffffffffffff002283409c00000000
(II) RADEON(0): 	0a0d01016821197ae88aaea154469924
(II) RADEON(0): 	0e474ffffe80315945596159314a8140
(II) RADEON(0): 	614001010101302a80c0416024304080
(II) RADEON(0): 	13002ce11000001e302a009851002a40
(II) RADEON(0): 	307013002ce11000001e000000fd0032
(II) RADEON(0): 	a01e46ff000a202020202020000000fc
(II) RADEON(0): 	00434d363231460a20202020202000eb
in RADEONProbeOutputModes
(II) RADEON(0): EDID vendor "HTC", prod id 40000
(II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DVI-0:ddc2" removed.
(II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DVI-0:ddc2" removed.
(II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DVI-0:ddc2" removed.
(II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
(II) RADEON(0): Output: S-video, Detected Monitor Type: 0

A bug report that mentions something similar is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263205, the difference is that I don't use cpufreq. I've also tried running without any gtk programs to no avail.

Output of hwinfo --gfx:

17: PCI 100.1: 0380 Display controller                          
  [Created at pci.310]                                          
  UDI: /org/freedesktop/Hal/devices/pci_1002_5941               
  Unique ID: NXNs.+J1lf5HupK7                                   
  Parent ID: vSkL.Zfhw7fZE2z3                                   
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.1       
  SysFS BusID: 0000:01:00.1                                     
  Hardware Class: graphics card                                 
  Model: "ATI RV280 [Radeon 9200] (Secondary)"                  
  Vendor: pci 0x1002 "ATI Technologies Inc"                     
  Device: pci 0x5941 "RV280 [Radeon 9200] (Secondary)"          
  SubVendor: pci 0x148c "C.P. Technology Co. Ltd"               
  SubDevice: pci 0x2063                                         
  Revision: 0x01                                                
  Memory Range: 0xe0000000-0xe7ffffff (rw,prefetchable,disabled)
  Memory Range: 0xde800000-0xde80ffff (rw,non-prefetchable,disabled)
  Module Alias: "pci:v00001002d00005941sv0000148Csd00002063bc03sc80i00"
  Config Status: cfg=yes, avail=yes, need=yes, active=unknown
  Attached to: #28 (PCI bridge)

18: PCI(AGP) 100.0: 0300 VGA compatible controller (VGA)
  [Created at pci.310]
  UDI: /org/freedesktop/Hal/devices/pci_1002_5961
  Unique ID: VCu0._wDPWAFX2L9
  Parent ID: vSkL.Zfhw7fZE2z3
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "ATI RV280 5961"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x5961 "RV280 5961"
  SubVendor: pci 0x148c "C.P. Technology Co. Ltd"
  SubDevice: pci 0x2062
  Revision: 0x01
  Memory Range: 0xf0000000-0xf7ffffff (rw,prefetchable)
  I/O Ports: 0xd800-0xd8ff (rw)
  Memory Range: 0xdf000000-0xdf00ffff (rw,non-prefetchable)
  Memory Range: 0xeffe0000-0xefffffff (ro,prefetchable,disabled)
  IRQ: 16 (606573 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00001002d00005961sv0000148Csd00002062bc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: radeon
  Driver Info #1:
    XFree86 v4 Server Module: radeon
    3D Support: yes
    Extensions: dri
  Config Status: cfg=yes, avail=yes, need=yes, active=unknown
  Attached to: #28 (PCI bridge)

Primary display adapter: #18
Comment 1 Peter B 2008-09-19 09:39:53 UTC
Created attachment 240501 [details]
xorg configuration file
Comment 2 Stefan Dirsch 2008-09-19 10:04:23 UTC
Which desktop are you using? Sounds like a RANDR tool which polls every 10 seconds. Verify by starting a failsafe *Xsession*.
Comment 3 Peter B 2008-09-19 10:32:52 UTC
I'm using KDE4.1.1. You're right, in a failsafe Xsession the DDC scan appears only twice in Xorg.0.log.
Comment 4 Egbert Eich 2008-09-19 11:00:22 UTC
So this is most likely a desktop session problem. Some desktop process is querying the RandR extension every 10 seconds to find out if the connected displays have changed. As a result the Xserver will read out DDC which produces those messages in the log file.
Comment 5 Lubos Lunak 2008-09-19 14:11:26 UTC
That is correct:
===
void RandrMonitorModule::poll()
    {
    // HACK: It seems that RRNotify/RRNotify_OutputChange event (i.e. detecting a newly
    // plugged or unplugged monitor) does not work without polling some randr functionality.
    int dummy;
    XRRGetScreenSizeRange( QX11Info::display(), window, &dummy, &dummy, &dummy, &dummy );
    }
===
I didn't expect polling of a RANDR function would have any other effect than making it tell the client about the change, when it fails to do so on its own. If you tell me how to get RRNotify_OutputChange about a monitor change without polling, I'll gladly remove the hack.
Comment 6 Lubos Lunak 2008-09-19 14:12:50 UTC
Created attachment 240580 [details]
testcase

A small testcase, in case that helps.
Comment 7 Stefan Dirsch 2008-09-19 15:14:30 UTC
> If you tell me how to get RRNotify_OutputChange about a monitor change
> without polling, I'll gladly remove the hack.

AFAIK this won't be possible before RANDR 1.3 (which we won't have in time for openSUSE 11.1/SLE11), but Matthias knows more details here.
Comment 8 Matthias Hopf 2008-09-19 18:59:28 UTC
It's most likely that even RandR 1.3 won't have this feature. Also, most hardware isn't capable of creating interrupts on hotplug change. RandR 1.3 might have a less intrusive scanning operator, though.

(In reply to comment #5 from Lubos Lunak)
> I didn't expect polling of a RANDR function would have any other effect than
> making it tell the client about the change, when it fails to do so on its own.
> If you tell me how to get RRNotify_OutputChange about a monitor change without
> polling, I'll gladly remove the hack.

This is impossible ATM. Sorry.

Comment 9 Stefan Dirsch 2008-09-19 20:19:09 UTC
Sorry, I didn't read carefully and mixed this up with the less intrusive scanning operator of RANDR 1.3. I suggest to remove this hack.
Comment 10 Stefan Dirsch 2008-09-19 20:38:36 UTC
> --- KDE4 desktop (likely some RANDR tool) triggers DDC scan every 10 seconds 
> +++ RANDR doesn't inform about newly plugged monitors

Sorry, but this is nothing you can expect to be implemented by us for SLE11. There are even upstream no plans to implement this. It's a also a hardware limitation, as Matthias outlined before. Please remove this hack. I don't think it's acceptable, that every 10 seconds you can't use your mouse and keyboard for 1-3 seconds.
Comment 11 Peter B 2008-09-20 07:21:51 UTC
It appears that things are a little more complicated than that. I tested xorg-x11-7.3-96.2 and xorg-x11-driver-video-7.3-138.5 (default opensuse 11) and every 10 seconds the line 

(**) RADEON(0): RADEONSaveScreen(2)

is appended to Xorg.0.log, without any ill-effects that I'm aware of. It is possible to watch a video without any freezes, something that is impossible with the current Xorg.
Comment 12 Stefan Dirsch 2008-09-20 08:17:03 UTC
11.0 has still the old non-RANDR 1.2 capable radeon driver. This old radeon driver won't be available on 11.1. Conclusion: All RANDR 1.2 capable drivers are affected by this issue. Among these are radeon, radeonhd, intel, nv(G80) and soon fglrx, nvidia.
Comment 13 Stefan Dirsch 2008-09-23 08:08:46 UTC
Major/P2 according to my comment #10. Removing the hack should be easy.
Comment 14 Peter B 2008-09-23 17:56:50 UTC
I disabled the startup service "Detecting RANDR (monitor) changes" in the service manager and DDC scans stopped, so I'd say that a patch isn't necessary, adjusting the default setting seems to be enough.
Comment 15 Lubos Lunak 2008-09-25 15:06:08 UTC
> Conclusion: All RANDR 1.2 capable drivers are affected by this issue.

This conclusion is wrong, how do you think the feature was developed? I was even thinking about having just 1 second as the polling time, and I built the feature around the assumption that detecting hardware changes works, which sucks :(.

Disabled polling.
Comment 17 Lubos Lunak 2008-10-23 11:54:45 UTC
*** Bug 437739 has been marked as a duplicate of this bug. ***
Comment 18 Lubos Lunak 2008-10-23 13:38:37 UTC
*** Bug 431200 has been marked as a duplicate of this bug. ***
Comment 19 Lubos Lunak 2008-10-27 08:31:50 UTC
*** Bug 438984 has been marked as a duplicate of this bug. ***
Comment 20 Lubos Lunak 2008-11-03 21:21:01 UTC
*** Bug 439615 has been marked as a duplicate of this bug. ***
Comment 21 Stefan Dirsch 2008-11-03 21:50:56 UTC
Since the bug still exists with Beta4 (about 5 weeks after it has been closed as fixed) it makes perfectly sense to reopen this one and not closing it again
as fixed before it has been fixed for real.
Comment 22 Lubos Lunak 2008-11-03 21:56:52 UTC
*** Bug 441152 has been marked as a duplicate of this bug. ***
Comment 23 Lubos Lunak 2008-11-03 22:27:56 UTC
Sorry, no idea how I could have repeatedly got distracted in the middle and ended up thinking it'd been done already. Now it's in KDE:KDE4:Factory:Desktop and waiting in /work/src/done/STABLE, honest :).
Comment 24 Stefan Dirsch 2008-11-03 22:34:18 UTC
Which package is this? Which changelog? Please, I want to know this!
Comment 25 Lubos Lunak 2008-11-04 08:22:09 UTC
kdebase4-workspace
-------------------------------------------------------------------
Mon Nov  3 22:27:07 CET 2008 - llunak@suse.cz

- update from randr branch (bnc#427645)
- update from kwin branch (sync with 4.1 branch)

Comment 26 Lubos Lunak 2008-11-04 09:23:22 UTC
*** Bug 440965 has been marked as a duplicate of this bug. ***
Comment 27 Lubos Lunak 2008-11-04 09:24:32 UTC
*** Bug 435941 has been marked as a duplicate of this bug. ***
Comment 28 Lubos Lunak 2008-11-04 16:19:43 UTC
*** Bug 441531 has been marked as a duplicate of this bug. ***
Comment 29 Matthias Hopf 2008-11-06 14:31:45 UTC
*** Bug 436143 has been marked as a duplicate of this bug. ***
Comment 30 Karsten Keil 2008-11-06 15:11:27 UTC
Is here any way to disable this in the system, so that I can use Beta4 KDE for testing or is installing a new package the only way ?
Comment 31 Felix Möller 2008-11-06 15:16:38 UTC
@Karsten

$ qdbus org.kde.kded /kded unloadModule randrmonitor

solved it for me.
Comment 32 Frans Leerink 2008-11-09 00:25:53 UTC
Hello

I have copied "Comment #37 of bug 436143 to bug 427645 since I was told that my bug was a duplicate of that one.

I now want to add my last finding after a reinstall of openSUSE 11.1 beta4, but now installed from the DVD instead of the LiveCD.

The problem does not show up now !!  !!  !!

Regards,   Frans


 ------- Comment #37 From Frans Leerink 2008-11-04 09:25:23 MST  [reply] -------  
Hello,

I have also a very irritating flickering problem on my display. The screen
flickers every 9-10 seconds and in my opinion it goes over the complete screen.
But if I cover up the whole screen, except 1 square cm at one of the corners, I
still see 2 flickerings, 9-10 seconds in between and that repeated every 50
seconds. The flickering looks like a darker line flashing downwards over a
third of the screen height.
I have a GEFORCE 8400 GS NVIDIA card

Regards,
            Frans

 ------- Comment #38 From Stefan Dirsch 2008-11-04 09:34:23 MST  [reply] -------  
Frank, Nkoli, your issues might very well be another duplicate of Bug #427645.


Comment 33 Robby Verberne 2008-11-10 21:28:05 UTC
OS:  Linux 2.6.27.5-1-default x86_64
  Huidige gebruiker:  oddball@AMD64x2-sfn1
  Systeem:  openSUSE 11.1 Beta 4.6 (x86_64)
  KDE:  4.1.3 (KDE 4.1.3) "release 1.3"

i am glad to say that i don't have to:$ qdbus org.kde.kded /kded unloadModule randrmonitor , every time i boot up :))
Seems to be fixed..

Comment 34 Lubos Lunak 2008-11-11 11:34:08 UTC
*** Bug 443502 has been marked as a duplicate of this bug. ***
Comment 35 Lubos Lunak 2008-11-11 17:29:36 UTC
*** Bug 441031 has been marked as a duplicate of this bug. ***