Bobulate

It’s been ages since I wrote (or complained) about Sun Ray Server Software (SRSS) on OpenSolaris in combination with KDE4. That was because I wasn’t using it and my Sun Ray terminal sat idle. But a bit of house-rearranging has made the device useful again, and I spent an hour futzing with it today to get things working again.

SRSS is a bit complicated — it’s officially delivered only for Solaris 10 and it exists separately from the client devices, so just because you have a Sun Ray doesn’t mean you can do anything with it. Certainly there’s issues on OpenSolaris (or OpenIndiana). I seem to have 4.2 running — it’s a bit unclear whether there’s a version 5 available, and last time I blogged about SRSS it was enthusing about the new addition of Porter-Duff compositing, which made the Plasma Desktop beautiful on the thin client again.

A good official(-ish?) source of information on SRSS is the sun-rays.org wiki which has a section on getting this stuff to work on OSOL as well. Plus notes for build 134 or later, which is what KDE4 requires. Two blog entries I found very helpful were Chris Gerhard about build 130 and later and the Grey Blog on 2009.06. Both point out some tweaking that’s needed to get gdm to like the thin client — otherwise it starts on the thin client and stops about 60 milliseconds later.

After adding the requires symlinks and font paths, gdm starts up normally.

From there, I can now display KDE4 on my FullHD TV downstairs while the server hums gently in the attic. It’s nice to be able to move around in the house and have the desktop available everywhere. Session resume is also supported, so if I switch off the Sun Ray and switch on again later, my desktop is there.

Another benefit of having a desktop available in the living room is that it enables pair programming when random developers stop over, but that’s a topic for another time.

The Sun Ray thin client is a nifty piece of hardware, especially when it’s painted with a KDE Oxygen logo. It’s a thin client with USB forwarding and sound and session management and smartcard support (but it does not support the FSFE’s Fellowship smartcard). You can put the roughly the same thing together with Free Software, starting with LTSP, but I’ve been a fan of this largely-hardware solution for years. Unfortunately, it has been a poor platform for KDE4 — I’ve blogged about this in the past.

Until now.

There’s new Sun Ray server 5 coming up, and one of the features it has is Xrender (finally!). You need to enable it after installation and there are warnings about performance, but with a small deployment things should be just fine. I deployed it on my desk, with a single DTU with a single 1280×1024 monitor attached, running on an amd64 X2 with 6GB of RAM. Crunchy, but then again I was also building KDEtoys and KDEpim in parallel on it alongside a local GNOME session and a KDE 4.3.1 session on the Sun Ray.

Wait, 4.3.1? Wasn’t it just yesterday that I posted about the availability of KDE 4.3.0 on OpenSolaris? Yes, true. Bumping KDE up one minor revision did not take all that long, although I had to bump Akonadi to 1.2.0 in the process.

We use the gstreamer backend for Phonon on OpenSolaris, because gstreamer is installed anyway — or maybe it’s the Sun native audio backend? I don’t know and I don’t even know how to check. Suffice to say that whatever the default build picked out, sound works. Now, that might not be all that impressive at first thought, but that means that the thin client is receiving whatever audio output KDE is generating. I have not tried Amarok yet (that port needs a little more work still) on OpenSolaris, but that offers new realms of network-transparent desktop use.

The performance work done in Plasma over the past release cycle(s) has been impressive, and it just feels much snappier; Plasmoid handles show up like they should. This is a world of difference with my old laptop and KDE 4.1 which I was not-exactly-showing-off in London last year. Kudos to the Plasma team (and I’m truly looking forward to the results of Tokamak 3). The screenshot here is KDE 4.3.1 running on a Sun Ray, with whatever theme and decoration I ended up with while fiddling around (although Fluffy Bunny is listed in the “Get themes” widget, it doesn’t seem to work). There is a rendering issue with the text in systemsettings, where white-on-white isn’t all that useful, but on the whole it seems to work well enough graphically. A quick test using qgears gets 20fps on the Sun Ray, versus 30fps on the local display of the same machine (Radeon X1200).

There are some functional bugs, though. Many applications do not start up from the K menu, although they do start from the command line (and they do start up if I log in on a local display instead of the Sun Ray). Konqueror takes forever and a day to start or respond to keypresses — this is not production ready, but it is debug-ready, for anyone with a DTrace hammer. There’s a good chance, actually, that the issues are all related to threading problems deep within the C++ libraries. I know there are some newer patches available for it, and I think the library has been fully integrated into Solaris Nevada as of this week (presumably with those patches), which will make our own packaging of those C++ libraries superfluous. Hunting these issues down and integrating some feature work for OpenSolaris will be the KDE4-OpenSolaris team’s focus for the coming release cycle. It’s coming closer.

Time for a collection of screenshots, as an illustration of Qt applications on OpenSolaris, both on a local display driven by a Radeon X1200 and on a Sun Ray thin client. Not from KDE applications (although we have KDE 4.3.0 packages for OpenSolaris now) but from qtconfig — possibly the first Qt app you will want to run in OpenSolaris to set up some of the fonts correctly. Before running this version of qtconfig, I removed ~/.config — the whole directory tree — so I would get the default settings. There are screenies of the same 300×100 section of the application on four setups: local display or Sun Ray thin client, and system fontconfig or one built from our own packages. I switched my set of package builds to use the system’s fontconfig a while back, but the specfile for fontconfig (useful if you care about Solaris10) is still there. Both are version 2.5.0; for freetype system is 2.3.7 and the specfiles build 2.3.6.

So you would expect very little difference between the two, possibly only a difference in the default fonts. You could use some kind of png diff tool to see the differences, but it’s not a whole heck of a lot.

A bigger change happens when you switch from a local display (even a lousy onboard X1200) to a Sun Ray thin client display. I know I’ve ragged on parts of Qt in the past and the way KDE deals with less-capable displays, so this time I’m not going anywhere near graphics views.

What strikes me immediately is that the style has changed, from one display to another; it now looks a good deal more Morif like. Eww! So what is Qt looking at here to change style like that? (That’s a lazyweb question).

And switching fontconfigs doesn’t do much again. I’m actually curious if either of the fontconfigs does anti-aliasing right now.

One thing you can’t see in the screenie is the window titlebar. Whatever the default GNOME window manager is — metacity? — produces really ugly title bars on a Sun Ray, as it looks like the AA falls over, producing hard-to-read letters with white-ish strips between them. Those are screenies for another day.

We have the technology, we can fix it. The nice thing about showing people things that are broken and then sitting down to figure out what’s wrong is that the things get fixed. Holger helped out with understanding some of the rendering issues on the Sun Ray server, we tracked down some more suitable default themes (but there’s so many cool themes out there it’s hard to find a boring flat one), pushed graphicssystem RASTER into startkde, and ended up with a KDE4 that looks like this. Thin client heaven? I think not, but it’s a little better than when it started. Just a wee bit, though, even something totally flat like Heron (wish list: semantic tagging of plasma themes so I can search for “flat and boring”) totally borks the plasma panel.

Aaron was, probably rightly so, kind of annoyed with my cheap shot about ugliness on feature-limited X servers.

Still, it’s important to flag the problems, show them to people. The cheapness was more related to me complaining to the wrong people, but now at GCDS I could show them to the Sun Ray folks — and I’m very happy to have met Bob, Brian, Ken (?) and others from Sun — and collect information. It looks mostly like Qt has two problems: the fallback for non-porter-duff compositing is not very nice, and BGR colormaps are not supported. That’s the guesses from the Sun folk and they sound plausible enough — I’ll be trying them out when I get back home and can spend an evening re-compiling Qt all the time (instead of like here at GCDS where the evenings are for discussion and food).

.. and then we can fix it.