Bug 541670 - Extremely slow GUI after disabling second video output when desktop effects are enabled.
Extremely slow GUI after disabling second video output when desktop effects a...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
card_GM45
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-26 12:13 EST by J.H.M. Dassen (Ray)
Modified: 2013-07-03 00:06 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-04 04:15:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dmesg output (50.49 KB, text/plain)
2009-11-29 05:32 EST, J.H.M. Dassen (Ray)
no flags Details
X server log file (84.75 KB, text/plain)
2009-11-29 05:34 EST, J.H.M. Dassen (Ray)
no flags Details

  None (edit)
Description J.H.M. Dassen (Ray) 2009-11-26 12:13:09 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091105 Fedora/3.5.5-1.fc12 Firefox/3.5.5

What I'm trying to do:

* Lenovo Thinkpad X200, 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (PCI ID 8086:2a42)
* Fedora 12, fully updated.
* Use Compiz desktop effects (configured through "desktop-effects").
* Use a secondary video output (to deliver presentations).
* Disable the secondary video output (after the presentation is done).
* Continue to work on the system.


Reproducible: Always

Steps to Reproduce:
How I'm trying to do it:

* I'm using gnome-display-properties to enable and disable the secondary video
  output.

Actual Results:  
What behaviour I got:

* After I disable the secondary video output, the primary video output still
  functions, but the GUI is extremely slow. "ps" shows that there is still a
  compiz process running. Only after switching desktop effects down to
  "Standard" does the system regain its regular responsiveness.

Expected Results:  

What behaviour I expected:

* I expected the GUI to continue to be responsive throughout. 


Please let me know what additional troubleshooting data would be helpful.
Comment 1 Chris Campbell 2009-11-27 17:37:17 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 J.H.M. Dassen (Ray) 2009-11-29 05:32:50 EST
Created attachment 374540 [details]
dmesg output
Comment 3 J.H.M. Dassen (Ray) 2009-11-29 05:34:29 EST
Created attachment 374543 [details]
X server log file
Comment 4 J.H.M. Dassen (Ray) 2009-11-29 05:37:37 EST
Here are the log files requested. There is no /etc/X11/xorg.conf on the system.

Please let me know, should any additional data or testing be required.

Kind regards,
Ray
Comment 5 Adel Gadllah 2009-11-29 10:04:01 EST
Does disabling sync_to_vblank fix it?

gconftool -s /apps/compiz/general/screen0/options/sync_to_vblank  -t bool "false"  should disable it.
Comment 6 J.H.M. Dassen (Ray) 2009-11-29 13:11:25 EST
Thank you very much, Adel.

After disabling sync_to_vblank through
	gconftool-2 -s /apps/compiz/general/screen0/options/sync_to_vblank -t bool "false"
I can no longer reproduce the issue, i.e. after disabling the secondary video
output the desktop effects remain at their original fast speed.

I'm not quite sure what sync_to_vblank does, but I did stumble upon
	http://patchwork.kernel.org/patch/58658/
Would this be what is needed for an out-of-the-box fix?

Kind regards,
Ray
Comment 7 Adel Gadllah 2009-11-30 10:36:01 EST
(In reply to comment #6)
> Thank you very much, Adel.
> 
> After disabling sync_to_vblank through
>  gconftool-2 -s /apps/compiz/general/screen0/options/sync_to_vblank -t bool
> "false"
> I can no longer reproduce the issue, i.e. after disabling the secondary video
> output the desktop effects remain at their original fast speed.
> 
> I'm not quite sure what sync_to_vblank does, but I did stumble upon
>  http://patchwork.kernel.org/patch/58658/
> Would this be what is needed for an out-of-the-box fix?
> 
> Kind regards,
> Ray  

Thanks for testing. Sync to vblank is used to prevent tearing, it waits for you screens vblank interval before updating it so there is no visible tearing.

The patch you linked to seems to address this issue.

So in order to fix this we have to backport this fix to our kernel package.
Comment 8 Kyle McMartin 2009-11-30 14:16:11 EST
Proposed fix here with patch identified:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1838894

Please let me know if it fixes things for you.
Comment 9 J.H.M. Dassen (Ray) 2009-11-30 16:48:08 EST
Thank you, Kyle.

After switching back to the default for sync_to_vblank:
	gconftool-2 -s /apps/compiz/general/screen0/options/sync_to_vblank -t bool "true"
and booting into the 2.6.31.6-155.fc12.x86_64 kernel, I cannot reproduce the original issue: after disabling the secondary video output the desktop effects remain at their original fast speed. So, yes, the proposed fix works for me.

Kind regards,
Ray
Comment 10 Bug Zapper 2010-11-04 01:15:09 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 J.H.M. Dassen (Ray) 2010-11-04 04:15:08 EDT
As per comment #9, the proposed patch from comment #8 did fix things for me.

If I'm not mistaken, this patch was included in a later Fedora 12 kernel update, so I'm marking this as resolved.

Note You need to log in before you can comment on or make changes to this bug.