The new GTK-VNC 0.3.3 release was made available over the weekend. This was primarily a bug fix release dealing with yet more UltraVNC compatability issues, a few crash scenarios, improved key-state tracking to deal with annoying GTK behaviour where it fails to send you ‘release’ events during key-repeat, and ability to reset modifier state when the widget looses focus to avoid the server thinking Alt/Ctrl are stuck ‘on’.
We also have an EXPERIMENTAL web browser plugin for firefox. Before you go and install this, remember I’m saying this is EXPERIMENTAL. We’re not recommending anyone use this outside the lab yet because there needs to be a proper security audit of our protocol handling, and some more thought about how plugin security should work. Needless to say the build is disabled by default for now.
More interestingly though, is that the dev tree of GTK-VNC now has support for scaling the VNC display. We didn’t fancy writing pixmap scaling code, so for this we’re integrating with GtkGExt and OpenGL to get hardware accelerated scaling. The performance is pretty decent – Anthony tells me he’s been able to watch a DVD over VNC with scaling active. Sadly I’m stuck with the non-accelerated radeon driver in my laptop for now, so CPU usage is considerable. Still, its nice to be able to go “full screen” and have it use all screen real estate even when the remote desktop resolution doesn’t match the local desktop resolution.
Things have been progressing well with the GTK-VNC widget. The 0.3.0 release a few weeks back fixed a couple of co-routine race conditions, fixed portability to Solaris and added compatability for UltraVNC brokenness – it claims support for RFB version 3.4 which doesn’t technically exist. 0.3.1 was a brown paper bag release a day later, due to the ‘make dist’ process going wrong with 0.3.0; say no more. Today Anthony released version 0.3.2 which adds a GThread based co-routine implementation to provide portability to platforms lacking ucontext support (yes I’m looking at you Windows/cygwin). It also adds support for the RRE server encoding which is a zlib compressed format, although not commonly used its in the spec so its worth supporting.
For the next releases we’ll have support for the Tight encoding as used by TightVNC – this is a more advanced variant on RRE, in some cases using JPEG as its compression method which is interesting. We’re also in communication with the VMWare team to see if we can write code to support the RFB extensions, for which they recently got official extension numbers assigned. We decided to apply the ‘release early, release often’ mentality with earnest, and thus we’re aiming to have regular monthly releases for the forseeable future. Meanwhile John is continuing to develop Vinagre, a long overdue modern VNC client taking full advantage of the GNOME infrastructure & desktop integration points.
In his recent blog posting on redirected direct renderering, Kristian happened to mention Clutter, a toolkit which allows you to do 3d graphics without first needing to acquire a PhD in OpenGL. I made a mental note to give it a try sometime.
On saturday I spent a few hours doing the major upgrade from Fedora 6 to Fedora 8 on my laptop & desktop (skipping F7). I did it the crazy way, just changing my YUM config files & letting it upgrade everything. I can’t say it was a painless process, but I do finally have two working boxes on F8 now. I also took the opportunity to switch my IBM T60p laptop over to the Avivo driver, instead of the VESA driver & which worked without a hitch.
Back on topic. After the upgrade to F8, I poked at the repos and found that (nearly) all the Clutter related bits are packaged & available to Fedora users already. There is just an annoying buildrequires missing in the python bindings spec file, which meant the RPM is missing the GTK & GST APIs for clutter. A quick rebuild fixed that issue. You may remember I’ve been working on a GTK widget for displayed VNC sessions. One evil thought, led to another even more evil thought, and thus I ended up writing a VNC viewer program which displays multiple VNC sessions on a spinning cube. To make it even more evil, I decided to not restrict it to a cube, and instead generalized to an arbitrary number of sides.
The results are spectacular, though a static screenshot doesn’t really do it justice…
Ctrl+Alt+PageUp/PageDown lets you rotate to the previous/next session respectively. The mouse & keyboard events are fully plumbed in so you can actually interact with each session. In this example I just started 6 VNC server instances running TWM at 500×500 pixels, but they could have been real GNOME desktops too. The only issue is that I’ve not yet figured out how todo correct depth sorting of each desktops. You don’t notice this problem in the screenshot, since I’ve just got them all rendering at 50% opacity ;-) It is impressively slow & impressively fast at the same time. Slow because I’m using Avivo which doesn’t have any real 3d rendering support yet; fast because I’m amazed it is actually working at all :-)
Now to hook this all up into the next version of virt-manager….. just kidding ;-P
I’ve got many boxes for testing purposes and while often I can run graphical apps over SSH, every so often I really do need to run the app within a full GNOME session. For example, the incredible new PolicyKit app in Fedora 8 enables desktop applications to authenticate to gain extra privileges. PolicyKit uses ConsoleKit for its session tracking & the ConsoleKit sessions are created by GDM when you initially login. Thus to test an application using PolicyKit you really do need to login via GDM and run a full GNOME session, not merely a X tunnel over SSH.
Now of course the critical times when I need to do this testing are when I’m not physically anywhere near the machine I need to test on. And invariably I’ve not left a login session active, nor even GNOME’s ‘remote desktop’ access enabled. Traditionally I’ve just created a suitable VNC server startup file containing
$ cat $HOME/.vnc/xstartup
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
eval `dbus-launch --sh-syntax --exit-with-session`
This gets me a full GNOME login session. Unfortunately there’s no ConsoleKit session associated with this & thus no possibility of using PolicyKit. GNOME itself though does come with VINO which can export your regular X session using the VNC protocol. If only I were logged into X on the machine’s console & running VINO. Argh.
After much poking around I finally figured out a solution. First off, SSH to the box in question as your regular desktop user. Now we can use gconftool-2 to enable VINO. We need to enable it, enable authentication, set a password, turn off incoming connection prompts and possibily set an explicit port (if you have something else on the regular port 5900 – eg a Xen guest).
# Disable local confirmation dialog for incoming connections
gconftool-2 --type bool --set /desktop/gnome/remote_access/prompt_enabled false
# Change VNC port to :9 instead of :0
gconftool-2 --type bool --set /desktop/gnome/remote_access/use_alternative_port true
gconftool-2 --type int --set /desktop/gnome/remote_access/alternative_port 5909
# Enable password auth
gconftool-2 --type list --list-type string --set /desktop/gnome/remote_access/authentication_methods '[vnc]'
PW=`echo 'mypassword' | base64`
gconftool-2 --type string --set /desktop/gnome/remote_access/vnc_password $PW
# Enable the VINO server
gconftool-2 --type bool --set /desktop/gnome/remote_access/enabled true
So that has the VINO server configured to run when I’m logged in, but as I mentioned already – I’m typically not logged in on the console when I need to be. For this challenge GDM comes to the rescue. It is possible change its config file to specify that a particular user will be automatically logged in the moment GDM starts. To do this edit /etc/gdm/custom.conf and add
A quick restart of GDM later, and I’m automatically logged into the remote box with a full GNOME session, including all the neccessary ConsoleKit magic. I can now connect with VNC and properly test virt-manager / PolicyKit integration. Yay.