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

Simultaneous Update on Debian / Stretch Seems To Fix Wayland Bug, But An Effect Breaks.

This morning was one, on which most of my computers are receiving major system updates.

On the computer that acts as my Web-server, which I name ‘Phoenix’, this updated my Debian / Jessie version from 8.9 to 8.10.

On the computer which I most-recently installed, which I name ‘Plato’, this updated my Debian / Stretch version from 9.2 to 9.3 .

On both computers, this included a kernel-update. Additionally, it included an update, to the client-side X-server libraries. This posting has to do with the computer named ‘Plato’, which has kernel version ‘4.9.0-4-amd64′ now.

Previously I had blogged, that the computer named ‘Plato’ was suffering from a mysterious bug in its ‘Wayland’ compositor. If the compositing became suspended for any reason, after resuming, black rectangles would appear on the screen, as newly-opened windows faded in and out. This used to happen regardless of whether OpenGL 2 or OpenGL 3 compositing was being used.

Well since the update today, I tested the key-combination <Shift>+<Alt>+F12 again, which does the equivalent of sending the command to the compositor, to suspend. Apparently, the behavior of this key-combination has been changed since Debian / Jessie, so that instead of toggling, the compositing suspends for several seconds, and then automatically resumes. This would be useless as a user-feature, but can help with testing, because presumably, what an OpenGL application is supposed to do, is resend the signal every second or so, to make sure that compositing stays off.

To my pleasant surprise, I found that after compositing resumes, I no longer get black rectangles on the screen! :-)

Continue reading Simultaneous Update on Debian / Stretch Seems To Fix Wayland Bug, But An Effect Breaks.

There is a bug in the Wayland Compositor, under Debian Stretch.

One of the facts which I have written about before, is that modern desktop managers will use compositing – i.e. will use hardware-acceleration – to render desktop effects, specifically, when we are only running regular, 2D applications with a GUI. This feature exists with the old KDE 4, under Debian / Jessie, as well as with the new Plasma 5, under Debian / Stretch.

Under Debian / Jessie, this feature is extremely stable. Under Debian / Stretch, it is not yet so.

What will happen under Debian / Stretch, as far as I can make out, is that if an attempt has been made to disable compositing, instead of this succeeding, the desktop-session becomes corrupted, in that black rectangles will display, when we simply open multiple windows / dialogs. AFAICT, This can only be fixed, by rebooting / starting a new user-session.

I became aware of this, when running Steam-based games on the computer I name ‘Plato’. When games run that are heavy on OpenGL / Hardware-Rendering, it’s normal for the game-platform to try to switch compositing off, because often, the hardware-rendering of the game is not compatible with the desktop-compositing. After I have finished my session with Steam, the rendering errors in my desktop manager become noticeable, and Steam does not gain the permissions, to install any system software.

I do not blame this on Steam per se, because I can reproduce this problem by just clicking <Shift>+<Alt>+F12, which used to be the key-combination under KDE 4, that toggled desktop compositing on and off at will. Within seconds, under Plasma 5, this key-combination will also cause the malfunction.

(Updated 12/03/2017 : )

Now, there is a simplistic workaround for me:

 

Continue reading There is a bug in the Wayland Compositor, under Debian Stretch.