How an old problem with multiple (Debian / Linux) sessions seems to require an old fix.

One of the facts which I recently updated my postings with is, that I have the ability to run multiple sessions on one PC, and to switch back and forth between them, by using the key-combinations <Ctrl>+<Alt>+F7, <Ctrl>+<Alt>+F8, etc. According to that update, each session could theoretically use either ‘Plasma 5′, or ‘LXDE’ as its desktop manager, even though I’d choose an actual LXDE session for only one of my defined usernames.

When I was recently testing this ability, I found that a Plasma 5 session which had locked its screen (which I had switched away from), using the built-in Plasma 5 locker, would start to consume 1 CPU core at 100%, as was visible from within the other session. And, it appears that This is a bug which has been known for a long time, on computers that have the proprietary NVIDIA graphics drivers, as my computer named ‘Phosphene’ does. This computer is still based on Debian 9 / Stretch. Apparently, according to common lore, what one is supposed to do about this is, to create a file named such as ‘dirk.sh’ (in my case), in the directory ‘/etc/profile.d’, which is supposed to set two environment variables globally like so:

 

# An attempt to prevent klocker from consuming 1 CPU core 100%
# when multiple desktop sessions are active...

export KWIN_TRIPLE_BUFFER=1
export __GL_YIELD="USLEEP"

 

Unfortunately, this backfired on me when I tried to implement it, in that regardless of which way I tried to do so, ‘kwin’ would just crash in the session that’s supposed to be using ‘Plasma 5′. An additional mystery I ran in to was, that my attempts to set ‘__GL_YIELD’ would simply get reset somewhere, unless I had also set ‘KWIN_TRIPLE_BUFFER’. Only if I set both, would setting either reveal as successful, using an ‘echo $…’ command. (:1)  Therefore, what I really needed to do was, to turn off the Screen-Locking which is provided by Plasma 5 itself (for both my usernames), and to install and use ‘xscreensaver’ instead. However, doing that has two obvious caveats:

  • Under Debian 10 / Buster and later, ‘xscreensaver’ is no longer fully supported, unless one also reconfigured the new, Wayland display manager to act as an X-server proxy, And
  • Even when I apply this fix, which means that I’ve completely disabled ‘klocker’ in my settings, at the moment I tell Plasma 5 to launch a new, parallel session, foregoing-which causes <Ctrl>+<Alt>+F8 just to lead to a blank screen, Plasma 5 will lock the current session – Using ‘klocker’ again, and causing 100% CPU usage to become visible, again, from the second session.

What I find is that, once I’ve used my Plasma 5 session to create a parallel session, I need to switch to the first session once, using <Ctrl>+<Alt>+F7, and unlock that one. After that, both my Plasma 5 sessions will only lock themselves, using ‘xscreensaver’. And aside from that short, crucial interval, I haven’t seen 100% CPU-core usage again.


 

I should add that, for certain purposes, I sometimes choose only to install the CPU-rendered ‘xscreensaver’ packages, and deliberately do not install the hardware-accelerated ones. And in this case, the hardware-accelerated screensavers were omitted, simply because they could start running the busy-wait loop again, only this time, when invoked by ‘xscreensaver’.

(Update 3/24/2021, 13h55… )

Continue reading How an old problem with multiple (Debian / Linux) sessions seems to require an old fix.

Some Bugs of my LXDE-based Computer, ‘Klexel’

I wrote only yesterday, that I had set up a computer with the Linux desktop-manager ‘LXDE’, and that I had named that computer ‘Klexel’.

Well I’m finding out that this computer has a bug. If I leave it with its screen-locker locked for some time, and then unlock with my password, the unlock dialog seems to succeed, but only reveals a black desktop, with only the mouse-pointer visible.

I suspect that I know what causes this. The computer in question has an old ‘Intel 910′ graphics chip-set, and although it may be good the the chip-set is supported, that chip-set and its drivers have quirks. I do have OpenGL 1.4, which should be high enough a version. But it may be that ‘behind the screen-locker’, by the time I’ve unlocked the machine again, the ‘Compiz Fusion’ desktop compositor has crashed.

There are certain other quirks which point to a graphics chip problem:

  • The window title-bars sometimes don’t render, until I click in the region where the title-bar should be, in which case they reappear.
  • Wobbly Windows needs to be enabled, in order for me to be able to restore the title-bars in this simple way.

I found that a practical way to deal with this not-resuming from the screen-locker, may be, by setting the key-sequence <Ctrl>+<Alt>+<Backspace> just to kill the X-server, as it would do under KDE or Plasma 5, using the following customization. I can right-click on the Keyboard Layout Tray Icon, then left-click on “Keyboard Layout Handler Settings”, and then:

screenshot-from-2018-09-02-06-21-12_c

I have set 2 ‘setxkbmap Options':

  1. The Compose Key,
  2. The X-server kill key.

Killing the X- just prompts me for a log-in again.

Note:

There is some possibility that the Compiz crash, on resuming from a plain lock-screen, may have to do with the Compiz setting, to display a Splash Image. By default, Kanotix systems come with an animated Kanotix splash-screen, that may look nice on systems with stable graphics, and for the first few times the system is explored. We can change this splash-screen to something other than the Kanotix splash-screen.

But I have noticed that, just for Compiz to start the splash-screen, causes instability with the Intel 910 chip-set, even if it does work. So what may be happening, is that on resuming from the lock-screen, Compiz may be programmed to display the splash-screen, and doing so may be what crashes my session. And so for now, I’ve also disabled this feature, and will comment later, on whether having done so has fixed the crashes.

(Update 09/05/2018, 15h30 … )

(As of 09/02/2018 : )

Continue reading Some Bugs of my LXDE-based Computer, ‘Klexel’

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