Red Hat Bugzilla – Bug 541670
Extremely slow GUI after disabling second video output when desktop effects are enabled.
Last modified: 2013-07-03 00:06:01 EDT
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) 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.
Steps to Reproduce:
How I'm trying to do it:
* I'm using gnome-display-properties to enable and disable the secondary video
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.
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.
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
Created attachment 374540 [details]
Created attachment 374543 [details]
X server log file
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.
Does disabling sync_to_vblank fix it?
gconftool -s /apps/compiz/general/screen0/options/sync_to_vblank -t bool "false" should disable it.
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
Would this be what is needed for an out-of-the-box fix?
(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
> 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
> Would this be what is needed for an out-of-the-box fix?
> Kind regards,
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.
Proposed fix here with patch identified:
Please let me know if it fixes things for you.
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 220.127.116.11-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.
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:
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.