Simultaneous Update on Debian / Stretch Seems To Fix Wayland Bug, But An Effect Breaks.

This morning was one, on which most of my computers are receiving major system updates.

On the computer that acts as my Web-server, which I name ‘Phoenix’, this updated my Debian / Jessie version from 8.9 to 8.10.

On the computer which I most-recently installed, which I name ‘Plato’, this updated my Debian / Stretch version from 9.2 to 9.3 .

On both computers, this included a kernel-update. Additionally, it included an update, to the client-side X-server libraries. This posting has to do with the computer named ‘Plato’, which has kernel version ‘4.9.0-4-amd64′ now.

Previously I had blogged, that the computer named ‘Plato’ was suffering from a mysterious bug in its ‘Wayland’ compositor. If the compositing became suspended for any reason, after resuming, black rectangles would appear on the screen, as newly-opened windows faded in and out. This used to happen regardless of whether OpenGL 2 or OpenGL 3 compositing was being used.

Well since the update today, I tested the key-combination <Shift>+<Alt>+F12 again, which does the equivalent of sending the command to the compositor, to suspend. Apparently, the behavior of this key-combination has been changed since Debian / Jessie, so that instead of toggling, the compositing suspends for several seconds, and then automatically resumes. This would be useless as a user-feature, but can help with testing, because presumably, what an OpenGL application is supposed to do, is resend the signal every second or so, to make sure that compositing stays off.

To my pleasant surprise, I found that after compositing resumes, I no longer get black rectangles on the screen! :-)

Continue reading Simultaneous Update on Debian / Stretch Seems To Fix Wayland Bug, But An Effect Breaks.

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:

 

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

Caveat in using Visual Studio Express 2015

On my Windows 7 computer ‘Mithral’, I recently installed and started using “Visual Studio Express 2015″, which has Update 3.1, and am happy with it overall.

However, there is a type of malfunction which can take place, and apparently did. This IDE detected that I have 8 cores, and decided as a default that it would try to build as many as 8 targets concurrently, to maximize its speed. It did not detect that my 8 cores are threaded as 4, which is of minor significance. I changed the setting to 6 simultaneous builds, which means to me, that for each of the 6 targets, only one source file should be in the process of being compiled at once.

A type of condition seems to be possible, in which for an unknown reason, the application starts to build an extreme number of targets, which on my system meant maybe 15-20 targets. In the Task Manager, I saw up to 20 ‘cl.exe’ processes running at once. This was what led to an ‘OOM’ (‘Out-Of-memory’) condition, and required me to force the application to close from the Task Manager, as the IDE window had also stopped responding.

After that, I was not sure of the status of my build, so that I Cleaned the build, and also rebooted my machine, because the worst thing to my mind, would have been a not-clean shutdown. It seems that the actual reboot may not have been necessary.

After the reboot, I was able to build my Solution again, with no ill effects.

I am not sure what triggers this error, but do remember that on that occasion, I had Minimized the IDE application window and Restored it again. The whole thing gave me a bigger scare than was necessary, since no long-term corruption resulted.

Dirk