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:
I have set 2 ‘setxkbmap Options':
- The Compose Key,
- The X-server kill key.
Killing the X- just prompts me for a log-in again.
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 : )
This hypothesis would agree well with the fact that until now, another Compiz feature was not working properly: I have enabled the Annotate feature, which effectively allows the user to draw lines on the screen, in colors which he or she has configured. Well, so far, the colors which were annotated in this way, would always be applied in Additive Mode, even if the Compiz settings window selects them with a customizable opacity, to be alpha-blended with the regular screen view. This made the Annotate feature useless in the past.
Since I have disabled the Compiz splash-screen and rebooted, the Annotated lines are being drawn with the correct opacity. Apparently, such annotations as well as the splash-screen, are implemented as an overlay. It may be that on the Intel 910 graphics chip-set, the required number of overlays don’t render correctly, and they may be a root source of instability. Also, since having disabled the Compiz splash-screen, I’m noticing that the Window Title Bars are not disappearing on me anymore. So it looks hopeful, that the computer I name ‘Klexel’ is finally stable.
(Update 09/04/2018, 8h35 : )
I should mention, that with Compiz and LXDE, I’m using ‘light-locker’ and ‘lxlock’.
Alas, after running for 48 hours, the computer named ‘Klexel’ has had a relapse. Therefore, just disabling the Compiz behavior to display a Splash Screen, has not resolved the problem, which doing so was first intended to solve. However, disabling this feature, nevertheless enables me to Annotate, meaning to draw lines directly on the screen, with the correct opacity.
(Update 09/05/2018, 15h30 : )
I could formulate yet another hypothesis, as to why Compiz is not cooperating with my lock-screen:
- Every time the monitor switches off and the screen locks, the scene which the GPU is rendering could be crashing in some way.
- Because programmers have made improvements to Compiz, every time I unlock the screen, code running on the CPU might be recreating the scene, by allocating new Vertex Array-related -objects and linking them to existing drawing-surfaces, the latter acting as virtual desktops for running applications that have not quit.
- I myself have not yet allowed the session to ‘go to sleep’, with application-windows left open (to witness whether those are recreated as well).
- If this was in fact happening, it would represent a massive memory leak, because the previous scene was not cleaned up.
- If this was happening, it would explain why, each time I unlocked the screen, for just shorter than a second, I’d see a black screen, followed by the familiar Compiz session, working and intact again.
- After a certain number of unlocks, the GPU would run out of memory in which to store its ‘geometry info’, and for that reason, subsequent attempts of the Compiz software running on the CPU to recreate the scene, would fail. And then, I’d be left with a permanently-black screen.
My main problem with this hypothesis is, that I have no way to test it. If the person reading this has a similar issue, and is also using ‘lxlocker’ and ‘light-lock’, then what he or she might try next, is to Change a setting belonging to the LXDE Power Panel, Not to lock when the screen-saver starts, But to lock On Resuming from the lock-screen. If successful, this would create a situation in which the desktop contents appear for a split-second, before the user must enter his credentials, to continue with his Compiz session.
My own solution to this problem is, I have stopped running Compiz.
Now, some people have reported the problem, of not getting screen-savers to work with Compiz, such as the wonderful ‘xscreensaver’. To me, this seems obvious. When considering a Compiz session, there are two distinct drawing-environments for the output – and for the mouse and keyboard -inputs. The first drawing-environment would be the ‘real’, root window, that finally gets displayed on the monitor, as a result of hardware-rendering a 3D scene, essentially, even while that scene does not seem very 3-dimensional. And the second drawing-environment would be the one that user applications are meant to render their GUIs to, and which gets mapped to the faces of the desktop cube. Even though these faces act as the graphical output for arbitrary applications, they also act as textures for the hardware-rendering of the cube.
This type of rearrangement of the session is also why, any applications started before Compiz, will not be able to receive mouse- or keyboard- input, once Compiz has started. They are technically not on the same display.
If the user wanted to get ‘xscreensaver’ to work with Compiz, then he or she would also need to assure, that ‘xscreensaver’ is launched, before Compiz. And while that might sound easy, in fact it’s not, because Compiz is just one of the many applications that auto-start. Just because ‘C’ comes before ‘X’ alphabetically, Compiz will usually also auto-start, before ‘xscreensaver’ does.
The simplifying feature of ‘light-locker’ is that, because it’s associated with my particular log-in manager, ‘lightdm’, I can be sure that ‘light-locker’ is running in the same, root window, that ‘lightdm’ is running in, that is in the display-environment, preceding Compiz.
If the other user is very unlucky, then he or she might next discover, that ‘xscreensaver’ can no longer detect the use of the mouse or keyboard, that the session times out according to screen-saver-settings, and that the session no longer wakes up, even though the user seems to be obviously using the mouse or keyboard.