There is a bug in the Wayland Compositor, under Debian Stretch.

One of the facts which I have written about before, is that modern desktop managers will use compositing – i.e. will use hardware-acceleration – to render desktop effects, specifically, when we are only running regular, 2D applications with a GUI. This feature exists with the old KDE 4, under Debian / Jessie, as well as with the new Plasma 5, under Debian / Stretch.

Under Debian / Jessie, this feature is extremely stable. Under Debian / Stretch, it is not yet so.

What will happen under Debian / Stretch, as far as I can make out, is that if an attempt has been made to disable compositing, instead of this succeeding, the desktop-session becomes corrupted, in that black rectangles will display, when we simply open multiple windows / dialogs. AFAICT, This can only be fixed, by rebooting / starting a new user-session.

I became aware of this, when running Steam-based games on the computer I name ‘Plato’. When games run that are heavy on OpenGL / Hardware-Rendering, it’s normal for the game-platform to try to switch compositing off, because often, the hardware-rendering of the game is not compatible with the desktop-compositing. After I have finished my session with Steam, the rendering errors in my desktop manager become noticeable, and Steam does not gain the permissions, to install any system software.

I do not blame this on Steam per se, because I can reproduce this problem by just clicking <Shift>+<Alt>+F12, which used to be the key-combination under KDE 4, that toggled desktop compositing on and off at will. Within seconds, under Plasma 5, this key-combination will also cause the malfunction.

(Updated 12/03/2017 : )

Now, there is a simplistic workaround for me:

 

  • System-Settings -> Display And Monitor -> Compositor
  • Uncheck “Allow applications to block compositing”
  • Reboot

But the success of this workaround requires two good fortunes:

  1. Under Plasma 5.8 , this setting is respected when I run Steam-based games – resulting in the malfunction no longer taking place afterward,
  2. If I was to run games (even Steam-based), which involve much-more-powerful graphics, those will no longer render properly, even in full-screen mode, If the compositor is active.

So, two games which will work this way are:

  • Sid Meier’s Civ 5
  • Sid Meier’s Civ – Beyond Earth

One game which has failed to cooperate in practice:

  • Quern – Undying Thoughts

In principle, my graphics H/W is not as strong, as the minimum system requirements stated on Steam, for “Quern”, but some remote possibility might exist, even to get Quern to run, if I reduce its graphical effects to their bare minimum, and If I can get any compositor-issue resolved… ( :1 )

The way it stands with Quern on that box, is that at first this game caused my graphics card to lock up, when its graphics settings were quite high, but at which time it was suspending compositing. After that, experiments to get Quern to run with lower graphics settings failed to progress beyond a certain stage, because apparently, it was not longer able to suspend compositing, which in turn caused the display to become jerky, and to tear at the edges. And this unstable display was strong enough, to prevent me from operating the settings menus adequately.

I suppose that a detail which I should add is, that on that ( Debian / Stretch ) PC, the compositor can be switched between three back-ends:

  1. OpenGL 2.0
  2. OpenGL 3.1
  3. (XRender) – No H/W Acceleration

But until now I’ve been using OpenGL 2.0 , over a vague recollection that choosing GL 3.1 , the compositing still works, but certain graphical editors which I have, which display their editing windows with OpenGL, crashed. As long as my compositor was still using GL 2.0 , those applications didn’t crash.


 

I can form a hypothesis at this point. As long as the application itself is still using OpenGL 2, I may still be okay to force it to fit into the compositor’s framework. But if the application – such as a fancy game – uses OpenGL 3, then I’m asking it to render its graphical output to an OpenGL 2 pipeline, which may be a doomed concept.

I have switched to using OpenGL 3 as my compositing back-end for the moment, even though unfortunately, the compositing still gets corrupted in practice, over having been suspended and then resumed. In fact, attempts to suspend it continue to fail. Therefore, even when using GL 3 for this, I need to leave the setting Unchecked, to allow applications to block this feature.

But, If I leave my compositing set to use GL 3, and never suspend it, then my OpenGL 2 -based games – i.e., the ‘Civ…’ games, continue to run with it enabled. And at that point I may also have some success in the future, of allowing the ‘Quern’ game to run – which uses GL3 itself – in spite of having compositing enabled.

Only, if I do run into applications in the future, which again crash due to the GL 3 compositing, this will present an unsolved problem. As it stands, none of the applications I can think of, presently crash due to GL 3 compositing…


 

Further, some sources suggest that the key-combination <Ctrl>+<Alt>+F12 is meant to switch compositing off, while <Shift>+<Alt>+F12 is meant to switch it back on. While certain other computers might be configured that way, all <Ctrl>+<Alt>+F12 does for me, is to Switch to an eventual X-Session #6, which has not been started yet, the same way <Ctrl>+<Alt>+F1 Switches me to Text-Session #1, via Frame-Buffer, which comes to life as soon as it is visited. And <Ctrl>+<Alt>+F7 then Switches me back to X-Session #1, which is underway.

Doing so does not corrupt my compositing.

I’m accustomed to this mechanism for opening multiple sessions on my computers, even though I rarely need to use it.


 

1: ) With my compositing back-end set to GL 3, I have now retried getting the game ‘Quern’ to run on the computer ‘Plato’. This time, there was no tearing of the display, and I was able to set the graphics to their minimum performance.

The result was, that instead of causing the GC simply to lock up, eventually, after several minutes of loading, Steam dropped me back to the desktop-view, with Steam running, but with the game no longer running. At that point, my compositing was Not corrupted. And I didn’t need a hard-boot like last time.

So, I was able to bypass this compositing bug for the moment, but am still not able to get ‘Quern’ to run on ‘Plato’.

(Edit 12/03/2017 : )

I should explicitly note, that the malfunction in question did not go away, just because I switched from GL 2 to GL 3 compositing. The problem has not recurred, because as before my experiment with Steam, no command has been given again, to suspend compositing.

Not recurred at all.

But, the switch to GL3 compositing has been ‘successful’, in that I’ve never been able to cause any applications to crash again, including video-players, just due to my use of GL 3 compositing. Suddenly, all my applications seem to like GL 3 compositing.

Dirk

 

Print Friendly, PDF & Email

One thought on “There is a bug in the Wayland Compositor, under Debian Stretch.”

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>