When the Euphoria (GL) Screensaver starts, KWIN crashes

[Jon "The Nice Guy" Spriggs]

When I come back to my PC, the screensaver has frozen, and when I then unlock the machine, it shows that KWin has crashed.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: kde-window-manager 4:4.6.2a-0ubuntu5.1
ProcVersionSignature: Ubuntu 2.6.38-11.48-generic-pae 2.6.38.8
Uname: Linux 2.6.38-11-generic-pae i686
Architecture: i386
Date: Thu Sep 15 06:48:19 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110427.1)
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: kdebase-workspace
UpgradeStatus: No upgrade log present (probably fresh install)

[Adler-187 (adler-187)]

Application: kwin (4.5.1 (KDE 4.5.1) "release 3")
KDE Platform Version: 4.5.1 (KDE 4.5.1) "release 3"
Qt Version: 4.6.3
Operating System: Linux 2.6.34.7-0.3-desktop x86_64
Distribution: "openSUSE 11.3 (x86_64)"

-- Information about the crash:
- What I was doing when the application crashed:

I'm not exactly sure how KWin crashed, but I was watching a flash video in Chromium. It ended and I alt-tabbed and things locked up. Suddenly a Chromium tab was in it's own window like I had dragged it off the tab bar, but I hadn't. Not sure if this really helps or not.

This is on an R400 Thinkpad laptop with intel i945 graphics. KWin works fairly good with effects but these intel drivers are really buggy it seems.

-- Backtrace:
Application: KWin (kwin), signal: Segmentation fault
[KCrash Handler]
#6 intel_region_buffer (intel=0x780530, region=0x0, flag=2) at intel_regions.c:498
#7 0x00007f123d601dc4 in intelClearWithBlit (ctx=0x780530, mask=2) at intel_blit.c:266
#8 0x00007f123d603dca in intelClear (ctx=0x780530, mask=<value optimized out>) at intel_clear.c:173
#9 0x00007f12540ddf85 in KWin::SceneOpenGL::paintBackground (this=<value optimized out>, region=<value optimized out>) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/scene_opengl.cpp:892
#10 0x00007f12541372b6 in KWin::Scene::paintGenericScreen (this=0x10a60a0, orig_mask=32) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/scene.cpp:187
#11 0x00007f12541090aa in KWin::Scene::finalPaintScreen (this=0x10a60a0, mask=32, region=<value optimized out>, data=<value optimized out>)
    at /usr/src/debug/kdebase-workspace-4.5.1/kwin/scene.cpp:177
#12 0x00007f125413a4dc in KWin::EffectsHandlerImpl::paintScreen (this=<value optimized out>, mask=32, region=<value optimized out>, data=...)
    at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:172
#13 0x00007f123ccf8e6f in KWin::LogoutEffect::paintScreen (this=0x10790b0, mask=32, region=..., data=<value optimized out>)
    at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects/logout/logout.cpp:207
#14 0x00007f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=<value optimized out>, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:168
#15 0x00007f123ccfd842 in KWin::PresentWindowsEffect::paintScreen (this=0x11311c0, mask=32, region=..., data=<value optimized out>)
    at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects/presentwindows/presentwindows.cpp:196
#16 0x00007f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=<value optimized out>, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:168
#17 0x00007f125279241f in KWin::Effect::paintScreen (this=<value optimized out>, mask=32, region=<value optimized out>, data=...)
    at /usr/src/debug/kdebase-workspace-4.5.1/kwin/lib/kwineffects.cpp:227
#18 0x00007f125413a56c in KWin::EffectsHandlerImpl::paintScreen (this=0x1341ca0, mask=32, region=<value optimized out>, data=...) at /usr/src/debug/kdebase-workspace-4.5.1/kwin/effects.cpp:168
#19 0x00007f125279241f in KWin::Effect::paintScreen (this=<value optimized out>, mask=32, region=<value optimized out>, data=...)
    at /usr/src/debug/kdebas...

[Thomas-luebking (thomas-luebking)]

*** Bug 252824 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

crashes in glClear( GL_COLOR_BUFFER_BIT ), most likely because there's no valid ontext, because the intel drivers and/or mesa (i frankly don't know/recall who's to blame here) have _serious_ problems handling multiple contexts/contexts on non-window drawables (in this, this is related to the mighty freeze bug #241402 ...)

Notice that "resolved upstream" does not mean that there's a fixed driver available atm. but just that the bug won't/cant be fixed in kwin.
in this particular case there might be a workaround available as discussed in #241402

[Mgraesslin (mgraesslin)]

As the crash trace is rather good I would like to ask you to report the bug
again on bugs.freedesktop.org for the intel driver. Thanks

[Adler-187 (adler-187)]

Opened upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=30509

[Thomas-luebking (thomas-luebking)]

*** Bug 256128 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 257115 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 264258 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 246892 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 246960 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 264493 has been marked as a duplicate of this bug. ***

[Alex3255 (alex3255)]

I spend two days for debug this issue. Mesa function glXSwapBuffers is buggy for i945 and i965. This function is used just once in kwin in scene_opengl.cpp, flushBuffer(...) {
....
 if( mask & PAINT_SCREEN_REGION ) { do region updating}
 else { // do fullscreen updating
  waitSync();
  glXSwapBuffers( display(), glxbuffer );
 }
}

I changed glXSwapBuffers( display(), glxbuffer ) with
glXCopySubBuffer( display(), glxbuffer, 0, 0, displayWidth(), displayHeight());
and the bug disappeared for me. Please test it.

[Mgraesslin (mgraesslin)]

> This function is used just once in kwin in
> scene_opengl.cpp
The number of occurrances does not say much. That code is executed in each
fullscreen rendered frame (e.g. present windows, login, logout, desktop grid,
cover switch...)
> I changed glXSwapBuffers( display(), glxbuffer ) with
> glXCopySubBuffer( display(), glxbuffer, 0, 0, displayWidth(),
> displayHeight()); and the bug disappeared for me. Please test it.
We will definatly not change the code to workaround it - sorry. If it is
broken in the drivers, it has to be fixed in the drivers.

[Alex3255 (alex3255)]

Hope they'll fix it quickly. I am waiting for working full-screen flash for 1.5 years.

Thanks

[Thomas-luebking (thomas-luebking)]

(In reply to comment #12)
> > This function is used just once in kwin in scene_opengl.cpp
is it really the source of /this/ particular backtrace that occurs in a complete different location than glXSwapBuffers?

In case this might be a /very/ valuable information for the driver developers and should definitely be fixed there, since a constant glClear/glXSwapBuffer cycle is probably one of the most occurring GL code statements.

[Alex3255 (alex3255)]

I don't have the same backtrace. I have a backtrace like Magnus Kessler's one at https://bugs.freedesktop.org/show_bug.cgi?id=30509, but all backtraces I have was very different. All crashes occurs when there was a full-screen application(like flash or wine game) and another window is appears.

For some reason internal structs of mesa become damaged(render buffer's pointer for a region become 0) after glXSwapBuffers. Some mesa functions(like prepare_wm_surfaces) were not expecting it and crash kwin.

Chris Wilson has added the non-null region pointer check for intelClearWithBlit function, so I not saw first backtrace. I made all functions to work with structs damaged this way, kwin stopped segfaulting, but, instead, it became very unstable(black screen, mouse pointer freezing, flickering, etc).

I am trying to understand why structs damaging.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #15)
> I don't have the same backtrace. I have a backtrace like Magnus Kessler's one
> at https://bugs.freedesktop.org/show_bug.cgi?id=30509
No, that's another -likely unrelated- bug :-(

> All crashes occurs when there was a full-screen
yes - reasonable, but not related to this issue at all.

> I am trying to understand why structs damaging.
nullpointers are not exactly "damaged" like "dangeling pointers" but can be valid states, they might however require different treatment (reallocation or whatever) than a simple
"if (!pointer) return;"

[Alex3255 (alex3255)]

I think that the two backtraces are consequences of one bug. Because
1) Developers marked my bug https://bugs.freedesktop.org/show_bug.cgi?id=33496 as a duplicate for 30509 and 30509 has the same backtrace as this.
2) Here is a patch for the first backtrace:
+ if (irb == NULL || irb->region == NULL)
+ goto clear_bit;
+
Here is code, that causes a segfault in my backtrace:
 irb = intel_get_renderbuffer(fb, buf);
 struct gl_renderbuffer *rb = ctx->DrawBuffer->_ColorDrawBuffers[i];
 struct intel_renderbuffer *irb = intel_renderbuffer(rb);
 struct intel_region *region = irb ? irb->region : NULL;

 brw_add_validated_bo(brw, region->buffer); // irb->region == 0 -> crash

There is one simple way to figure this out - apply proposed patch and check if each bug if gone. I'll be happy if someone check it.

---
I am logging most activity of kwin, mesa and libdrm and found that a mesa's function intel_region_alloc_for_handle unexpectedly returns NULL. I'll going to talk about it with upstream.

[Thomas-luebking (thomas-luebking)]

*** Bug 265960 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

*** Bug 266132 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 266416 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 267939 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 268027 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

at least the last dupe is on a radeon chip...

[Thomas-luebking (thomas-luebking)]

...and seems just a different bug deep down in the ubuntu "natty" mesa version - no real dupe

[Thomas-luebking (thomas-luebking)]

*** Bug 268321 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

*** Bug 268394 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 268589 has been marked as a duplicate of this bug. ***

[Nikola Snele (n-schnelle)]

I have been testing and these are my findings:

Mesa 7.9 classic - no kwin crashes
Mesa 7.11-devel classic - no kwin crashes
Mesa 7.10.1 gallium (natty default) - kwin crashes whenever you change window decoration, color scheme, turn on/off effect, turn on/off vsync etc.

So problem seems to be in Mesa 7.10.1 gallium.

All these tests are performed on KDE 4.6.1 with radeon driver.

[Thomas-luebking (thomas-luebking)]

*** Bug 269314 has been marked as a duplicate of this bug. ***

[Alain ANDERLINI (alain-anderlini)]

wrt comment #28, i experienced exactly the same crash as initially submitted when returning from flash full screen in Chrome albeit I have Mesa 7.9 installed (i915 Intel driver 2.14.901 running with KDE 4.6.1). Did not try with Mesa 7.11 version.

[Nikola Snele (n-schnelle)]

Now I am on Mesa 7.10.1 classic and no crashes.

So problem is 100% in gallium driver.

[Mgraesslin (mgraesslin)]

*** Bug 269504 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

*** Bug 269562 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 269889 has been marked as a duplicate of this bug. ***

[Harald Sitter (apachelogger)]

Martin, any thoughts? Backtrace makes my weak mind think it might be driver related.

[Martin Gräßlin (ubuntu-martin-graesslin)]

Most often reported bug in the history of KWin and unfortunately a driver bug. We changed the defaults in 4.7 to no longer trigger it, that's the max we could do.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Harald Sitter (apachelogger)]

I'll mark the bug fixed then. 11.10 should not trigger it anymore. Thanks Martin.

[Mgraesslin (mgraesslin)]

*** Bug 293281 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

*** Bug 302764 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 301529 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 303961 has been marked as a duplicate of this bug. ***

[Dan O'Keefe (dano0955)]

update mesa  ...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...

-------------------------------------------------------

Sponsored links:
Rock Hard Erections. All New Formula
Attacks the Root Fast
www.capitolbird.org/pharma.html

________________________________
 From: Thomas Lübking <email address hidden>
To: <email address hidden>
Sent: Monday, July 23, 2012 10:40 AM
Subject: [Bug 252817] KWin crashes on intel/mesa glClear(GL_COLOR_BUFFER_BIT)

https://bugs.kde.org/show_bug.cgi?id=252817

Thomas Lübking <email address hidden> changed:

           What    |Removed                    |Added
----------------------------------------------------------------------------
                 CC|                            |<email address hidden>

--- Comment #177 from Thomas Lübking <email address hidden> ---
*** Bug 303961 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 304042 has been marked as a duplicate of this bug. ***

[danae (ahepas1999)]

Created attachment 72806
New crash information added by DrKonqi

kwin (4.8.4 (4.8.4)) on KDE Platform 4.8.4 (4.8.4) using Qt 4.8.1

- What I was doing when the application crashed:
My dell inspiron n5110 came out of sleep when this crash occured

-- Backtrace (Reduced):
#7 brw_update_renderbuffer_surface (brw=0x9e0c310, rb=0xa04bf88, unit=0) at brw_wm_surface_state.c:970
#8 0xaea6f7a3 in brw_update_renderbuffer_surfaces (brw=0x9e0c310) at brw_wm_surface_state.c:1066
#9 0xaea5825f in brw_upload_state (brw=0x9e0c310) at brw_state_upload.c:508
#10 0xaea3efef in brw_try_draw_prims (max_index=5, min_index=0, ib=0x0, nr_prims=1, prim=0xbfde8738, arrays=0xa278160, ctx=0x9e0c310) at brw_draw.c:482
#11 brw_draw_prims (ctx=0x9e0c310, prim=0xbfde8738, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=5, tfb_vertcount=0x0) at brw_draw.c:572

[Thomas-luebking (thomas-luebking)]

=====================================================================
IT IS COMPLETELY POINTLESS TO ADD FURTHER CRASH REPORTS TO THIS BUG.
=====================================================================

This is a *Driver Bug*.

We cannot do anything in KWin to fix this bug.

Recent versions have fullscreen unredirection disabled by default.
If you enabled it and encountered this bug, just disable it again - there is no other fix.

Open konsole and enter:
kwriteconfig --file kwinrc --group Compositing --key UnredirectFullscreen false
qdbus org.kde.kwin /KWin reconfigure
qdbus org.kde.kwin /KWin toggleCompositing
qdbus org.kde.kwin /KWin toggleCompositing

Or use systemsettings or "kcmshell4 kwincompositing" to configure it with a GUI

[Mgraesslin (mgraesslin)]

*** Bug 304464 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

*** Bug 305002 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

*** Bug 306254 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 307442 has been marked as a duplicate of this bug. ***

[Sergio Callegari (callegar)]

Well, yes there is little that can be done to the kwin package to fix this, but something can probably be done for ubuntu precise in general...

I am running the newer intel drivers from the oibaf PPA, together with a 3.5 kernel and the bug seems to be fixed here.
So, backporting the relevant changes to the ubuntu kernel (maybe this has already been done) and the ubuntu intel drivers would probably be a good thing to make the LTS happy.

[Thomas-luebking (thomas-luebking)]

*** Bug 310027 has been marked as a duplicate of this bug. ***

[kotfantazer (kotfantazer)]

Kwin crashing when you select "disable visual effects for the full screen window" when starting stellarium.

When unselected option "disable visual effects for full-screen windows" does not crash

OS: Linux 3.6.11-4.fc16.i686 i686
System: Fedora release 16 (Verne)
KDE: 4.8.5 (4.8.5)

[Kamil Roman (kamil-lech-roman)]

A few updates:
1. Disabling the fullscreen unredirection does not help any more.
2. A bug has been submited to mesa bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58834

[Mgraesslin (mgraesslin)]

*** Bug 317594 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 320624 has been marked as a duplicate of this bug. ***

[Ben Cooksley (bcooksley)]

Removing <email address hidden> per abuse report.

[Thomas-luebking (thomas-luebking)]

*** Bug 321959 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

*** Bug 322206 has been marked as a duplicate of this bug. ***

[Thomas-luebking (thomas-luebking)]

Git commit 9f7d825e5323dd25ece39d9af56d49318396ead2 by Thomas Lübking.
Committed on 10/07/2013 at 18:48.
Pushed by luebking into branch 'KDE/4.11'.

ignore unredirection configuration on intel

the only thing it does on these systems is cause users
trouble because usually when there's a client where
unredirection makes sense, that uses OpenGL - and then
things break in the driver.
REVIEW: 111476

M +2 -0 kwin/eglonxbackend.cpp
M +2 -0 kwin/glxbackend.cpp
M +2 -0 kwin/options.cpp

http://commits.kde.org/kde-workspace/9f7d825e5323dd25ece39d9af56d49318396ead2

[Alexander Mezin (mezin-alexander)]

Please revert this.
It worked for me very well (Intel HD 3000). Also, without it I can't currently use DRI_PRIME.
Add a warning, don't enable it by default, but please, let me decide if I want this feature or not. Without patching.
Also, I prepared a patch that makes it less agressive (for example, fullscreen Flash videos aren't unredirected with it). I spent more than hour trying to figure out why shouldUnredirect() isn't called.

[Stefan-b (stefan-b)]

Hey,

Just upgrade to the newer version of Kubuntu.
Works fine for me now.

Best,
S.

On 07/28/2013 09:03 AM, Alexander Mezin wrote:
> https://bugs.kde.org/show_bug.cgi?id=252817
>
> Alexander Mezin <email address hidden> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |<email address hidden>
>
> --- Comment #195 from Alexander Mezin <email address hidden> ---
> Please revert this.
> It worked for me very well (Intel HD 3000). Also, without it I can't currently
> use DRI_PRIME.
> Add a warning, don't enable it by default, but please, let me decide if I want
> this feature or not. Without patching.
> Also, I prepared a patch that makes it less agressive (for example, fullscreen
> Flash videos aren't unredirected with it). I spent more than hour trying to
> figure out why shouldUnredirect() isn't called.
>

[Thomas-luebking (thomas-luebking)]

(In reply to comment #195)
> Please revert this.
> Add a warning, don't enable it by default

It *is* disabled by default - what does not prevent people from happily activating it, because some guy in a random forum told them "it's the best trick ever" - and then report crashes in driver that resolve by "after disabling unredirection, bug is gone"

We basically (and actually for far too long) expose users to a feature, while knowing it will crash their WM more or less for sure.

> It worked for me very well (Intel HD 3000).
Since you mentioned DRI_PRIME, it will rather be some IGP-GPU briged system?

> Also, without it I can't currently use DRI_PRIME.
As far as i was told, DRI_PRIME does only work *with* redirection, ie. whenever you disable the compositor, the DRI_PRIME context paints nothing.
If it does NOT work redirected for you, the better solution to suspend compositing altogether is not affected.
Either (depending on redirection states) would probably a major bug in the prime handling, though.

> Also, I prepared a patch that makes it less agressive
The level of "aggression" is not relevant, esp. since you try to constrain it to the most problematic cases (override_redirect windows, assuming those are games, ie. likely will have a second GL context) - which overmore would largely benefit from simply turning the compositor off instead (frees memory, quits redirection/damage processing/conversion overhead)

What currently missing to do this from scripts is to have scripts informed when unmanaged windows are added, eventually resized to/from "fullscreen".

[Alexander Mezin (mezin-alexander)]

(In reply to comment #197)
> It *is* disabled by default - what does not prevent people from happily
> activating it, because some guy in a random forum told them "it's the best
> trick ever" - and then report crashes in driver that resolve by "after
> disabling unredirection, bug is gone"
Then add big red label in KCM: "This could cause crashes. Don't file bugs, you've been warned". Compositing could also cause problems with buggy drivers.

> We basically (and actually for far too long) expose users to a feature,
> while knowing it will crash their WM more or less for sure.
For me it NEVER crashed KWin or anything.

> > It worked for me very well (Intel HD 3000).
> Since you mentioned DRI_PRIME, it will rather be some IGP-GPU briged system?
Yes, but KWin is always running on Intel, and doesn't even know about Radeon.

> As far as i was told, DRI_PRIME does only work *with* redirection, ie.
> whenever you disable the compositor, the DRI_PRIME context paints nothing.
No, for me it paints black screen when compositing is enabled (without unredirection).

> If it does NOT work redirected for you, the better solution to suspend
> compositing altogether is not affected.
I can't find an option to automatically suspend compositing in KCM.
Instead there's now non-working (silently!) option for unredirection.

And... Mutter and Compiz now do unredirection by default. And seems that they don't crash too much.

[Alex (hello71)]

(In reply to comment #198 as excerpted)
> (In reply to comment #197)
> > If it does NOT work redirected for you, the better solution to suspend
> > compositing altogether is not affected.
> I can't find an option to automatically suspend compositing in KCM.
> Instead there's now non-working (silently!) option for unredirection.

Put a rule in "Window Rules" (component "Window Behavior") selecting the window, then in "Appearance & Fixes" (last tab), set "Block compositing" to Force Yes.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #198)

> Then add big red label in KCM:
kde-workspace is frozen. -> not before summer 2014 (iff at all)

> For me it NEVER crashed KWin or anything.
Lucky for you. Yet bugzilla suggests there's a problem.
Look at only the plain dupes of this one and feel free to search through bugzilla...

> Yes, but KWin is always running on Intel, and doesn't even know about Radeon.
Yes, but dri does. The crash is in the driver.

> No, for me it paints black screen when compositing is enabled (without
> unredirection).
So it works with suspended compositing as well?

> I can't find an option to automatically suspend compositing in KCM.
Because a general setting would be silly. Already was for unredirection.

(In reply to comment #199)
> Put a rule in "Window Rules" (component "Window Behavior") selecting the
> window, then in "Appearance & Fixes" (last tab), set "Block compositing"

This will unfortunately not work with unmanaged windows (and for some strage reason most SDL games are; though i expect they will have to change if they still want to be "fullscreened" on wayland as well)

@Alex
You should have received a RR that enables controlling this via kwin scripts.

> Instead there's now non-working (silently!)
Yes, that's a bit unfortunate. We had to remove gl system detection from the settings because it occasionally caused (guess what) driver crashes (though iirc mostly amd) - killing the dialog or even systemsettings.

> And... Mutter and Compiz now do unredirection by default.
They're probably just better than kwin then.
Or will figure such things happen.

[Alexander Mezin (mezin-alexander)]

(In reply to comment #200)
> > I can't find an option to automatically suspend compositing in KCM.
> Because a general setting would be silly. Already was for unredirection.
Probably it won't.
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idp6357888
https://git.reviewboard.kde.org/r/110088/
I think this could be a good "default" option, if you replace "unredirect" with "suspend".

[Thomas-luebking (thomas-luebking)]

(In reply to comment #201)
> (In reply to comment #200)
> > > I can't find an option to automatically suspend compositing in KCM.
> > Because a general setting would be silly. Already was for unredirection.
> Probably it won't.
> http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idp6357888

This is not about "a general setting" at all, but about a protocol.
The silly part about the *general* setting was that we treated konqueror and quake equally.

The _NET_WM_BYPASS_COMPOSITOR was actually somehow inspired by the (largely ignored) _KDE_NET_WM_BLOCK_COMPOSITING, so merging the atoms and deprecate _KDE_NET_WM_BLOCK_COMPOSITING certainly makes sense.
It will require to move the blocking code from Client to Toplevel - does anything but (upcoming) SDL2 support it so far?

> https://git.reviewboard.kde.org/r/110088/
> I think this could be a good "default" option

The problem of this is that we don't get out of the "default" since there's no system in place to rule override_redirects (since they do not belong to WM or user)

The _NET_WM_BYPASS_COMPOSITOR tristate is a red herring: if special clients are not interested in saying: "1", why should regular clients be interested in saying "2"?
And why esp. those which are override_redirect and thus often don't set any properties at all?

The next problem is that unmanged windows are only matched "fullscreen" by their geometry, so if your imagebrowser opens a popup to preview the image and uses the maximum screen area, you'll toggle compositing by it.

-> The only (present) "downstream" (user accessible) way to control those (and FS state changes of managed clients) is via the script interface.

[Alexander Mezin (mezin-alexander)]

(In reply to comment #202)
> It will require to move the blocking code from Client to Toplevel - does
> anything but (upcoming) SDL2 support it so far?
AFAIK, almost every new game is using SDL 2 (from games based on MonoGame to Valve's Source). And most old games are using SDL 1, which does override_redirect. I say "most" and "almost" here, but I don't know any exceptions.

> The _NET_WM_BYPASS_COMPOSITOR tristate is a red herring: if special clients
> are not interested in saying: "1", why should regular clients be interested
> in saying "2"?
Regular clients don't need to say anything, they won't be unredirected/compositing won't be suspended.

> And why esp. those which are override_redirect and thus often don't set any
> properties at all?
You answered yourself:
> The next problem is that unmanged windows are only matched "fullscreen" by
> their geometry, so if your imagebrowser opens a popup to preview the image
> and uses the maximum screen area, you'll toggle compositing by it.
It's not too hard to set this hint, 3 lines of code with Xlib or a bit more with xcb.
Also, as Gnome's Mutter does almost the same things (in particular, it unredirects unmanaged windows), non-KDE clients will have this hint where needed.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #203)

> And most old games are using SDL 1
Even if, that's irrelevant.
Actually that would make the solution *extremely* simple: have SDL1 tag the window as "_NET_WM_BYPASS_COMPOSITOR", "1" - problem solved.

> which does override_redirect.
You are aware that "override_redirect" just means: "Dear WM, please ignore me"?
Every popup and tooltip, many docks, some "fullscreen" windows of all sorts (often because they're just popups), a whole bunch of synthetic windows and whatnot are.
It's not somehow a hint on the content of the window or some SDL exclusive.
The state is not a usable hint on whether compositing should be used. You enter the field of heuristics what means you'll hit false positives for sure.

> Regular clients don't need to say anything, they won't be
> unredirected/compositing won't be suspended.

I think there's a misunderstanding about "regular" - i was only talking about "override_redirect windows that are not interested in skipping the redirection", NOT about "non override_redirects".

> > And why esp. those which are override_redirect and thus often don't set any
> > properties at all?
> You answered yourself:
No, where?

> It's not too hard to set this hint, 3 lines of code with Xlib or a bit more
> with xcb.

The problem is not that it's hard to do, the problem is that nobody does and especially you can not expect "legacy" clients to alter to match your reconsiderations about the protocol.
Providing the ability to hint this preference is fine, but an absent hint only indicates an absent hint - not any intention.

[Alexander Mezin (mezin-alexander)]

(In reply to comment #204)
> Actually that would make the solution *extremely* simple: have SDL1 tag the
> window as "_NET_WM_BYPASS_COMPOSITOR", "1" - problem solved.
AFAIK SDL 1 reached end of life - there won't be any official updates. Actual problem with legacy code is here, not with "false positives".

And let's talk about my patch in reviewboard.

Currently I want to solve another problem: I can't enable unredirection with one click anymore, just because other users with broken gpu drivers clicked too much.
Your "fix" causes regression for me. Isn't it a bad fix?

Also, you've disabled all Intel cards, while the problem may be specific to i915g driver or older mesa versions.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #205)
> (In reply to comment #204)
> > Actually that would make the solution *extremely* simple: have SDL1 tag the
> > window as "_NET_WM_BYPASS_COMPOSITOR", "1" - problem solved.
> AFAIK SDL 1 reached end of life - there won't be any official updates.
> Actual problem with legacy code is here, not with "false positives".
No, false positives is what you'll get on your approach - proof: the cause for this discussion.

> Your "fix" causes regression for me. Isn't it a bad fix?
It's not a fix, thus not a bad fix.
It's a trade-off: we've a feature that will either get you less performance boost than another feature - or crashes.

Then what's the "regression"?
You suspend compositing instead and get 3 more extra fps in your shooter?

If you can work around the problem in a way so that we do no more get a "help, kwin crashed after checking this" bugreport about every week, i'll happily vote for that solution.

inb4: If your solution is "disable it by default and remove the config GUI", you're asking for a single target ("you") solution - and i'm dead sure the "secret command to make kwin faster" will show up pretty fas as well - with known consequences.

> Also, you've disabled all Intel cards, while the problem may be specific to
> i915g driver or older mesa versions.

It seems Sandybridge is affected by the same root cause (see comment #17 and comment #43) and it seems Ubuntu/Compiz meanwhile figured this happens =)
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/947544

[Alexander Mezin (mezin-alexander)]

(In reply to comment #206)
> No, false positives is what you'll get on your approach - proof: the cause
> for this discussion.
Yes, I'll get some false positives. Theoretically. But in practice:
- What's the problem with unredirected fullscreen unmanaged window? It could cause flicker once, nothing more.
- I've never seen such windows (where I didn't want unredirection).

> Then what's the "regression"?
> You suspend compositing instead and get 3 more extra fps in your shooter?
I get black screen when I run something with DRI_PRIME=1. And after reverting it everything is fine again.

> If you can work around the problem in a way so that we do no more get a
> "help, kwin crashed after checking this" bugreport about every week, i'll
> happily vote for that solution.
Suspend compositing instead of unredirecting? I'm not against it, I'm against removing single-checkbox solution.

> you're asking for a single target ("you") solution
Solution for a single target (me) is git revert.

[Thomas-luebking (thomas-luebking)]

(In reply to comment #207)

> - What's the problem with unredirected fullscreen unmanaged window? It could
> cause flicker once, nothing more.
It could flicker often, but the problem of course magnifies when you suspend compositing (because things like present windows etc. won't work either)

> - I've never seen such windows (where I didn't want unredirection).
Individual experience is, frankly, irrelevant.

> I get black screen when I run something with DRI_PRIME=1. And after
> reverting it everything is fine again.
Since you already run it with a shell export, you can just as easily block compositing around it.

> I'm not against it, I'm against removing single-checkbox solution.
And the truth is that a "single-checkbox solution" regardless of the backend (unredirection/suspension) does not work. For complete suspension it's actually a complete no-go.
Property hint control works. Rules work. Scripts (kinda dynamic rules) work.
"Yes or no" has been imprecise and will remain so, thus also your RR to sharpen it (regardles on whether implying "override_redirect = SuperMeatBoy = SDL" assumptions are reasonable)

[Ben Cooksley (bcooksley)]

Removing <email address hidden> from CC list per abuse report.

[Mgraesslin (mgraesslin)]

> > No, false positives is what you'll get on your approach - proof: the cause
> > for this discussion.
>
> Yes, I'll get some false positives. Theoretically. But in practice:
> - What's the problem with unredirected fullscreen unmanaged window? It could
> cause flicker once, nothing more.
KWin uses unredirected fullscreen translucent (!) unmanaged windows.

[Ben Cooksley (bcooksley)]

Removing <email address hidden> per abuse report.

[Thomas-luebking (thomas-luebking)]

Git commit f215bfb502461f2c2b281d023b0a92b2464422d7 by Thomas Lübking.
Committed on 28/07/2013 at 19:44.
Pushed by luebking into branch 'KDE/4.11'.

write back unsupported (kwin-intel) unredirection

to have a minimal hint on "this does not work"

REVIEW: 111772

M +3 -0 kwin/options.cpp

http://commits.kde.org/kde-workspace/f215bfb502461f2c2b281d023b0a92b2464422d7