I no longer have Compiz-Fusion running on the LXDE-based computer, named ‘Klexel’.

According to this earlier posting, I had run in to stability issues with my newly-reinstalled Linux computer, which I name ‘Klexel’. Well, the only sensible way, finally, to solve those problems, was to deactivate ‘Compiz Fusion’, which is a special window-manager / compositor, that creates a desktop cube animation, as well as certain other effects, chosen by the user out of a long menu of effects, but which needs to run on the graphics hardware, using OpenGL.

Even though Compiz Fusion is fancy and seems like a nice idea, I’ve run in to the following problems with it, in my own experience:

  • Compiz is incompatible with Plasma 5, which is still my preferred desktop manager,
  • If we have a weak graphics-chip, such as the one provided on the computer named ‘Klexel’ using ‘i915 Support’, trying to run Compiz on it forces the so-called GPU to jump through too many hoops, to display what it’s being asked to display.

Before a certain point in time, even a hardware-accelerated graphics chip, only consisted of X vertex pipelines and Y fragment pipelines, and had other strict limitations on what it could do. It was after a point in time, that the “Unified Shader Model” was introduced, whereby any GPU core could act, as a vertex shader core, as a fragment shader core, etc.. And after that point in time, the GPU also became capable of rendering its output to texture images, several stages deep… Well, programmers today tend to program for the eventuality, that the host machine has ‘a real GPU’, with Unified Shader Model and unlimited cores, as well as unlimited texture space.

The “HP Compaq DC7100 SFF”, that has become my computer ‘Klexel’, is an ancient computer whose graphics chip stems from ‘the old days’. That seems to have been an Intel 910, which has as hardware-capability, direct-rendering with OpenGL 1.4 , the Open-Source equivalent of DirectX 7 or 8 . Even though some Compiz effects only require OpenGL 1.4 , by default, I need to run the computer named ‘Klexel’ without compositing:

screenshot-from-2018-09-04-11-56-50

Also, before, when this was the computer ‘Walnut’, it actually still had KDE 3 on it! KDE 3 was essentially also, without compositing.

It should finally be stable again, now.

By comparison, the computer which acts as Web-server and hosts this blog, which I name ‘Phoenix’, has as graphics chip an Nvidia “GeForce 6150SE”, that is more powerful than the Intel ‘i915′ series was, is capable of OpenGL 2.1 , equivalent to DirectX 9 , but still predated the Unified Shader Model chips. Microsoft has even dropped support for this graphics chip, because according to Microsoft, it’s also not powerful enough anymore. And so up-to-date Windows versions won’t run on either of these two computers.

(Update 09/04/2018, 18h20 : )

Continue reading I no longer have Compiz-Fusion running on the LXDE-based computer, named ‘Klexel’.

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’

I’m impressed with the Mesa drivers.

Before we install Linux on our computers, we usually try to make sure that we either have an NVIDIA or an AMD / Radeon  GPU  – the graphics chip-set – so that we can use either the proprietary NVIDIA drivers designed by their company to run under Linux, or so that we can use the proprietary ‘fglrx’ drivers provided by AMD, or so that we can use the ‘Mesa‘ drivers, which are open-source, and which are designed by Linux specialists. Because the proprietary drivers only cover one out of the available families of chip-sets, this means that after we have installed Linux, our choice boils down to a choice between either proprietary or Mesa drivers.

I think that the main advantage of the proprietary drivers remains, that they will offer our computers the highest version of OpenGL possible from the hardware – which could go up to 4.5 ! But obviously, there are also advantages to using Mesa , one of which is the fact that to install those doesn’t install a ‘blob’ – an opaque piece of binary code which nobody can analyze. Another is the fact that the Mesa drivers will provide ‘VDPAU‘, which the ‘fglrx’ drivers fail to implement. This last detail has to do with the hardware-accelerated playback of 2D video-streams, that have been compressed with one out of a very short list of Codecs.

But I would add to the possible reasons for choosing Mesa, the fact that its stated OpenGL version-number does not set a real limit, on what the graphics-chip-set can do. Officially, Mesa offers OpenGL 3.0 , and this could make it look at the surface, as though its implementation of OpenGL is somewhat lacking, as a trade-off against its other benefits.

One way in which ‘OpenGL’ seems to differ from its competitor in real-life: ‘DirectX’, is in the system by which certain DirectX drivers and hardware offer a numeric compute-level, and where if that compute-level has been achieved, the game-designer can count on a specific set of features being implemented. What seems to happen with OpenGL instead, is that 3.0 must first be satisfied. And if it is, the 3D application next checks individually, whether the OpenGL system available, offers specific OpenGL extensions by name. If the application is very-well-written, it will test for the existence of every extension it needs, before giving the command to load that extension. But in certain cases, a failure to test this can lead to the graphics card crashing, because the graphics card itself may not have the extension requested.

As an example of what I mean, my KDE / Plasma compositor settings, allow me to choose ‘OpenGL 3.1′ as an available back-end, and when I select it, it works, in spite of my Mesa drivers ‘only’ achieving 3.0 . I think that if the drivers had been stated to be 3.1 , then this could actually mean they lose backward-compatibility with 3.0 , while in fact they preserve that backward-compatibility as much as possible.

screenshot_20171127_185831

screenshot_20171127_185939

Continue reading I’m impressed with the Mesa drivers.

I question the amount of VRAM on Phoenix.

I am still contemplating, why the server-box I name ‘‘ was crashing, and my attention keeps coming back to the graphics chip. Before this computer was resurrected, it was running in 32-bit mode, as ‘‘. At that time, it only had 2GB of RAM. But now it runs in 64-bit mode, with 4GB of RAM.

When I boot, the BIOS message still tells me that it has 128MB of shared memory, for the graphics chip. But strangely enough, the piece of text I pasted into this posting, reads that the graphics driver has set aside 256MB of VRAM, near the top of the 4GB of physical addresses. I did not know that the kernel can override a BIOS setting in this way, let us say just because processing has been switched to 64-bit mode.

One mishap which could naively go wrong, is that the legacy driver, unaware of the specifics of this motherboard, could be allocating 256MB of shared memory, but that physically, the hardware cannot share past the address ‘‘. That is, the address ‘‘ may have become forbidden territory for the graphics card. It is however uncommon, that the programmers of kernel-space modules, would make such a simple mistake.

This is a 64-bit system, which only accepts up to 4GB of RAM, thus only possessing 32-bit physical addresses, to go with its 64-bit virtual addresses.

According to this screen-shot:

phoenix_ram_1

I only have 3.74GB of RAM available to the system, instead of 4GB. The reason for this, is the fact that 256MB have in fact been reserved for the graphics chip. By itself this would seem to suggest, that the allocation has succeeded.

Also, the fact that 49.26MB of shared memory was momentarily being indicated, is not too telling, because several types of processes could be using shared memory for some purpose. This feature does not only exist, for user-space processes to make texture images available to the graphics card.

Continue reading I question the amount of VRAM on Phoenix.