search

chjj / compton

A compositor for X11.
Other
2.25k stars 500 forks source link

RGBA windows are always transparent #179

Open thefeel opened 10 years ago

thefeel commented 10 years ago

Hi, I'm using Awesome 3.5 on Fedora rawhide. For some reason using compton makes the windows transparent. This only happens when using the mesa drivers (10.1 rc2 and kernel 3.14), with fglrx compton works fine.

As can be seen in the pic glxgears and the steam window are transparent.

bug

richardgv commented 10 years ago

Thanks for the report. That's a weird problem and I don't quite understand what may cause this. Tried forcing compton to treat all windows as ARGB, but still it doesn't create the effect.

  1. Does this happen only on windows fully rendered with OpenGL?
  2. On which backend does it occur? X Render, GLX, or both? Does compton --backend YOUR-BACKEND --config /dev/null help?
  3. Does it appear with other WMs that draws window decoration?
thefeel commented 10 years ago

1- Only with windows rendered with OpenGL 2- All backends, xrender, glx and hybrid. 3- No, MATE, xfce4 and i3 work fine.

I tried messing around with the opacity settings in compton, but they didn't work. Is there a way to just disable all opacity in compton?

richardgv commented 10 years ago

It's not an issue related to opacity. These windows are not rendered with opacity, but with some sort of ARGB visual, which probably is associated with an issue in your driver. I need to think a bit about the possibilities. (It's close to midnight here, does not sound like a good time to consider a complicated issue.) Does xcompmgr or cairo-compmgr work in this case?

thefeel commented 10 years ago

xcompmgr shows the same issue, cairo-compmgr doesnt seem to be available in rawhide. Maybe this is an Awesome bug?

thefeel commented 10 years ago

Starting awesome with the --no-argb flag fixes the issue.

richardgv commented 10 years ago

Sorry for the late reply, thefeel.

  1. Indeed, the usage of ARGB visual in awesome-3.5 seemingly caused various driver-specific issues.
  2. As far as I could tell, you will loss ARGB window support (at least, the non-override-redirect / decorated ones) with --no-argb. Windows will no longer have true transparency, that is.
  3. I suppose typically a WM uses ARGB visual on frame windows only if the client window has an ARGB visual. (At least, this is the case for fvwm.) Since your issue only occurs with a window rendered with OpenGL and has ARGB visual, which is moderately rare, it shouldn't appear much with a normal WM -- but ultimately, it's a driver issue, and you can't see it doesn't mean it does not exist on other WMs.
ghost commented 10 years ago

I have the same issue here. Happens both with xcompmgr and compton so I guess the issue is awesome's fault. I'm using mesa drivers as well. issue I'm going to downgrade awesome and see what happens.

ghost commented 10 years ago

This issue appears on git version, but does not on awesome 3.4. Tried downgrading mesa packages but that didn't do anything, so most probably it is awesome's fault. awesome3 4

richardgv commented 10 years ago

@void-null:

Have you tried thefeel's suggestion on awesome-3.5?

Starting awesome with the --no-argb flag fixes the issue.

By the way, I would recommend you to read the comments above.

ghost commented 10 years ago

@richardgv

Have you tried thefeel's suggestion on awesome-3.5?

Of course I did. Using --no-argb is a mere workaround since it disables true transparency for applications that actually require it (like the terminal window in my previous screenshot).

By the way, I would recommend you to read the comments above.

I did that as well.

I doubt that the issue is driver's fault, since it does not appear with any other window manager besides awesome, older version of which works fine. I haven't been able to reproduce it on other WMs like i3, KWin (with both native and compton compositing) or Openbox.

richardgv commented 10 years ago

@void-null:

I doubt that the issue is driver's fault, since it does not appear with any other window manager besides awesome, older version of which works fine. I haven't been able to reproduce it on other WMs like i3, KWin (with both native and compton compositing) or Openbox.

Well, it doesn't explain why this only happens on specific drivers, and it doesn't happen on non-OpenGL windows. At least the problem is non-existent here with nvidia-drivers-337.12. I suppose other WMs don't trigger the bug because they don't wrap a 24-bit window inside a 32-bit frame. I do not know whether this is a sane design (although it could be useful in some cases). When in doubt, please contact Awesome developers.

And, Uli Schlachter (psychon) (the main developer of Awesome?) suggested more than once where the problem with ARGB visual is: http://git.naquadah.org/?p=awesome.git;a=commit;h=37bb1e088f9d5bbd9f344825b916dd0108e92012 https://awesome.naquadah.org/bugs/index.php?do=details&task_id=837

thefeel commented 10 years ago

Xorg 1.16 fixes all issues. I guess this can be closed.

richardgv commented 10 years ago

@thefeel:

Thanks for the feedback! :-)

@void-null:

Does upgrading Xorg work for you?