The laptop ‘Klystron’ suspends to RAM half-decently.

One subject which I have written a lot about, was that as soon as I close the lid of the laptop I name ‘Klystron’, it seems to lose its WiFi signal, and that that can get in the way of comfortable use, because to close the lid also helps shield the keyboard of dust etc..

This Linux laptop boots decently fast, and yet is still a hassle to reboot very often. And so I needed to come up with a different way of solving my problem, on a practical level. My solution for now, is to tell the laptop to Suspend To RAM, as soon as I close the lid. That way, the WiFi signal is gone more properly, and when the laptop resumes its session, the scripts that govern this behavior also re-initialize the WiFi chipset and its status on my LAN. This causes less confusion with running Samba servers etc., on my other computers.

There is a bit of terminology, which I do not think that the whole population understands, but which I think that people are simply using differently from how it was used in my past.

It used to be, that under Linux, we had ‘Suspend To RAM’ and ‘Suspend To Disk’. In the Windows world, these terms corresponded to ‘Standby’ and ‘Hibernate’ respectively. Well in the terminology today, they stand for ‘Sleep’ and ‘Hibernate’, borrowing those terms from mobile devices.

There are two types of Suspend working in any case.

In past days of Linux, we could not cause a laptop just to Hibernate. We needed to install special packages and modify the Grand Unified Bootloader, before we could even Suspend To Disk. Suspending To RAM used to be less reliable. Well one development with modern Linux which I welcome, among many, is the fact that Sleep and Hibernate should, in most cases, work out-of-the-box.

I just tried Sleep mode tonight, and it works 90%.

One oddity: When we Resume, on this laptop, the message is displayed on the screen numerous times, of a CPU Error. But after a few seconds of CPU errors, apparently the session is restored without corruption. Given that I have 300 (+) processes, I cannot be 100% sure that the Restore is perfectly without corruption. But I am reasonably sure, with one exception:

The second oddity is of greater relevance. After Waking Up, the clock of the laptop seems to be displaced 2 days and a certain number of hours into the future. This bug has been observed on some other devices, and I needed to add a script to the configuration files as a workaround, which simply sets the system clock back that many days and that many hours, after Waking. Thankfully, I believe that doing so, was as much of a workaround as was needed.

One side-effect of not having done so, before being aware of the problem, was that the ‘KNotify’ alarms for the next two days have also all sounded, so that it will take another two days, before personal organizer – PIM – notifications may sound for me again.

The fact that numerous CPU errors are displayed bothers me not. What that means, is that the way the CPU goes to sleep, and then wakes up, involves power-cycling in ways that do not guarantee the integrity of data throughout. But it would seem that good programming of the kernel does provide data integrity, with the exception of the system clock issue.

But the fact that the hardware is a bit testy when using the Linux version of Sleep, also suggests that maybe this is also the kind of laptop that powers down its VRAM. It is a good thing then, that I disabled the advanced compositing effects, that involve vertex arrays.


 

There is a side-note on the desktop cube animation I wanted to make.

In general, when raster-rendering a complex scene with models, each model is defined by a vertex array, an index array, one or more texture images etc., and the vertex array stores the model geometry statically, as relative to the coordinate-origin of the model. Then, a model-view-projection matrix is applied – or just a rotation matrix for the normal vectors – to position it with respect to the screen. Moving the models is then a question of the CPU updating the model-view matrix only.

Well when a desktop cube animation is the only model in the scene, as part of compositing, I think that the way in which this is managed differs slightly. I think that what happens here, is that instead of the cube having vertex coordinates of +/- 1 all the time, the model-view matrix is kept as an identity matrix.

Instead, the actual vertex data is rewritten to the vertex array, to reposition the vertices with respect to the view.

Why is this significant? Well, if it was true that Suspending the session To RAM also cut power to the VRAM, it would be useful to know, which types of data stored therein will seem corrupted after a resume, and which will not.

Technically, texture images can also get garbled. But if all it takes is one frame cycle for texture images to get refreshed, the net result is that the displayed desktop will look normal again, by the time the user unlocks it.

Similarly, if the vertex array of the only model is being rewritten by the CPU, doing so will also rewrite the header information in the vertex array, that tells the GPU how many vertices there are, as well as rewriting the normal vectors, as when they are a part of any normal vertex animation, etc.. So anything resulting from the vertex array should still not look corrupted.

But one element which generally does not get rewritten, is the index array. The index array states in its header information, whether the array is a point list, a line list, a triangle list, a line strip, a triangle strip… It then states how many primitives exist, for the GPU to draw. And then it states sets of elements, each of which is a vertex number.

The only theoretical reason fw the CPU would rewrite that, would be if the topology of the model was to change, which is as good as never in practice. And so, if the VRAM gets garbled, what was stored in the index array would get lost – and not refreshed.

And this can lead to the view, of numerous nonsensical triangles on the screen, which many of us have learned to associated with a GPU crash.

 

Dirk

 

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