Awesome: rendering problems after xorg upgrade

Created on 26 Mar 2015 · 18Comments · Source: awesomeWM/awesome

 $ awesome --version                                                                                                                                                                              
  awesome v3.5.6 (For Those About To Rock)
 • Build: Jan 14 2015 20:56:29 for x86_64 by gcc version 4.8.2 (buildd@lgw01-04)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔

After an upgarde on my ubuntu host I have rendering problems with several (but not all) applications.
Attached below is an image of chromium after i switched away and back to a workspace running chromium. The window is not rendered fully.

capture

For other apps this never happens. For example gnome-terminal or gedit. There are no problems at all
with the applications running on other window managers. Some of the upgraded packages (which might be relevant):


  2015-03-26 08:51:21 upgrade libdrm-intel1:i386 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:22 upgrade libdrm-intel1:amd64 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:22 upgrade libdrm-nouveau2:i386 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade libdrm-nouveau2:amd64 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade libdrm-radeon1:i386 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade libdrm-radeon1:amd64 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade x11-common:all 1:7.7+1ubuntu8 1:7.7+1ubuntu8.1
  2015-03-26 08:51:24 upgrade xserver-common:all 2:1.15.1-0ubuntu2.6 2:1.15.1-0ubuntu2.7
  2015-03-26 08:51:25 upgrade libgles2-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:26 upgrade xserver-xorg-core:amd64 2:1.15.1-0ubuntu2.6 2:1.15.1-0ubuntu2.7
  2015-03-26 08:51:26 upgrade libgl1-mesa-dri:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:27 upgrade libgl1-mesa-dri:i386 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:28 upgrade libgl1-mesa-glx:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:29 upgrade libgl1-mesa-glx:i386 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:29 upgrade libglapi-mesa:i386 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:30 upgrade libglapi-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:30 upgrade libwayland-egl1-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:30 upgrade libegl1-mesa-drivers:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:31 upgrade libxfont1:amd64 1:1.4.7-1ubuntu0.1 1:1.4.7-1ubuntu0.2
  2015-03-26 08:51:32 upgrade libgbm1:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:32 upgrade libopenvg1-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:33 upgrade libegl1-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:33 upgrade libgudev-1.0-0:amd64 1:204-5ubuntu20.9 1:204-5ubuntu20.10
  2015-03-26 08:51:34 upgrade libicu52:amd64 52.1-3 52.1-3ubuntu0.2

chromium itself and spotify were both also updated. But as I said they are rendered just fine in other window managers. Please let me know if there is any other useful info I could provide. I have
absolutely no idea how to solve this issue right now.

bug no-argb upstream

Source

gilligan

Most helpful comment

i think psychon meant /usr/local/bin/awesome-no-argb

and instead of /usr/bin/awesome you should put your real path to awesome, ie $ which awesome

actionless on 6 Oct 2016

🎉1 😄1

All 18 comments

is that happens only with chromium-based apps?
do you use any compositor? if not can you try to run awesome with --no-argb argument?

actionless on 26 Mar 2015

@actionless indeed i think i might have to correct myself. it seems like it only happens with chromium. As for compositor, I use compton. Killing it has no effect. I will try the --no-argb switch and report back

gilligan on 26 Mar 2015

@actionless awesome is now running with --no-argb but the problem remains. I also tried latest google-crhome. Same problem as with chromium

gilligan on 26 Mar 2015

@actionless correcting myself again. Running awesome with --no-argb and without compton fixes the problem. My question is: who is to blame for what now and how should I proceed ?

gilligan on 26 Mar 2015

I also tried some random other composition manager (xcompmgr) with the same result

gilligan on 26 Mar 2015

Sorry, but awesome is not to blame. Awesome just places windows (it tells the X11 server where the window should be visible). It's not involved at all in the actual drawing. Everything that is fixed by --no-argb is a bug elsewhere, likely in your X11 video driver (or in this case in xcompmgr). Sorry, but I don't know more.

psychon on 26 Mar 2015

@psychon valid points indeed. It is odd however that this only ever occurs in awesome and no other window manager. Regardless of which comp manager is used as well. Maybe i will file bug for chrome and see where that leads.

gilligan on 27 Mar 2015

I can confirm this on my laptop as well, with the Intel driver, and the issue only happens on Awesome.
Will report back with more details and tests when I am with the machine

ViktorNova on 4 Apr 2015

@ViktorNova Does --no-argb and/or no compton help you, too?

psychon on 4 Apr 2015

Same problem here. I am using ubuntu and an older version of awesome (3.5.14) and the redrawing does not occur in both chromium and firefox.
Workaround:
Running chromium with the --disable-gpu-compositing option solved the problem for me.

In that sense it is related to the report referenced above:
https://github.com/awesomeWM/awesome/issues/195
Where the graphics card seems to be the issue as well.

HHM on 15 Apr 2015

I confirm that using --disable-gpu-compositing is also solving the problem for google-chrome.

pakozm on 26 May 2015

Same here. With GPU compositing disabled in Chrome the rendering issues go away. For those of you with Intel drivers, the end of this bug on chromium might work:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1309801

0jrp0 on 26 May 2015

if not can you try to run awesome with --no-argb argument?

I have some trouble testing this approach. I use LXDM as a display manager which uses X Desktop Entry files for starting the awesome session. But these files don't allow arguments with two hyphens.
How could I e.g. start an awesome session "manually" from a tty?

slaufmann on 5 Oct 2016

You could create a file /usr/local/awesome-no-argb (make sure it is executable) with the following content (and then use this file in your .desktop file):

#!/bin/sh
exec /usr/bin/awesome --no-argb "$@"

If you really want to start a session from a tty, something like the following might work: X :5 & sleep 10 ; DISPLAY=:5 awesome.

psychon on 5 Oct 2016

Thanks, starting from the command line worked.

The workaround with the shell script as executable for the .desktop file didn't work. I kept propted with a message that "awesome-no-argb" couldn't be found even though it was in the right path. I even tried a complete path but that didn't work either.

slaufmann on 5 Oct 2016

i think psychon meant /usr/local/bin/awesome-no-argb

and instead of /usr/bin/awesome you should put your real path to awesome, ie $ which awesome

actionless on 6 Oct 2016

🎉1 😄1

Unless this is an urelated bug that produces the same result, this has been recently fixed