The Roku Remote

I feel like I might want to add some constructive criticism, about the new playback device, of which I just bought one, as described in this posting.

The designers have made some progressive statements in how they designed this hardware, that range from only taking up circuit-board space with modern, HDMI output, to designing a novel remote-control. I think that although I like many of the concepts that wen into the remote, there is some room for improvement.

This remote has a headphone-jack, so that we do not need to plug any headphones into our TV or into our stationary devices, which may be located on the other side of the living room, from where we sit. The first thing I would typically test about that, is whether the sound from the TV actually does mute, when we plug in headphones. And in fact, this works as it should.

That headphone jack came bundled with headphones for me to use, right out-of-the-box. I suppose this comment might seem petty, considering that this is a standard jack, into which I could plug an any headphones I supply. But in the included headphones, the Right ear-piece could be labeled more clearly, to distinguish it from the Left ear-piece. They look nearly identical, and the tiny ‘R’ stamped into the Right piece, might be hard for people to read, whose vision is not 100%.

Okay, but now I am done with the trivial details.

The remote has 4 pre-assigned buttons, for 4 possible channels, which the designers felt that their users would want to visit most-frequently. Netflix is one of them, but there are 3 more. These buttons save us the possible hassle, of navigating a menu, to the channel we want to view most-frequently.

The problem with this is, that depending on what a certain user prefers, the other 3 channels might not be set up. They are, as usual, free to install, but then we need to enter the log-in information into our , to connect to each of the accounts. What if we do not have these accounts? For example, ‘‘ was randomly chosen to deserve a button on its own, and yet I would find it impractical to set up a account, to use for the duration.

Continue reading The Roku Remote

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.