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

One of the subjects which fascinate me is, Computer-Generated Images, CGI, specifically, that render a 3D scene to a 2D perspective. But that subject is still rather vast. One could narrow it by first suggesting an interest in the hardware-accelerated form of CGI, which is also referred to as “Raster-Based Graphics”, and which works differently from ‘Ray-Tracing’. And after that, a further specialization can be made, into a modern form of it, known a “Deferred Shading”.

What happens with Deferred Shading is, that an entire scene is Rendered To Texture, but in such a way that, in addition to surface colours, separate output images also hold normal-vectors, and a distance-value (a depth-value), for each fragment of this initial rendering. And then, the resulting ‘G-Buffer’ can be put through post-processing, which results in the final 2D image. What advantages can this bring?

• It allows for a virtually unlimited number of dynamic lights,
• It allows for ‘SSAO’ – “Screen Space Ambient Occlusion” – to be implemented,
• It allows for more-efficient reflections to be implemented, in the form of ‘SSR’s – “Screen-Space Reflections”.
• (There could be more benefits.)

One fact which people should be aware of, given traditional strategies for computing lighting, is, that by default, the fragment shader would need to perform a separate computation for each light source that strikes the surface of a model. An exception to this has been possible with some game engines in the past, where a virtually unlimited number of static lights can be incorporated into a level map, by being baked in, as additional shadow-maps. But when it comes to computing dynamic lights – lights that can move and change intensity during a 3D game – there have traditionally been limits to how many of those may illuminate a given surface simultaneously. This was defined by how complex a fragment shader could be made, procedurally.

(Updated 1/15/2020, 14h45 … )

## A butterfly is being oppressed by 6 evil spheroids!

As this previous posting of mine chronicles, I have acquired an Open-Source Tool, which enables me to create 3D / CGI content, and to distribute that in the form of a WebGL Scene.

The following URL will therefore test the ability of the reader’s browser more, to render WebGL properly:

http://dirkmittler.homeip.net/WebGL/Marbles6.html

And this is a complete rundown of my source files:

http://dirkmittler.homeip.net/WebGL

(Updated 01/07/2020, 17h00 … )

(As of 01/04/2020, 22h35 : )

On one of my alternate computers, I also have Firefox ESR running under Linux, and that browser was reluctant to Initialize WebGL. There is a workaround, but I’d only try it if I’m sure that graphics hardware / GPU is strong on a given computer, and properly installed, meaning, stable…

## Understanding why some e-Readers fall short of performing as Android tablets (Setting, Hidden Benefits).

There is a fact about modern graphics chips which some people may not be aware of – especially some Linux users – but which I was recently reminded of because I have bought an e-Reader that has the Android O/S, but that features the energy-saving benefits of “e-Ink” – an innovative technology that has a surface somewhat resembling paper, the brightness of which can vary between white and black, but that mainly uses available light, although back-lit and front-lit versions of e-Ink now exist, and that consumes very little current, so that it’s frequently possible to read an entire book on one battery-charge. With an average Android tablet that merely has an LCD, the battery-life can impede enjoying an e-Book.

An LCD still has in common with the old CRTs, being refreshed at a fixed frequency by something called a “raster” – a pattern that scans a region of memory and feeds pixel-values to the display sequentially, but maybe 60 times per second, thus refreshing the display that often. e-Ink pixels are sent a signal once, to change brightness, and then stay at the assigned brightness level until they receive another signal, to change again. What this means is that, at the hardware-level, e-Ink is less powerful than ‘frame-buffer devices’ once were.

But any PC, Mac or Android graphics card or graphics chip manufactured later than in the 1990s has a non-trivial GPU – a ‘Graphics Processing Unit’ – that acts as a co-processor, working in parallel with the computer’s main CPU, to take much of the workload off the CPU, associated with rendering graphics to the screen. Much of what a modern GPU does consists of taking as input, pixels which software running on the CPU wrote either to a region of dedicated graphics memory, or, in the case of an Android device, to a region of memory shared between the GPU and the CPU, but part of the device’s RAM. And the GPU then typically ‘transforms’ the image of these pixels, to the way they will appear on the screen, finally. This ends up modifying a ‘Frame-Buffer’, the contents of which are controlled by the GPU and not the CPU, but which the raster scans, resulting in output to the actual screen.

Transforming an image can take place in a strictly 2D sense, or can take place in a sense that preserves 3D perspective, but that results in 2D screen-output. And it gets applied to desktop graphics as much as to application content. In the case of desktop graphics, the result is called ‘Compositing’, while in the case of application content, the result is either fancier output, or faster execution of the application, on the CPU. And on many Android devices, compositing results in multiple Home-Screens that can be scrolled, and the glitz of which is proven by how smoothly they scroll.

Either way, a modern GPU is much more versatile than a frame-buffer device was. And its benefits can contribute in unexpected places, such as when an application outputs text to the screen, but when the text is merely expected to scroll. Typically, the rasterization of fonts still takes place on the CPU, but results in pixel-values being written to shared memory, that correspond to text to be displayed. But the actual scrolling of the text can be performed by the GPU, where more than one page of text, with a fixed position in the drawing surface the CPU drew it to, is transformed by the GPU to advancing screen-positions, without the CPU having to redraw any pixels. (:1) This effect is often made more convincing, by the fact that at the end of a sequence, a transformed image is sometimes replaced by a fixed image, in a transition of the output, but between two graphics that are completely identical. These two graphics would reside in separate regions of RAM, even though the GPU can render a transition between them.

(Updated 4/20/2019, 12h45 … )