KDE 4.3.1 on Sun Ray

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.

ScreenshotThere’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.

13 thoughts on “KDE 4.3.1 on Sun Ray

    • Because each smart card speaks its own little protocol; I have understood from Bob Doolittle that it’s not *hard* to add support, just that Sun would need some documentation about the card (and possibly one to play with). It’s something I intend to address at some point, but it’s not very high priority, since the Fellows-with-a-Sun Ray market is not very big.

  1. The System Settings tooltip issue only occurs with some colour schemes, and should be corrected in trunk and branch. Unfortunately it missed 4.3.1

    • I thought it was a pretty obvious one myself, since it seemed to affect the default scheme for KDE 4.2 and 4.3, but at the same time I admit I never filed a bug about it — this again is one of those case of “I can’t tell whether this is a bug in the port or a bug in KDE”, and I’m glad that FreeBSD has passed OSOL by so I have a nice comparison system again.

      • … which is to say that FreeBSD delivers a really nice vanilla KDE experience, which is what we aim for on OSOL as well. So basically things should look the same on both systems.

  2. Antialiasing still does not seem to be working correctly. Wouldn’t a better idea be to compile Qt with the raster graphics engine as the default? That way rendering doesn’t have to be converted to xrender commands by Qt to just be rendered in cpu by a more general implementation. Instead, Qt’s raster is optimized for itself and so by using raster, you would bypass the middleman (xrender).

    • AA (I assume you mean font AA) is independent of the graphics engine; I wrote about fontconfig / libfreetype recently. It comes down to this, I’ve now found out: /usr/lib has one copy, and /usr/sfw/lib has another copy of libfreetype. GNOME uses the latter; we linked to the former. However, the former must be some ancient version or be otherwise broken, because it has no AA and the /usr/sfw/lib one does. So I’m now testing a patch to our Qt build to use the same freetype that GNOME does.

      • .. I should add that /usr/sfw/lib isn’t governed by any package that I can find, so it’s unclear whether there’s any sane way of depending on freetype being there.

    • If I remember correctly, using raster didn’t help one bit. I don’t know why. Maybe I blogged about it. I don’t much feel like producing different Qt libraries for local display and Sun Ray use — here’s where I really miss an environment variable to set the default graphics system.

  3. @Thomas:
    Using the software rasterizer for font rendering is a *BAD* idea when working with thin clients. Rendering on the CPU means that you have to send bitmaps over the network instead of line drawing instructions, which eat huge amounts of bandwidth.

    In the bad-but-not-worst-case scenario of scrolling one full screen (1280×1024) of text per second the difference is about 30 Mb/s, which is a huge chunk of a 100 Mb/s network…

  4. Looks great, but agree with above posters that the lack of Antialiasing detracts significantly from the overall aesthetics.

    If using the same freetype that GNOME does helps, more power to you!

  5. I guess I did not get something right here. Maybe somebody can enlighten me in this matter:

    I thought having a Thin client liek the Sun Ray virtual desktop client is all about executing the software on a remote server and then accessing this software from anywhere. So why should I install a full KDE4 on that client? Isn’t it suffice enough just to install a basic X or at least a basic KDE?

    If someone has the time to explain that to me, I would be glad 🙂

    • Yes, you’ve got it completely wrong 🙂 You install KDE 4.3.1 on the server — some crunchy Solaris or Linux box in the network. The Sun Ray DTU displays a session that runs entirely on the server. However, the DTU needs to support what the applications are doing — in terms of what they do with X — in order to display nicely. So that’s why “on Sun Ray” is different from “on local display”.