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 … )

(As of 04/29/2018 : )

Logically, it’s not so hard to deduce, that the fault must either be within the ‘xscreensaver’ program, or within the graphics driver. I’d bet the problem is with the ‘xscreensaver‘ program. My reason for this is the fact, that ‘xscreensaver’ can theoretically run any program as a screen-saver, and only needs to be told in the file ‘~/.xscreensaver’, that a given program uses OpenGL. Additionally, the fact that the package ‘rss-glx’ may have been programmed differently, but offers the same sort of candidate-programs, suggests it’s not the fault of any one screen-saver program. There just seems to be some issue in destroying the OpenGL rendering-context, when that context is not the root window, or, if ‘xscreensaver’ is switching from one screen-saver to another.

Yet, most of the other OpenGL applications seem to run just fine, including ‘glxgears’… Just not, as an ‘xscreensaver’ screen-saver.

But, along the same lines, if I was to choose the ‘BOINC Screen-Saver’, which also uses OpenGL, then again I should expect, that this saver will fail to exit after having been previewed in its mini-preview-window, but oddly, not fail to exit, if rendering to the root window. It’s just that, I don’t want to take my chances with the root window remaining locked one day… I hate file-system checks.

(Edit 04/30/2018 : )

Because ‘xscreensaver’ will virtually run any program as a screen-saver, and run it with ‘nice’, this poses the question of what, exactly, ‘xscreensaver’ does, to tell the actual screen-saver program to terminate. And it can only be some form of ‘kill’ command.

Under Linux, I’m aware of two distinct types of ‘kill’ commands:

  1. ‘kill -15′ Is a soft-kill, which allows the target program to clean up and exit gracefully, as if it had decided to do so within its own programming,
  2. ‘kill -9′ Is a hard-kill, which does not allow the target program to do anything, prior to being removed forcibly.

But, which kill command the actual programmers of ‘xscreensaver’ use, is mainly a subject of speculation to me. If they used a soft kill, and if the OpenGL-program did not exit, then why the program failed to do so needs to be examined, given the assumption that the graphics drivers should not be failing 100% of the time.

But, simply because the devs were worried, that the user might not be able to unlock his desktop, in cases where the screen-saver is also supposed to be a screen-locker, they may have chosen to issue a hard kill – every time. If they did this, it could be a mistake, because certain graphics drivers may not allow graphics memory to be cleaned up by the kernel, if the program died improperly.

(Update 04/30/2018, 19h25 : )

Actually, I found out that ‘xscreensaver’ does in fact send a ‘TERM’ signal to the so-called “hack”, which is another way to say, a soft kill.

I also found out that these GL-based screensavers, only use OpenGL 1.3 ! What this could mean is, that because nVidia has done its best to support OpenGL 4.5, support for 1.3 might have deteriorated…

Dirk

 

Print Friendly, PDF & Email

One thought on “xscreensaver Bug With Latest Proprietary nVidia Graphics Drivers”

Leave a Reply

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

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>