rendering problems after xorg upgrade about awesome HOT 18 CLOSED

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

from awesome.

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?

from awesome.

@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

from awesome.

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

from awesome.

@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 ?

from awesome.

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

from awesome.

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.

from awesome.

@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.

from awesome.

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

from awesome.

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

from awesome.

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:
#195
Where the graphics card seems to be the issue as well.

from awesome.

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

from awesome.

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

from awesome.

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?

from awesome.

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.

from awesome.

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.

from awesome.

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

from awesome.

...recently been fixed in Xorg

from awesome.