## Understanding The Intricacies Of KDE Logic

In This Posting, I was describing a problem with my Linux laptop named ‘Klystron’, in which the laptop would take itself off my WiFi, apparently every time I closed the lid.

In the short term, there was a solution to this problem. I was able to go into my KDE Power Management Settings, where I had set the action on closing the lid to “Lock Screen”, and I was able to change this setting to “Do Nothing”. The suspicion had never occurred to me, that there could be two distinct behaviors:

1) After (x) minutes, the screensaver can come on, and if the attempt is made to interrupt the screensaver after (y) additional seconds, that screensaver can ask the user for his password.

2) The user can ask KDE to “Lock The Screen”.

According to the way KDE works, (1) and (2) are as different as Night and Day. So apparently, Locking The Screen is also supposed to mean, Disconnect From WiFi. But the screensaver asking the user for his password to stop, does not mean Disconnecting The WiFi.

Live and Learn.

And actually, one main reason for which I do close the lid usually, is the fact that the laptop is more protected from dust etc., with the lid closed.

Dirk

(Edit : ) This laptop setup uses Network Manager. So just this afternoon I left-clicked on the Network Manager icon while connected to my home WiFi, and then drilled deeper into its GUI, to adjust which settings would be displayed as additional information about the network I am connected to. Network Manager is somewhat flexible in this GUI layout adjustment, but does not really allow settings to be fine-tuned in the same way.

Some KDE setups use ‘WICD‘ instead of ‘Network manager‘.

What I saw, was that there was no specific parameter to display, for whether a WiFi network should disconnect, on locking the desktop.

The only relevant WiFi-related detail I was able to add to the display, was “WiFi Band”, which could plausibly have complemented “WiFi Security”, which was already included. For my home access point, WiFi Band now displays “b/g“, as a result of further troubleshooting steps of mine.

I have since disabled 802.11n from the kernel module…

This means in practice, according to my logic, that the behavior I described in this posting, of cutting out when I close the laptop lid, cannot be deliberate. If it was deliberate, it would also be something which can be configured differently. And thus, this can also not be due to any translation error.

Therefore, this is a bug, and one I can now reproduce any time I want to.

## I have now chosen against keeping the desktop cube animations.

In This Posting, I wrote that I had enabled a ‘desktop cube’, a compositing effect, on the laptop I name ‘Klystron’. In fact, this KDE effect consisted of two separate effects, the ‘Desktop Cube’, and the ‘Cube Animation’, which look very similar to each other.

Since then, I have discovered that enabling this much compositing (1) prevents me from turning compositing off quickly, with <Alt>+<Shift>+F12, and (2) prevents the screensavers from activating, reducing my screen locking capability to a simple screen locker.

It did not result in any crashes or errors, but presumably to prevent such errors, KDE just did not launch the screensaver.

So even though I felt that it was fun for a while to have these effects enabled, they added rather little to the functionality. I am in favor of using compositing, to whatever extent doing so causes the GPU to take work off the hands of the CPU. But after that, once increased use of these effects interferes in any way with the reliability of the S/W, I will choose against further increases.

And so now I have reversed these desktop effect settings, and gotten my screensaver back.

However, I also double-checked what I had run in to in This Posting, to see whether the GL 3+ Render System now works, belonging to OGRE 1.10 . And alas, the behavior of the OGRE GL 3+ Render System is unchanged. I did not push it to a full crash, but read the debug output again, before it came to that.

Dirk

(Edit 4/24/2016 : ) This behavior, of not having a screensaver, was logical. With the Desktop Cube effect, the usual KDE output was being rendered to 4 of the faces of a cube, defined as target texture images in OpenGL (Render To Texture, ‘RTT’). This cube was then rendered as a 3D Entity, to the actual screen displayed.

This 3D scene poses the question, of where the screensaver should be inserted. In theory, it would have been possible for the KDE screensaver to be rendered to each of these 4 active cube faces, but not to the actual screen, that acted as the virtual camera position. A simple lock-screen was rendered there.

This was similar, to how the KDE wallpaper was also potentially different, from the Desktop Cube, effect wallpaper. With this effect, there is the standard KDE wallpaper which is seen on each of the active cube faces, which is different from the wallpaper one might choose for the whole scene.

It is a good thing, that the developers added as default behavior, to offer a regular lock screen for the display, when the real screensaver was running, and potentially rendering its animation to 4 of the faces of the cube. Because in the latter place, that screen saver would also have been failing to lock the display.

And one of the behaviors which I have read about, state that there can be problems on some computers, to go into and out of Suspend Mode, if there is active 3D rendering (on the GPU) taking place in the background. A Desktop Cube would be an example, where a 3D rendering pipeline has been inserted, in such a way that it is not removed or deactivated, when the effect seems passive, or when we try to put the laptop into Suspend Mode.

This has sometimes resulted in crashes, because the graphics driver was not up to the Debian version of Suspend Mode, or even because the Index Buffer of the GPU contained garbled data, because the VRAM of the GPU was losing power, in Debian Suspend Mode.

## Desktop Compositing on ‘Klystron’

Since I installed ‘Kanotix / Spitfire’ on my Hewlett-Packard laptop, which I now name ‘Klystron’, I have enabled OpenGL 3.1 Desktop Compositing as part of its Desktop Effects. Kanotix has generally been based on KDE, which is a high-powered desktop manager under Debian / Linux, and has always bundled this as a build with the standard ‘KWin’ desktop manager.

I know that as an alternative to KWin, it would be possible to have a Debian system that has ‘Compiz’. But Compiz really breaks things. Compiz is also the Desktop Compositor that offers windows which flame when they are closed, and many effects that are much fancier than what I currently have.

But if the user selects OpenGL 3.1 Desktop Compositing with KWin and KDE, we generally obtain the “Wayland Compositor”, and one effect which is already offered, is that of 4 virtual desktops forming the faces of a virtual, 3D cube that rotates, with the windows on each virtual desktop potentially standing out in front of each cube face, and offering translucency, as the user specifies.

I have always wanted to have that, while I feel that fancy effects for closing windows represent distractions instead. So the rotating desktop-cube seems just fine for me.

The windows which explode when closed are an effect that works fine on my machine, and that I believe also uses a Geometry Shader.

And then, the fact that this configuration is stable, presents me with another reason, to stay with the graphics drivers that I currently have selected. Because if I was to switch to the ‘fglrx’ drivers, conversely, I might make unstable, what was stable.

Dirk

## Stabilizing my Realtek rtl8723be WiFi card under Linux.

The laptop of mine onto which I newly installed Kanotix / Spitfire, and that is named ‘Klystron’, happens to have a Realtek rtl8723be WiFi chip-set, which is known to have stability issues under Linux. I found that recently my own experience also ran into these issues.

If you feel that you are also having these issues, it is important that you first check, whether in fact you have the WiFi card in question. This can be done via an ‘lspci‘ command, or with


lsmod | grep rtl8723



I felt that I needed to apply a two-prong solution to my own problem.

The first thing which I did, was to create a file named


/etc/modprobe.d/rtl8723be.conf



The only content of which was the line


options rtl8723be fwlps=0 swlps=0



This solution may solve the problem, of the WiFi dropping the connection, after periods of idle time.

There is something to watch out for. There are some sources on the Web, which state that we should try  the configuration line


options rtl8723be fwlps=N swlps=N



The problem with this method is, that for certain uses in programming, in particular in the language C, which is used for kernel modules, a numeric value may be expected in place of a Boolean value, and if in this case the module sees an ‘N’, this value will not be equal to zero, because the ASCII code for ‘N’ is not zero, and any other value than zero is taken to be True! So to make sure that the kernel module registers False, we need to put a ‘0’.

But I found that a second issue was affecting me, which was the fact that this WiFi setup has IPv6 enabled, but that my router does not tolerate IPv6. This may have been causing my laptop to get dropped from the WiFi, even as I was downloading software. In my dhcp configuration, I have added the DNS Server 8.8.8.8, which is the free Google DNS server, in addition to the auto-detected server. But 8.8.8.8 will offer the system an IPv6 resolution of a domain name along with an IPv4 resolution, and in the case of WiFi, apparently Linux will use the IPv6, without detecting that this ability was not assigned by the Access Point.

And so I felt that I also needed to disable IPv6 system-wide on this laptop. The way to do that was to add the following lines to the file ‘/etc/sysctl.conf‘:


net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1



And then ‘sysctl -p‘. After that, I also did


update-initramfs -u



This is a very sticky issue, in which different users have reported, that some of these solutions either do or do not work for them. One reason may be, that users are in fact reporting different issues without knowing it. I cannot be sure that this solution will remain 100% effective for myself, let alone for the reader. I just wanted to share my own experience with this. So far, my WiFi chipset is stable again.

(Edit 04/12/2016 : ) Just to prove to you, how uncertain the state of that WiFi chip-set is, even though I did change the parameters fed into this kernel module, it still happens that when I leave that laptop idling overnight, its WiFi goes into suspend mode. This happens in a way which the applications usually do not see, so that those applications still think they’re connected. However, my ‘Pidgin’ IRC Client gets disconnected.

And then, when I resume my session, ‘Pidgin’, which uses a ping timeout, did realize it was disconnected, and just reconnects seamlessly. And this latter part seems to happen, directly after I unlock my screen-saver, which seems to suggest that this is not being introduced by the Kernel Module, but rather by KDE, etc. I suppose it might introduce some level of confusion into the software, if the Kernel Module was to provide the same function again.

So who knows, which of my problems – if any – I may really have fixed?

Just checking my package manager, I see that ‘Pidgin’ has an available ‘Away-On-Lock’ plugin, which was not installed. Just this evening I installed and activated that, just to see whether I can override a behavior, which might have been set erroneously to ‘Offline-On-Lock’, while the plugin was not installed… By tomorrow, I should know.

Dirk