xscreensaver Bug With Latest Proprietary nVidia Graphics Drivers

As described in this posting, I have just applied a major software-update to the computer I name ‘Plato’, in which I replaced its open-source graphics drivers, with the proprietary nVidia drivers, suitable for its graphics card, and for its Linux-build.

That would be drivers version ‘375.82-1~deb9u1′ , from the package manager, for a ‘Debian 9.4′ system.

I have just noticed a major bug, which other people should know about, before they also decide to go with the proprietary drivers. They tend to cause some malfunction with OpenGL-based ‘xscreensaver’ screen-savers, version ‘5.36-1′ .

The bug seems to be, that if I use the graphical configuration tool to preview several screen-savers, when I switch from one screen-saver to another, the previous GL-screen-saver being previewed fails to terminate, which in turn causes the configuration window to freeze, so that the next-chosen screen-saver cannot be previewed. A small blank rectangle takes its place, in the configuration window. When this happens, I actually need to ‘kill -9′ the screen-saver-process – belonging to the screen-saver in question and not ‘/usr/bin/xscreensaver’ – the former of which is taking up 100% of 1 CPU core with nice-time, before I can continue previewing screen-savers.

The problem with this as I see it is, it could also happen after the screen-saver has locked the screen, and when I have entered my password to unlock it. The mere fact that I was always able to unlock one GL-based screen-saver in the past was good in itself, but may only have been luck! The strangeness with which my bug seems to differ from other users’ bug-reports, is that when my OpenGL-based screen-saver was rendering to the root window – i.e., to the whole screen – it did exit properly when unlocked by me.

So as it currently stands, I have set my screen-saver on the computer ‘Plato’, to just a blank screen… :-(

At the same time, OpenGL applications seem to run just fine, like this example, just tested:

screenshot_20180430_142338

However, since the description of the screen-saver packages in the package manager states “GL(Mesa)” screen-savers, it may be better just to ‘remove’ the ‘xscreensaver-gl’ and ‘xscreensaver-gl-extra’ packages.

I found out, that this bug also affects ‘rss-glx 0.9.1-6.1′ .

(Updated 04/30/2018, 19h25 … )

Continue reading xscreensaver Bug With Latest Proprietary nVidia Graphics Drivers

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