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

## Kernel Update today, Downtime, Multiple Reboot-Attempts

Today, the PC which is hosting my site and blog, which I name ‘Phoenix’, received a kernel update.

Debian Team has not been following standard guidelines in their propagation of kernel updates, as the last 3 updates produced the same kernel-version number:


3.16.0-6-amd64



Because even Linux computers require a reboot after a kernel-update, this blog was temporarily off-line from about 13h05 until 13h25. I apologize for any inconvenience to my readers.

There is a fact about the build of Linux on this computer which I should bring up. I have the following on-board graphics-chip:


GeForce 6150SE nForce 430/integrated/SSE2



And this proprietary graphics driver is the only one, capable of working with the said graphics-chip:


NVIDIA 304.137



The graphics driver is installed from standard Debian repositories.

Somewhere between these software-packages there is a problem, which Debian Team has never been aware of, but which has existed ever since I installed Debian / Jessie on this computer. Directly after a reboot, the ability of the X-server to start, is not reliable. Sometimes, the X-server starts on the first try, but on other occasions I need to make 7 reboot attempts, before the X-server will start, and from one reboot-attempt to the next, I change nothing.

Once the X-server has started successfully, this graphics-chip will work 100% for 30 days !

I have been reluctant to point this out for the past few years, because if a Debian developer finds out about it, he will try to fix this problem. And when he does, he will brick my computer.

This afternoon, 7 reboots were in fact required, before the X-server started. That is why the reboot-procedure took 20 minutes of time.

(Updated 07/14/2018, 16h45 … )

## How to Add a Web-browser to GNURoot + XSDL.

In This earlier posting – out of several – I had explained, that I’ve installed the Android apps “GNURoot Debian” and “XSDL” to my old Samsung Galaxy Tab S (first generation). The purpose is, to install Linux software on that tablet, without requiring that I root it. This uses the Android variant of ‘chroot’, which is actually also called ‘proot’, and is quick and painless.

However, there are certain things which a ch-rooted Linux system cannot do. One of them is to start services to run in the background. Another is, to access hardware, as doing the latter would require access to the host’s ‘/dev’ folder, not the local, ch-root’s ‘/dev’ folder. Finally, because XSDL is acting as my X-server, when GNURoot’s guest-software tries to connect to one, there will be no hardware-acceleration, because this X-server is really just an Android app, and does not really correspond to a display device.

This last detail can be quite challenging, because in today’s world, even many Linux applications require, direct-rendering, and will not function properly, if left just to use X-server protocol, à la legacy-Unix. One such application is any serious Web-browser.

This does not result from any malfunction of either Android app, because it just follows from the logic, of what the apps are being asked to do.

But we’d like to have a Web-browser installed, and will find that “Firefox”, “Arora” etc., all fail over this issue. This initially leaves us in an untenable situation, because even if we were not to use our Linux guest-system for Web-browsing – because there is a ‘real’ Web-browser installed on the (Android) host-system – the happenstance can take place, by which a Web-document needs to be viewed anyway – let’s say, because we want to click on an HTML-file, that constitutes the online documentation for some Linux-application.

What can we do?