Bug 357116

Sounds like a buffer age problem. KWin still running on the intel chip?

Does it go away with
KWIN_USE_BUFFER_AGE=0 kwin_x11 --replace &

If not , does it happen on the xrender backend as well?

Did you maybe export KWIN_EXPLICIT_SYNC=0 ?

You do not get this when suspending/resuming the compositor by hand?

Do you have fullscreen unredirection enabled?

(In reply to Thomas Lübking from comment #1)
> Sounds like a buffer age problem. KWin still running on the intel chip?

Yes, it is. Apparently, I have 3 different issues:
1) A black square in the top left corner when compositing is disabled, which is put on top of every window, this is actually the "button" which is on plasma desktop to access the desktop settings menu etc, for some reason it's totally black with compositing disabled. Happens even with ALT-SHIFT-F12. So actually that black square appears on top of the game as well. This disappear when reenabling the compositor.

2) Flickering when moving windows after compositing has been reenabled

3) Windows decorations having weird "buggy" black borders around them

> Does it go away with
> KWIN_USE_BUFFER_AGE=0 kwin_x11 --replace &

That seem to fix 2), but doesn't fix 3)

> 
> Did you maybe export KWIN_EXPLICIT_SYNC=0 ?

No, I'm not exporting anything specific to kwin.

> You do not get this when suspending/resuming the compositor by hand?

No, only when suspended with the rules.

> Do you have fullscreen unredirection enabled?
No, it's impossible to enable it with an intel card.

To be more precise, I get 2) and 3) only when the compositor suspended by the rules and reenabled.

(In reply to AnAkkk from comment #2)

> 1) A black square in the top left corner when compositing is disabled

ie. an override_redirect (unmanaged) ARGB window. It's always above the other windows, but you can only see it when not compositing.
Smells like a plasmashell bug to me? (Sounds as if it *should* be an input_only window and even that seems questionable)
Can you "xprop" & "xwininfo" it?

> 3) Windows decorations having weird "buggy" black borders around them
Can you make a Screenshot?

> > KWIN_USE_BUFFER_AGE=0 kwin_x11 --replace &
> 2) Flickering when moving windows after compositing has been reenabled
> That seem to fix 2), but doesn't fix 3)
> No, only when suspended with the rules.

Does it also happen if you eg. create a rule for
a) xterm
b) (windowed!) glxinfo

Created attachment 96290 [details]
Screenshot of firefox window after reenabling compositing

(In reply to Thomas Lübking from comment #4)
> Can you "xprop" & "xwininfo" it?

Output of xprop:
_NET_WM_WINDOW_OPACITY(CARDINAL) = 0

Output of xwininfo:
xwininfo: Window id: 0x2400006 (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 32
  Height: 32
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: yes
  Corners:  +0+0  -1888+0  -1888-1048  +0-1048
  -geometry 32x32+0+0

> > 3) Windows decorations having weird "buggy" black borders around them
> Can you make a Screenshot?

Attached a screenshot of the firefox window border.

> Does it also happen if you eg. create a rule for
> a) xterm
> b) (windowed!) glxinfo

a) No, doesn't seem to happen with xterm, maybe because it's not a fullscreen app
b) windowed ? what do you mean?

(In reply to AnAkkk from comment #6)
> (In reply to Thomas Lübking from comment #4)
> > Can you "xprop" & "xwininfo" it?
> 
> Output of xprop:
> _NET_WM_WINDOW_OPACITY(CARDINAL) = 0

Idiocracy. Seriously. Whatever it is, it's idiocracy.
run "xkill" and click the window - the process it belongs to should die afterwards
(maybe take a "ps fax" diff on before and after)

Unfortunately there's no further hint what it belongs to :-(

> Attached a screenshot of the firefox window border.
Looks like the shadow texture is invalid (for whatever reason)

> a) No, doesn't seem to happen with xterm, maybe because it's not a
> fullscreen app

I rather assume "because it's not a GL context".
You can however turn any window fullscreen (except for xterm by default, because it demands certain aspect ratios, can be ignored by a rule as well)

> b) windowed ? what do you mean?
... "glxgears", sorry :-)

(In reply to Thomas Lübking from comment #7)
> Idiocracy. Seriously. Whatever it is, it's idiocracy.
> run "xkill" and click the window - the process it belongs to should die
> afterwards
> (maybe take a "ps fax" diff on before and after)

xkill has no effect on it, it's still here.

> ... "glxgears", sorry :-)

Just tried, I don't have issues 2) and 3) with glxgears.

(In reply to AnAkkk from comment #8)

> xkill has no effect on it, it's still here.

Err, what?
It would then probably belong to a crashed (and stopped) process?
ps ax | grep T

> > ... "glxgears", sorry :-)
> Just tried, I don't have issues 2) and 3) with glxgears.

What about fullscreen glxgears (you can turn it fullscreen using  the Alt+F3 menu and in doubt close it by Alt+F4 w/o unfullscreening it before)

(In reply to Thomas Lübking from comment #9)
> It would then probably belong to a crashed (and stopped) process?
> ps ax | grep T

No, nothing. xkill probably doesn't work because there is no PID attached to the window (doesn't it rely on the PID that is showed by xprop?)
.Anyway, why would it belong to a crashed process, since we know it belongs to plasmashell?

> What about fullscreen glxgears (you can turn it fullscreen using  the Alt+F3
> menu and in doubt close it by Alt+F4 w/o unfullscreening it before)

Tried, that doesn't trigger the issue either.

xkill cuts the line between client and server. This sould remove all resources (windows) and typically the client would exit (crash in doubt) in return.

Do you have positive knowledge on the relation, ie. does killing plasmashell remove the window?

> Tried, that doesn't trigger the issue either.
Errr... stupid question: did you optirun glxgears?

(In reply to Thomas Lübking from comment #11)
> Do you have positive knowledge on the relation, ie. does killing plasmashell
> remove the window?

No, you're right, it doesn't actually remove the window. But I thought this was plasmashell, since it's at the place of the desktop "movable menu".

> Errr... stupid question: did you optirun glxgears?

No, but now I did, no difference :/

Found another issue, which happens as well after compositing has been disabled through a rule:
Writing anything in kate/konsole is very slow, it can take several seconds for the text to appear. Restarting kwin also fixes the issue.

(In reply to AnAkkk from comment #13)
> Found another issue, which happens as well after compositing has been
> disabled through a rule:
> Writing anything in kate/konsole is very slow, it can take several seconds
> for the text to appear.

You mean *while* the compositor is suspended??
By what window? Kate or something else and does any involved client "optirun"?

Fyi, there's no difference in suspending the compositor by the shortcut or a window rule. It's always the same routine being invoked. A behavioral difference here would suggest the rules trigger it at a "clumsy" moment, but we already shuffled it off the eventloop. So we'd be in a situation where "suspending the compositor in 'close' time to mapping a window causes weird issues" (w/ optimus setups)

(In reply to Thomas Lübking from comment #14)
> You mean *while* the compositor is suspended??
No, after it has been reenabled by closing the game, just like the other issues.
I just tried again, and for some reason I can't reproduce the issue now, although it happened twice before. I'm not sure if it's linked to the rule after all, although both time I noticed it after stopping the game.

> By what window? Kate or something else and does any involved client
> "optirun"?
Kate search text field (I think the main text area was not affected), kate "terminal" part of the window, konsole main text input. No, I don't use optirun/primusrun for anything else than the game.

> Fyi, there's no difference in suspending the compositor by the shortcut or a
> window rule. It's always the same routine being invoked. A behavioral
> difference here would suggest the rules trigger it at a "clumsy" moment, but
> we already shuffled it off the eventloop. So we'd be in a situation where
> "suspending the compositor in 'close' time to mapping a window causes weird
> issues" (w/ optimus setups)

Is there any way to debug it, at least the invalid shadow texture issue, and the black box at the place of the desktop button?

(In reply to AnAkkk from comment #13)
> Writing anything in kate/konsole is very slow, it can take several seconds
> for the text to appear. Restarting kwin also fixes the issue.

This issue doesn't seem to be related to compositing, as I've now completely disabled it, and that seem to happen quite often. I have no idea how to debug it though.
I'm having the issue right now, and writing in Yakuake is fast without any issues, but in Konsole/Kate it's very laggy and characters appear after several seconds.
CPU usage looks fine, my computer doesn't feel slow at all, it's really just when writing text in these two app.

Ok, that issue is actually related to having compositing disabled. It happens 100% of the time when I disable compositing. 
It must also happen when compositing is disabled with the rule.

I'm fairly sure that what you see is a sync issue between the two graphics chips.
Can you disable one of them in bios/uefi and check the results (also reg. the original problems)?

(In reply to Thomas Lübking from comment #18)
> I'm fairly sure that what you see is a sync issue between the two graphics
> chips.
> Can you disable one of them in bios/uefi and check the results (also reg.
> the original problems)?

No, there is no option in bios/uefi to do that.

This sounds a lot like another case of bug #361154. If you are still able to reproduce with 5.7.4 please reopen.

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