Bug 90910 - Switching workspaces in AwesomeWM - workspace changes but Awesome lags behind
Summary: Switching workspaces in AwesomeWM - workspace changes but Awesome lags behind
Status: RESOLVED DUPLICATE of bug 99220
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
Depends on:
Reported: 2015-06-09 03:41 UTC by alexis
Modified: 2017-01-18 08:55 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

xorg log (34.90 KB, text/plain)
2015-06-09 03:41 UTC, alexis
no flags Details

Description alexis 2015-06-09 03:41:32 UTC
Created attachment 116383 [details]
xorg log

When I switch from one workspace to another the screen changes (the workspace changes instantly) but AwesomeWM's task bar does not change immediately, there are a few seconds of lag before it will register that the workspace has changed. 

To reproduce, in Awesome press meta (windows key usually) + 2 to change from the first to second workspace. Watch the numbers on the top left hand side and you should see a noticeable delay for the numbers to change and to show you which workspace you are on. 

I have attached my xorg log in case it reveals anything, I can't see anything in particular there. 

I am using funtoo with the x11-drivers/xf86-video-ati-9999 ebuild from the x11 overlay. This behaviour does not exist with the 7.5.0 driver. 

/etc/X11/xorg.conf.d % cat radeon.conf
Section "Device"
   Identifier  "radeon"
   Driver      "radeon"
   Option      "TearFree" "true"
   Option      "ShadowPrimary" "true"
   Option      "AccelMethod" "glamor"
Comment 1 alexis 2015-06-09 03:46:48 UTC
I should add that without the TearFree option the lag isn't not present so it would see that may be the issue. 

The problem seems to be progressively worse with more programs open, a new empty session has very little lag but open something on each workspace and it quickly becomes noticeable.
Comment 2 Paul Menzel 2016-09-14 08:57:42 UTC
Do you also experience the problem, when maximizing a Firefox window on a screen with several Firefox windows, and when demaximizing it, the background is not updated?
Comment 3 Michel Dänzer 2016-09-16 01:42:58 UTC
Per bug 97796, passing --no-argb on the awesome command line works around this.
Comment 4 alexis 2016-09-16 03:50:25 UTC
Unfortunately I am not running awesome and don't easily have a way to test with the newer driver any more. Feel free to close because I would not be able to test any fixes/changes.
Comment 5 Michel Dänzer 2016-09-16 06:07:51 UTC
That's okay, I can reproduce the problem and can resolve this report when I notice that it's fixed.
Comment 6 Michel Dänzer 2017-01-18 08:55:51 UTC

*** This bug has been marked as a duplicate of bug 99220 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.