Planet Closed Fist

December 05, 2014

Damien Lespiau

Working in a separate prefix

I’ve been surprised in the past to discover that even some seasoned engineers didn’t know how to use the autotools prefix feature. A sign they’ve been lucky enough and didn’t have to deal with Autotools too much. Here’s my attempt to provide some introduction to ./configure --prefix.

Working with or in “a separate prefix” is working with libraries and binaries (well, anything produced by ‘make install‘ in an autotooled project really) installed in a different directory than the system-wide ones (/usr or even /usr/local that can become quite messy). It is the preferred way to hack on a full stack without polluting your base distribution and has several advantages:

  • One can hack on the whole stack without the fear of not being able to run your desktop environment you’re working with if something goes wrong,
  • More often than not, one needs a relatively recent library that your distribution doesn’t ship with (say a recent libdrm). When working with the dependencies in a prefix, it’s just a matter of recompiling it.

Let’s take an example to make the discussion easier:

      •  We want to compile libdrm and intel-gpu-tools (because intel-gpu-needs needs a more recent libdrm than the one coming with your distribution),
      •  We want to use the ~/gfx directory for our work,
      • git trees with be cloned in ~/gfx/sources,
      • ~/gfx/install is chosen as the prefix.

First, let’s clone the needed git repositories:

$ mkdir -p ~/gfx/sources ~/gfx/install
$ cd ~/gfx/sources
$ git clone git:// libdrm
$ git clone git://

Then you need to source a script that will set-up your environment with a few variables to tell the system to use the prefix (both at run-time and compile-time). A minimal version of that script for our example is (I store my per-project setup scripts to source at the root of the project, in our case ~/gfx):

$ cat ~/gfx/setup-env
export PATH=$PROJECT/install/bin:$PATH
export PKG_CONFIG_PATH=$PROJECT/install/lib/pkgconfig:$PKG_CONFIG_PATH
export ACLOCAL_FLAGS="-I $PROJECT/install/share/aclocal $ACLOCAL_FLAG"

$ source ~/gfx/setup-env

Then it’s time to compile libdrm, telling the configure script that we want to install it in in our prefix:

$ cd ~/gfx/sources/libdrm
$ ./ --prefix=/home/damien/gfx/install
$ make
$ make install

Note that you don’t need to run “sudo make install” since we’ll be installing in our prefix directory that is writeable by the current user.

Now it’s time to compile i-g-t:

$ cd ~/gfx/sources/intel-gpu-tools
$ ./ --prefix=/home/damien/gfx/install
$ make
$ make install

The configure script may complain about dependencies (eg. cairo, SWIG,…). Different ways to solve those:

    • For dependencies not directly linked with the graphics stack (like SWIG), it’s recommended to use the development package provided by the distribution
    • For old enough dependencies that don’t change very often (like cairo) you can use the distribution development package or compile them in your prefix
    • For dependencies more recent than your distribution ones, you need to install them in the chosen prefix.

by damien at December 05, 2014 06:00 PM

November 19, 2014

Richard Purdie

Laugh or cry?

I think by now people realise there is some “fatigue” thing going on with me.

I spent a couple of evenings last week doing strenuous wall paper stripping (woodchip), to the point I was trembling when I took breaks. On Saturday I took my new cyclocross bicycle for an 18 mile ride, I’ve been talking about buying one for years so I was determined to try it while the weather was good. Compared to my previous 40 year old bicycle with non-indexed gears and ineffective brakes, its a complete revelation and I love it. There is an 10 mile “time trial” section on the route I picked, Nov 2013 I was doing ~45 mins, Nov 2014 on the old bike, ~39 mins, on the new one, under 34 mins. I was pleasantly surprised!

I spent the weekend in a bit of a daze induced by the exercise which is par for the course, I’m used to that along with the muscle aches.

On Monday night, I became extremely cold and shivery with the “flu” aches and pains and basically didn’t sleep, oddly wide awake yet more unwell than I’ve ever been with proper flu. There were no respiratory or digestive symptoms. It could be a virus although the pattern of flu like symptoms 36-48 hours after exertion with varying intensity makes me lets say suspicious.

The medical profession? They basically don’t have a clue what is going on :( . Lots of tests up to and including muscle biopsy and some interesting results (like spinal nerve damage I seemingly recovered from?!) but nothing which explains it.

There seems to be a finite amount I can do, if I exceed that, there is a price to pay. I still feel horrible 24 hours on, nowhere near as bad as I did but still “not good”, sitting wearing half my wardrobe to keep warm (trail riding base layers are wonderful). I have no idea which events to commit to and need to be careful about being in a fit state for things. On the plus side, the price comes later, not during activity and I guess I have some handle on the pattern. Its also always been there I think, I’ve just tried to be more active/fit and provoked it.

So really, I don’t know whether to laugh or cry :/. If you see me having disappeared a bit from some things, this is why though.

by Richard at November 19, 2014 12:23 PM

October 09, 2014

Hylke Bons

A bit about taking pictures

Though I like going out and take pictures at the places I visit, I haven’t actually blogged about taking pictures before. I thought I should share some tips and experiences.

This is not a “What’s in my bag” kind of post. I won’t, and can’t, tell you what the best cameras or lenses are. I simply don’t know. These are some things I’ve learnt and that have worked for me and my style of taking pictures, and wish I knew earlier on.


Keep gear light and compact, and focus on what you have. You will often bring more than you need. If you get the basics sorted out, you don’t need much to take a good picture. Identify a couple of lenses you like using and get to know their qualities and limits.

Your big lenses aren’t going to do you any good if you’re reluctant to take them with you. Accept that your stuff is going to take a beating. I used to obsess over scratches on my gear, I don’t anymore.

I don’t keep a special bag. I wrap my camera in a hat or hoody and lenses in thick socks and toss them into my rucksack. (Actually, this is one tip you might want to ignore.)

Watch out for gear creep. It’s tempting to wait until that new lens comes out and get it. Ask yourself: will this make me go out and shoot more? The answer usually is probably not, and the money is often better spent on that trip to take those nice shots with the stuff you already have.


Try some old manual lenses to learn with. Not only are these cheap and able to produce excellent image quality, it’s a great way to learn how aperture, shutter speed, and sensitivity affect exposure. Essential for getting the results you want.

I only started understanding this after having inherited some old lenses and started playing around with them. The fact they’re all manual makes you realise quicker how things physically change inside the camera when you modify a setting, compared to looking at abstract numbers on the back of the screen. I find them much more engaging and fun to use compared to full automatic lenses.

You can get M42 lens adapters for almost any camera type, but they work specially well with mirrorless cameras. Here’s a list of the Asahi Takumar (old Pentax) series of lenses, which has some gems. You can pick them up off eBay for just a few tenners.

My favourites are the SMC 55mm f/1.8 and SMC 50mm f/1.4. They produce lovely creamy bokeh and great sharpness of in focus at the same time.


A nice side effect of having a camera on you is that you look at the world differently. Crouch. Climb on things. Lean against walls. Get unique points of view (but be careful!). Annoy your friends because you need to take a bit more time photographing that beetle.

Some shots you take might be considered dumb luck. However, it’s up to you to increase your chances of “being lucky”. You might get lucky wandering around through that park, but you know you certainly won’t be when you just sit at home reading the web about camera performance.

Don’t worry about the execution too much. The important bit is that your picture conveys a feeling. Some things can be fixed in post-production. You can’t fix things like focus or motion blur afterwards, but even these are details and not getting them exactly right won’t mean your picture will be bad.

Don’t compare

Even professional photographers take bad pictures. You never see the shots that didn’t make it. Being a good photographer is as much about being a good editor. The very best still take crappy shots sometimes, and alright shots most of the time. You just don’t see the bad ones.

Ask people you think are great photographers to point out something they’re unhappy about in that amazing picture they took. Chances are they will point out several flaws that you weren’t even aware about.


Don’t forget to actually have a place to actually post your images. Flickr or Instagram are fine for this. We want to see your work! Even if it’s not perfect in your eyes. Do your own thing. You have your own style.


I hope that was helpful. Now stop reading and don’t worry too much. Get out there and have fun. Shoot!

by Hylke Bons at October 09, 2014 10:53 PM

September 28, 2014

Hylke Bons

Switching jobs

Today was my first day at Red Hat! This has been a public service announcement.

by Hylke Bons at September 28, 2014 09:30 PM

London Zoo photos

Visited the London Zoo for the first time and took a few photos.

by Hylke Bons at September 28, 2014 08:51 PM

Trip to Nuremberg and Munich

This month I visited my friend and colleague Garrett in Germany. We visited the Christmas markets there. Lots of fun. Here are some pictures.

by Hylke Bons at September 28, 2014 05:27 PM

September 27, 2014

Hylke Bons

Attending the Vienna GNOME/.NET hackfest

Today I arrived in the always wonderful city of Vienna for the GNOME/.NET Hackfest. Met up and had dinner with the other GNOME and .NET fans.

SparkleShare has been stuck on GTK+2 for a while. Now that the C# bindings for GTK+3 are starting to get ready, and Bindinator is handling any other dependencies that need updating (like WebKit), it is finally time to take the plunge.

My goal this week is to make some good progress on the following things:

  1. Port SparkleShare's user interface to GTK+3.
  2. Integrate SparkleShare seamlessly with the GNOME 3 experience

SparkleShare 1.2

Yesterday I made a new release of SparkleShare. It addresses several issues that may have been bugging you, so it's worth to upgrade. Depending on how well things go this week it may be the last release based on GNOME 2 technologies. Yay for the future!

by Hylke Bons at September 27, 2014 02:28 PM

SparkleShare 1.0

I’m delighted to announce the availability of SparkleShare 1.0!

What is SparkleShare?

SparkleShare is an Open Source (self hosted) file synchronisation and collaboration tool and is available for Linux distributions, Mac, and Windows.

SparkleShare creates a special folder on your computer in which projects are kept. All projects are automatically synced to their respective hosts (you can have multiple projects connected to different hosts) and to your team’s SparkleShare folders when someone adds, removes or edits a file.

The idea for SparkleShare sprouted about three years ago at the GNOME Usability Hackfest in London (for more background on this read The one where the designers ask for a pony).

SparkleShare uses the version control system Git under the hood, so people collaborating on projects can make use of existing infrastructure, and setting up a host yourself will be easy enough. Using your own host gives you more privacy and control, as well as lots of cheap storage space and higher transfer speeds.

Like every piece of software it’s not bug free, even though it has hit 1.0. But it’s been tested for a long time now and all reproducable and known major issues have been fixed. It works reliably and the issue tracker is mostly filled with feature requests now.

The biggest sign that it was time for a 1.0 release was the fact that Lapo hasn’t reported brokenness for a while now. This can either mean that SparkleShare has been blessed by a unicorn or that the world will end soon. I think it’s the first.


For those of you that are not (that) familiar with SparkleShare, I’ll sum up its most important features:

The SparkleShare folder

This is where all of your projects are kept. Everything in this folder will be automatically synced to the remote host(s), as well as to your other computers and everyone else connected to the same projects. Are you done with a project? Simply delete it from your SparkleShare folder.

The status icon

The status icon gives you quick access to all of your projects and shows you what’s going on regarding the synchronisation process. From here you can connect to existing remote projects and open the recent changes window.

The setup dialog

Here you can link to a remote project. SparkleShare ships with a couple of presets. You can have mulitple projects syncing to different hosts at the same time. For example, I use this to sync some public projects with Github, some personal documents with my own private vps and work stuff with a host on the intranet.

Recent changes window

The recent changes window shows you everything that has recently changed and by whom.


The history view let’s you see who has edited a particular file before and allows you to restore deleted files or revert back to a previous version.

Conflict handling

When a file has been changed by two people at the same time and causes a conflict, SparkleShare will create a copy of the conflicting file and adds a timestamp. This way changes won’t get accidentally lost and you can either choose to keep one of the files or cherry pick the wanted changes.


If someone makes a change to a file a notification will pop up saying what changed and by whom.

Client side encryption

Optionally you can protect a project with a password. When you do, all files in it will be encrypted locally using AES-256-CBC before being transferred to the host. The password is only stored locally, so if someone cracked their way into your server it will be very hard (if not impossible) to get the files’ contents. This on top of the file transfer mechanism, which is already encrypted and secure. You can set up an encrypted project easily with Dazzle.

Dazzle, the host setup script

I’ve created a script called Dazzle that helps you set up a Linux host to which you have SSH access. It installs Git, adds a user account and configures the right permissions. With it, you should be able to get up and running by executing just three simple commands.

Plans for the future

Something that comes up a lot is the fact that Git doesn’t handle large (binary) files well. Git also stores a database of all the files including history on every client, causing it to use a lot of space pretty quickly. Now this may or may not be a problem depending on your usecase. Nevertheless I want SparkleShare to be better at the “large backups of bulks of data” usecase.

I’ve stumbled upon a nice little project called git-bin in some obscure corner of Github. It seems like a perfect match for SparkleShare. Some work needs to be done to integrate it and to make sure it works over SSH. This will be the goal for SparkleShare 2.0, which can follow pretty soon (hopefully in months, rather than years).

I really hope contributors can help me out in this area. The Github network graph is feeling a bit lonely. Your help can make a big difference!

Some other fun things to work on may be:

  1. Saving the modification times of files
  2. Creating a binary Linux bundle
  3. SparkleShare folder location selection
  4. GNOME 3 integration
  5. …other things that you may find useful.

If you want to get started on contributing, feel free to visit the IRC channel: #sparkleshare on so I can answer any questions you may have and give support.


I’d like to thank everyone who has helped testing and submitted patches so far. SparkleShare wouldn’t be nearly as far as it is now without you. Cheers!

by Hylke Bons at September 27, 2014 01:48 PM

Vienna GNOME/.NET hackfest report

I had a great time attending the GNOME/.NET hackfest last month in Vienna. My goal for the week was to port SparkleShare's user interface to GTK+3 and integrate with GNOME 3.

A lot of work got done. Many thanks to David and Stefan for enabling this by the smooth organisation of the space, food, and internet. Bertrand, Stephan, and Mirco helped me get set up to build a GTK+3-enabled SparkleShare pretty quickly. The porting work itself was done shortly after that, and I had time left to do a lot of visual polish and behavioural tweaks to the interface. Details matter!

Last week I released SparkleShare 1.3, a Linux-only release that includes all the work done at the hackfest. We're still waiting for the dependencies to be included in the distributions, so the only way you can use it is to build from source yourself for now. Hopefully this will change soon.

One thing that's left to do is to create a gnome-shell extension to integrate SparkleShare into GNOME 3 more seamlessly. Right now it still has to use the message tray area, which is far from optimal. So if you're interested in helping out with that, please let me know.

Tomboy Notes

The rest of the time I helped out others with design work. Helped out Mirco with the Smuxi preference dialogues using my love for the Human Interface Guidelines and started a redesign of Tomboy Notes. Today I sent out the new design to their mailing list with the work done so far.

Sadly there wasn't enough time for me to help out with all of the other applications… I guess that's something for next year.


I had a fun week in Vienna (which is always lovely no matter the time of year) and met many new great people. Special thanks to the many sponsors that helped making this event possible: Norkart, Collabora, Novacoast IT, University of Vienna and The GNOME Foundation.

by Hylke Bons at September 27, 2014 01:29 PM

September 20, 2014

Damien Lespiau

git commit –fixup and git rebase -i –autosquash

It’s not unusual that I need to fix previous commits up when working  on a branch or in the review phase. Until now I used a regular commit with some special marker to remember which commit to squash it with and then git rebase -i to reorder the patches and squash the fixup commits with their corresponding “parent” commits.

Turns out, git can handle quite a few of those manual manipulations for you. git commit --fixup <commit> allows you to commit work, marking it as a fixup of a previous commit. git rebase -i --autosquash will then present the usual git rebase -i screen but with the fixup commits moved just after their parents and ready to be squashed without any extra manipulation.

For instance, I had a couple of changes to a commit buried 100 patches away from HEAD (yes, a big topic branch!):

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 29f3813..08ea851 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2695,6 +2695,11 @@ static void skylake_update_primary_plane(struct drm_crtc *crtc,
        intel_fb = to_intel_framebuffer(fb);
        obj = intel_fb->obj;
+       /*
+        * The stride is expressed either as a multiple of 64 bytes chunks for
+        * linear buffers or in number of tiles for tiled buffers.
+        */
        switch (obj->tiling_mode) {
        case I915_TILING_NONE:
                stride = fb->pitches[0] >> 6;
@@ -2707,7 +2712,6 @@ static void skylake_update_primary_plane(struct drm_crtc *crtc,
-       plane_ctl &= ~PLANE_CTL_TRICKLE_FEED_DISABLE;
        plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
        I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);

And I wanted to squash those changes with commit 2021785

$ git commit -a --fixup 2021785

git will then go ahead and create a new commit with the subject taken from the referenced commit and prefixed with <code>fixup!<code>

commit d2d278ffbe87d232369b028d0c9ee9e6ecd0ba20
Author: Damien Lespiau <>
Date:   Sat Sep 20 11:09:15 2014 +0100

    fixup! drm/i915/skl: Implement thew new update_plane() for primary planes

Then when using the interactive rebase with autosquash:

$ git rebase -i --autosquash drm-intel/drm-intel-nightly

The fixup will be next after the reference commit

pick 2021785 drm/i915/skl: Implement thew new update_plane() for primary planes
fixup d2d278ff fixup! drm/i915/skl: Implement thew new update_plane() for primary planes

validating the proposed change (by in my case leaving vim) will squash the fixup commits. Definitely what I’ll be using from now on!

Oh, and there’s a config option to have git rebase automatically autosquash if there are some fixup commits:

$ git config --global rebase.autosquash true

by damien at September 20, 2014 10:18 AM

July 22, 2014

Emmanuele Bassi

moving on…

I’ve finally restored my personal web server after the WordPress installation(s) I had there got hacked last year, and I decided to migrate this blog there.

if you do not read this blog via Planet GNOME, but you use the syndacation feed, you should subscribe to this feed, instead. if you’re only interested in GNOME-related posts (i.e. the posts that end up in Planet GNOME) the use this feed instead.

by ebassi at July 22, 2014 11:55 AM

May 19, 2014

Ross Burton

UEFI Validation

The Linux UEFI Validation Project was announced recently:

Bringing together multiple separate upstream test suites into a cohesive and easy-to-use product with a unified reporting framework, LUV validates UEFI firmware at critical levels of the Linux software stack and boot phases.

LUV also provides tests in areas not previously available, such as the interaction between the bootloader, Linux kernel and firmware. Integrated into one Linux distribution, firmware can now be tested under conditions that are closer to real scenarios of operation. The result: fewer firmware issues disrupting the operating system.

Of course that “one Linux distribution” is built using the Yocto Project, so it’s trivial to grab the source and patch/extend it, or rebuild it for different processors if for example you want to validate UEFI on ARM or a new CPU that mainstream distros don’t fully support.

by Ross Burton at May 19, 2014 09:07 AM

Richard Purdie

Kielder K2 – Marshalling Day 3

Sunday morning was an early start but despite the fun of the previous day, I was basically ok and the swelling of my leg has massively reduced overnight. I made my way back to Bellingham in time to put fuel onto the fuel trailer and then made my way leisurely to the far checkpoint and my section. Unfortunately I was on my own today, it is more fun when you have someone to ride with and talk to.

Eventually bikes turned up and entered the section and then I followed the pack through to make sure there weren’t any issues. It was all quiet so I cut back to the special test and refueled finding the riders weren’t yet back to there. I therefore waited around. The end of the special test has an interesting detour through a ditch and there were a number of people falling off there who I ended up helping. There was one person who decided to head off the line everyone else was using and buried it in liquid mud up to the mudguards. I didn’t enjoy pulling that out and getting covered in mud. Another went off line, planted the front wheel into a hole and went over the bars head first, thankfully he was shaken but ok as it was slow speed.

There were people having fun on the enduro loops but my back tyre wasn’t up to it, nor were my energy levels to be quite honest. I had something to eat/drink and eventually the closing marshal turned up which marked the start of my main work. I headed back to my section via a short cut along with a local rider who was wanting to retire. There, I had a wait for the closing marshal again, he arrived and it was time to demark.

I was supposed to be with a team of another two however they weren’t there and I decided to get started without them, leaving word with the checkpoint to send them on. I hadn’t gotten too far when they showed up and joined in. We worked as a team, person in front gets the first arrow they come to and the team rotates. Demarking can be interesting as you never know quite what kind of terrain you’ll have to park on to reach the arrows. Obviously you try to do it without getting off the bike, although if the ditch is marsh/water with reeds growing out of it, you quickly learn not to ride into it (I’d remembered from last year).

We made it around the course to the next checkpoint and demarked to the road there, then also demarked the route back to the camping field. The far section with the second special test was being handled by another team. By the end of the few days, the bike was rather coated in mud/dust and rather sorry for itself with its missing headlight:

The forest fire roads are hard on tyres, particularly when you do use the power to accelerate and my rear was paractially a slick at this point:

So all in all a good weekend and some good fun. The bike is going to need a good check over after all that vibration from the fireroads.

by Richard at May 19, 2014 08:56 AM

Kielder K2 – Marshalling Day 2

Saturday dawned and I found I could roughly move. Various locals started arriving, either entering in the rally or marshalling. I was given the top section of the course to look after where I’d run out of fuel the day before. One of the local TRF was to be my partner in crime.

We had a leisurely ride out to the special test, then short cut to our section. We did a sighting lap of that part not least so my partner had some idea where we were, then watched a load of bikes through the special test since that was our way back to the start of our section and the checkpoint there. We headed back there to find nobody has entered it yet and managed to push our way through the crowds to the front. The spot has a lovely view over the reservoir.

After a good few bikes had set off, we started a check through and stopped to take some photos of some friends. After that we came across
a breakdown, a 690 that wouldn’t run. We spent a while pooling tools trying to diagnose the problem. It had a spark so it had to be fuel related. We left to go and find a tow rope. We swept through our section, then went back to the special test and fuel point to refill and find a tow rope. On the way back to our section we passed some other breakdowns but there wasn’t anything we could do to help and they were in a good place for recovery.

Whilst my two stroke wasn’t up to towing, my partner’s four stroke was and we were able to get him out the forest using some creative use of shortcuts and into a position he could get recovered from. Greg did well particularly given he’d never tried this before.

After Greg refueled at Kielder and I’d eaten my sandwiches, we went back around our section, stopping for photos and so on, hovering near the end so we’d hear of any other breakdowns or problems. When it was clear things were winding down we headed back to the test/fuel area and found the course was closed. All that was left was for us to head back to base which we did without incident. Our section was clear as far as we knew and would get checked by the closing team anyway.

I have to say I was pretty tired at this point. I decided that rather than camping, I’d head home for a shower and so on in comfort and I wanted a better look at my leg. I arrived home without incident, had a shower and re-bandaged the leg and then started to feel extremely unwell. As far as I can tell I was losing my ability to regulate body temperature and was very shaky and shivering with a fast pulse. I tried various quick food/drink options and it wasn’t helping, if anything I was getting worse, extremely cold and shivery. An idea struck me and I tried a can of coke which thankfully hit the spot and pulled me out of it within 10 minutes.

This is very similar to what happened to me a couple of years ago. In that case I ended up near enough unconscious for 18 hours so this was an improvement on last time. I’m now pretty sure these were both cases of hypoglycaemia. Readers are probably thinking diabetes come to mind or a thyroid problem etc. For the record, I’ve had a ton of tests and its not any of the “usual” suspects. It does seem to be exercise induced, delayed effect and some kind of metabolic muscle issue is prime suspect. I have my theories and investigation is still ongoing.

So I opted to stay at home for a good night’s sleep and to see how I was in the morning. Any sensible person would perhaps of opted to rest the next day however I believe I’m actually starting to understand what was going on with energy levels and all my instincts told me I would be fine to ride.

by Richard at May 19, 2014 08:36 AM

K2 Rally – Marshalling Day 1

The K2 rally is this weekend in Kielder forest. It was fairly eventful so I’ll split these day by day.

Marking out a 65 mile course in the forest takes quite some time so I’d offered help to the organiser with that as well as marshalling in the rally itself.

As things worked out on the Friday, the course was pretty much done but it did need sighting, a check that all the signs were present in the right places, hazards marked etc. for the perspective of someone coming around the course.

Having arrived and secured a flat piece of ground for the tent, I therefore set off with someone who I won’t name on a DRZ400 on semi tyres, not off road ones. He assured me he would go steady but he’d finished X rallies, considers himself a retired enduro rider etc. He did have a good medical reason for not wanting to fall off too and wanted someone with him.

So we set off and it was soon clear that when he said we’d go ’steady’, he didn’t half mean it. I was on the YZ with its road gearing on, not the enduro gearing since this was a rally. It’s engine is a handful at the best of times and it didn’t run well at this (lack of) speed :( .

Back in the karting days, I prided myself on an ability to limp broken two stroke engines back to the pits so somehow, I managed to keep the YZ running and not oil the plug.

When we found the special test, I ended up having to go past for one section since the YZ requires commitment and the 10mph simply wasn’t going to work. I was wishing I was on the CRM which would have been much happier at this pace.

We did put up a few arrows in places to make things clearer and there was only one confusing section where some tape wasn’t out. At this point it became clear that whilst we had a map, I’d have to read it. I also had the GPS and some idea of what the forest looks like by now, thankfully.

Somehow we made it to the top of the course and after a biscuit break, we dropped down onto the road by the reservoir and then turned back into the forest. He commented that his speedo had stopped working.

At this point I noticed his front wheel was unwell. At first it looked like he’d lost a spoke which had snagged the speedo cable and wrapped it around the wheel a couple of times. The bike was basically unsafe to ride.

So, first up, what tools did we have? He seemed very unkeen to try and get them from the sealed package on his bike so we tried mine. Unfortunately I’d picked up my favourite multitool, not remembering it was broken so we were without decent pliers. The speedo cable was at quite some tension and therefore not easy to undo. We could undo various mounting clips to try and slacken it off and then using the broken pliers, very slowly inched the top end of the cable undone.

When it did come undone it did so with quite some force and could have done nasty things to my fingers but I had anticipated this. We found it wasn’t a spoke that was wrapped around the wheel but 12″ of fencing wire. We pulled that off and then rather than disconnecting the speedo from the other end, managed to simply sever the cable. Great, we could continue.

The course is supposed to be a 2-2.5 hour lap. I think we were 4 hours in at this point, maybe more and not even half way. We looped around the next section of forest and then suddenly, my bike started sounding odd, the kind of odd that means the fuel is running out. I sounded my horn, waved arms and he took not notice of me and continued off into the distance as I coasted to a stop.

Not entirely able to believe it I checked the tank and yes, it was extremely low and now on reserve. Eventually he noticed I was missing and came back to look for me. Basically, my lack of fuel was extremely frustrating for him and his advice was we split up and I make my own way back on the road, I could always hitch a lift and then pick the bike up. That way I was no longer a problem for him. Against my better judgement, I decided that yes, I’d have to sort myself out. I knew where there was an automated fuel station, perhaps within range of my reserve however I had neither two stroke oil to mix new fuel, or a credit card with me (not many places take them deep in the forest).

We also had a little disagreement about the cause of my lack of fuel. He was keen to point out that as any idiot knows, running slower doesn’t use more fuel. I suggested that rule may apply to a point but that the YZ actually runs more efficiently at more than 10mph however he wasn’t having it. Regardless, it wasn’t going to change anything.

I therefore left, in full fuel economy mode and headed for Bellingham. Making it was never going to happen and I coasted to a stop completely out just past Falston. On the plus side I knew exactly where I was. On the downside it was a fair distance to where I needed to be (9 miles as it turned out).

I stashed the bike down a side road in some bushes, I also stashed the bike helmet, the arrows, stapler, body armour and anything else I wasn’t going to need under a handy plastic sheet over some firewood. I should mention at this point that there is no mobile phone signal apart from occasionally a network I wasn’t on, nor was I expecting any signal any time soon. Any houses around there are holiday lets or second homes and nobody was around.

So still wearing the knee braces and bike boots, I started the walk to Bellingham. At least this way I knew I’d get sorted out eventually. I was passed by lots of cars and I’d imagine someone wearing MX clothing and big bike boots looked a little out of place walking along a verge. One oncoming car did stop and ask if I was ok and did offer me a lift in the wrong direction but I politely declined. I wasn’t taking too well to walking in the heat with that gear on, “dripping”, doesn’t quite cover it.

After 3 miles a car going the right way did stop and gave me a lift into Bellingham for which I was extremely grateful. I tried to find the organiser to tell him I was ok but he wasn’t around. I figured my friend was still riding around the forest so far so nobody probably knew I was stranded yet. I therefore jumped into the discovery and went to collect the bike and stashed gear. That went without incident and when I got back to the site, the organiser also arrived back having been looking for me. My friend had got a message from his phone to his wife. Anyhow, I+bike were back and all was well.

It was now late afternoon and I opted for a tea break. Thinking I was just popping out for three hours, I hadn’t taken food with me although I’d had a drink. The organiser was apologetic for my trip out and said if I wanted, I could go and check the other half of the course with him if I was up for it. So we set off and all I can say is that this trip was opposite extremes to the first one. I mostly kept up and we got the other half of the course done on half a tank of fuel (including riding out to it). So perhaps it does use more fuel at 10mph, who’d have thought it! I did get to see the second special test although I much preferred the first.

Unfortunately, just as we were coming to the end of the course, I relaxed a little too much, ran wide on the exit of a corner, ran onto the edge of and then into a gravel drainage ditch and spent a short while sliding along said ditch under the bike.

Once I was sure we’d actually stopped, I have a distinct memory of the self test of various pieces of me, concluding that all appeared to still be attached with one area of pain on my thigh which wasn’t structural. I therefore extracted myself and inspection showed a hole through the clothing on my thigh and some rather red raw looking skin, 3×2″ in size. I wasn’t leaking and inspection tallied with the previous conclusion, not structural so I turned my attention to the bike. It appeared not to be too bad and so while the adrenaline was still kicking in, I hauled it out the ditch through shear will power. The organiser therefore found me sitting in the middle of the track looking a little worse for wear. I was thankful the bike started without too much faff for a change and we went the two corners out the forest and the few miles of road back to camp.

Once back, someone helpfully pointed out the headlight was smashed. That was the least of my concerns, I dug out the first aid kit from my backpack which I’ve been carrying around for literally years, some water and paper towels and went about seeing how bad the damage was to me. I still can’t make up my mind if its a burn or a graze, I suspect its a burn from the exhaust. The first aid kit had the right things in it thankfully and although the first attempt at a bandage didn’t work too well, it did after supplementation with gaffer tape. It was clear at this point there was ’some’ bruising too. I suspect that I hit my knee hard but the brace deflected the damage into my thigh muscle which is a good thing and working as designed. I’ve a link here to a picture of said injury, don’t follow it if you don’t like gruesome graphic detail.

What followed was a pleasant evening on the campsite, cooking dinner and then talking to various people as they arrived, I eventually had to call it a night as sitting in the cold was causing my leg to seize up.

But hang on, what became of my friend you might ask? Well, he did complete lap one but proceeded to follow the arrows and start a second, not realising where he was. He did think some of the corners looked familiar! At some point he ran out of fuel. The only remaining detail to complete to story is that that he was rescued by a passing postman!

by Richard at May 19, 2014 07:50 AM

May 15, 2014

Ross Burton

Reproducible builds and GPL compliance

LWN has a good article on GPL compliance (if you’re not a subscriber you’ll have to wait) that has an interesting quote:

Developers, and embedded developers in particular, can help stop these violations. When you get code from a supplier, ensure that you can build it, he said, because someone will eventually ask. Consider using the Yocto Project, as Beth Flanagan has been adding a number of features to Yocto to help with GPL compliance. Having reproducible builds is simply good engineering practice—if you can’t reproduce your build, you have a problem.

This has always been one of the key points that we emphasis when explaining why you should use the Yocto Project for your next product.  If you’re shipping a product that is built using fifty open source projects then ensuring that you can redistribute all the original sources, and the patches that you’ve applied, and the configure options that you’ve used, and any tweaks to go from a directory of binaries to a bootable image isn’t something you can knock up in an afternoon when you get a letter from the SFC.  Fingers crossed you didn’t accidentally use some GPLv3 code when that is considered toxic.

Beth is awesome and has worked with others in the Yocto community to ensure all of this is covered.  Yocto can produce license manifests, upstream sources + patches archives, verify GPLv3 code isn’t distributed, and more.  All the work that is terribly boring at the beginning when you have a great idea and are full of enthusiasm (and Club-Mate), but by the time you’re shipping is often nigh on impossible.  Dave built the kernel on his machine but the disk with the right source tree on died, and Sarah left without telling anyone else the right flags to make libhadjaha actually link…  it’ll be fine, right?

by Ross Burton at May 15, 2014 10:29 PM

May 11, 2014

Ross Burton

Misc for Sale

As we’re moving house we are having a bit of a clear out, and have some techie gadgets that someone else might want:

  • Netgear DGN3500 ADSL/WiFi router. £15.
  • Bluetooth GPS dongle. £5.
  • Seagate Momentus 5400.6 160GB 2.5″ SATA hard disk (ex-MacBook). £5.

Those prices are including UK postage. Anyone interested?

by Ross Burton at May 11, 2014 10:28 PM

May 05, 2014

Richard Purdie

MGB lives again

Back in August 2010 I blew the MG’s engine up. I did get around to taking that one out and fitting the spare. The battery was too flat to start it and winter came along before I’d got any further. With moving house, the work on said house and garage and 101 other things, the MG just never happened and its been sat looking sorry for itself ever since :( .

Today, I thought I’d see what state it was in. It was changed overnight so the battery should either be good or knackered. The bonnet release cable was snapped but I found a way in.

Whilst stiff, the controls all seemed to roughly do what they should. First try at ignition on saw petrol explode over the engine bay as the fuel line between the carbs gave way. At least the fuel pump works I guess.

After a small new piece of fuel pipe was fitted, take two. Ignition on, fuel at pressure, no overflow from the carbs which was a pleasant surprised as I was expecting a carb rebuild. Trying the starter, the engine turned over at a reasonable speed, it even make a hint of a cough of life. The lack of oil pressure stopped me at this point. I took the plugs out, then ran it on the starter and after what seemed like an eternity, the oil pressure climbed to normal. Ok.

Plugs back in, try the starter. Nothing. This was the point I was at after the rebuild but with a charged battery. I noted the distributor was loose and I’d never set the timing. Ok, twiddle it one way, try again. Still nothing. Ok, lets try the other way.

This time, you could hear it trying. After some further gentle nudging, it started coughing into life, first on a single cylinder then quickly onto approximately two. At this point I just gently tried to keep it running. The other cylinders kicked in intermittently at first, then it was running on all approximately four. I looked around for Dad who’d run off to try and stop the clouds of smoke a two stoke would be proud of from getting into the garage (too late). I gestured for Dad to check nothing was on fire on the exhaust (probably just the petrol from the earlier spillage).

I decided not to run it too much more since there was no water in it. We stopped and then rectified that, cue a comedy moment where there was water pouring from a hole in the cylinder head with us wondering “what’s missing?” until we realised it was the water temperature sender unit.

Emboldened by this, we wondered “could it move?”. My Dad carefully moved vehicles out of the way in case the brakes failed in some catastrophic way and made dire predictions about whether I’d destroy the clutch trying this. It started and then we managed a controlled lurch forwards as the brakes unbound with not nearly as much issue as we’d expected. At this point I drove it off the drive and did a couple of loops around the T junction. Everything felt seized up but it was none the less moving, stopping, starting and turning.

At this point attention turned to the driveway which needed a good clean and with the car missing, this was an ideal opportunity. Later, the car started first turn of the starter and reversed back on relatively happily.

Sadly the bodywork is in a bad way but at least now its known to vaguely function and move under its own power :) .

by Richard at May 05, 2014 03:19 PM

May 04, 2014

Richard Purdie

CRM lives again

I took the CRM to bits back in September. It was making various rattling noises that said the engine was tired and in need of a rebuild. Upon dismantling it, I found that not only was the piston chattering but the power valve was also not in the best of health being rather loose on its shaft. I managed to get a secondhand part for that but getting a new piston proved tricky since I wanted a forged one rather than cast. I ended up going for a .4mm oversize after much playing with feeler gauges and vernier callipers to map out the barrel wear. As expected it was more worn in the centre of the bore and less at the top/bottom.

As a family we’ve long since used an engineering shop in Blyth for rebores. A lot of our engines now have nikasil liners which mean sending off the cylinders but this one is a cast iron liner and hence can be done locally. When I dropped it off, there was much sucking of teeth about a 0.4mm oversize piston as it was not leaving them a lot of room for the rebore. They’d do the best they could, complaining the standard bores were never actually straight. It had been given to the “old man” by the son since he has more patience with these silly motorcycle things. We use the place due to their attention to detail. A joke from my school’s karting association days about their local competitor springs to mind: “Where did you get the rebore? Armstrongs?! How do you square up the barrel then? Yellow pages [telephone directory] under one side?”.

The above shows a mark left which they were very apologetic about but they had warned me. In reality this won’t make any difference to the running.

New shiny parts and some less shiny power valve bits.

Crazy amounts of plumbing. The question is could I remember how it all goes together from back in September?

An interesting aside, these photos show the exhaust port with the valve open and closed. It makes an amazing difference to the port size and position. This allows the engine to have low down grunt and decent top end rather than having the port timing fixed to a specific engine speed.

The new shiny piston fitted and ready for the top end. I nearly forgot to fit the new base gasket but did thankfully remember.

It went back together with nothing unepected left over which is always good. So did it start? Kind of. It did fire up, smoke a lot then stop. It reluctantly fired up again, stopped and lost all compression. At this point I was some what panicking and also out to time to work on it further.

There are a limited number of ways a two stroke can lose compression and most of them are not good. This morning I took the exhaust off and peered into the barrel as best I could, all looked well. No signs of the power valve having hit the piston which was one worry. I tried turning the engine over under load and the compression came back suggesting the thing was just full of oil which was seizing up the piston rings. I spent an age kicking it over trying to get it started and did manage to get it to fire up occasionally once managing to get it onto full throttle with clouds of smoke coming out, then it basically stopped dead again. The plug was clearly oiling up and its a 10 minute job to remove, clean and refit it.

I gave in and called in Dad to drive the discovery whilst I was towed by it on the CRM. I am reluctant to do this having destroyed engines like this but I was confident the thing was just clogged up with oil. It took half the block for it to turn over enough to clear, fire and then run under its own power. A couple of more trips around the block, probably much to the enjoyment of the neighbours and its running! So it lives again, just need to get it out and gently run it in now.

by Richard at May 04, 2014 01:03 PM

Hanging by a thread

Never let it be said I don’t believe in preventative maintenance. Admittedly this is a little just in time!

This is the YZ’s clutch cable in case that isn’t clear. The first one that arrived was for a 250F (a four stroke) despite me clearly buying one for the YZ250 (a two stroke).

by Richard at May 04, 2014 12:19 PM

May 02, 2014

Emmanuele Bassi


one of the challenges of writing a graphics library that is capable of doing what modern UI designers and developers expect is providing the required data types to achieve things like 3D transformations.

with the collective knowledge and attention to detail1 that the free and open source software community brings to the table I was actually surprised to see that all the code for doing vector and matrix math is usually tucked away into various silos that also come with canvas implementations, physics engines, and entire web browsers. it gets even worse when you want code that used features of modern (and less modern) hardware, and instead all you get are just naive implementations of four floating point values in a structure.

you can trust me when I say that I didn’t want to spend the past seven days writing code that deals with vector and matrix operations, when I wasn’t reading PDFs of Intel architecture opcodes, or ARM NEON instructions; I also didn’t want to know that once you start implementing common operations on matrix types, like projection and unprojection, you get to open a fairly deep can of worms that forces you to implement point (2D and 3D), rectangle, quaternion, and quad types.

luckily, it’s possible to find a bunch of implementations under various stages of maintenance, and under suitable licenses, even though mostly are in C++ and they overlap by just about 60% each; you really need to buckle up and start translating naive matrix determinant code to SIMD four vector data structures, and do a union of all possible API, before you have something you can actually use.

the end result of these seven days is an almost decent, almost complete little utility library that tries to be fairly thin in both what it requires and what it provides. I called it graphene and it’s available in Git. at some point, when I’m actually satisfied with it, I’ll even document it like the grown-up I’m supposed to be. right now, I’ll have to write a ton of tests to check on the math, because I’m pretty sure there must be at ton of bugs in there.

the main question is: what do I intend to use graphene for. the more attentive amongst you, kind readers, will already guess that it’s for the forthcoming GTK+ scene graph API — which is indeed the correct answer, but you’ll have to wait for the next blog post in the series for a proper introduction and description, as well as a road map for the unicorn and ponies fuelled future.

  1. bordering on the OCD

by ebassi at May 02, 2014 08:00 PM

Berlin DX Hackfest / Day 3






the third, and last day of the DX hackfest opened with a quick recap as to what people have been working on in the past couple of days.

we had a nice lunch nearby, and then we went back to the Endocode office to tackle the biggest topic: a road map for GTK+.

we made good progress on all the items, and we have a fairly clear idea of who is going to work on what. sadly, my optimism on GProperty landing soon did not survive a discussion with Ryan; it turns out that there are many more layers of yak to be shaved, though we kinda agreed on the assumption that there is, in fact, a yak underneath all those layers. to be fair, the work on GProperty enabled a lot of the optimizations of GObject: property notifications, bulk installation of properties, and the private instance data reorganization of last year are just examples. both Ryan and I agreed that we should not increase the cost for callers of property setters — which right now would require asking the GProperty instance to the class of the instance that we’re modifying, which implies taking locks and other unpleasant stuff. luckily, we do have access to private class data, and with few minor modification we can use that private data to store the properties; thus, getting the properties of a class can be achieved with simple pointer offsets and dereferences, without locks being involved. I’ll start working on this very soon, and hopefully we’ll be able to revisit the issue at GUADEC, in time for the next development cycle of GLib.

in the meantime, I kept hacking on my little helper library that provides data types for canvases — and about which I’ll blog soon — as well as figuring out what’s missing from the initial code drop of the GTK+ scene graph that will be ready to be shown by the time GUADEC 2014 rolls around.

I’m flying back home on Saturday, so this is the last full day in Berlin for me. it was a pleasure to be here, and I’d really like to thank Endocode for generously giving us access to their office; Chris Kühl, for being a gracious and mindful host; and the GNOME Foundation, for sponsoring attendance to all these fine people and contributors, and me.


Sponsored by the GNOME Foundation

by ebassi at May 02, 2014 07:00 PM

May 01, 2014

Emmanuele Bassi

Berlin DX Hackfest / Day 2

the second day of the hackfest had a pretty big discussion on the roadmap for GTK+.

thanks to Matthias Clasen, we had a list of things to discuss prior to the start of the hackfest, even if Matthias himself would not be present:

  • filling the gaps between the GNOME HIG and the GTK+ API needed to implement it
  • a better cross-platform story for tool kit maintainers and application developers
  • touch support
  • scene graph to replace Clutter
  • documentation
  • improving the relationship of the tool kit with Glade
  • required clean ups for GTK+ 4

during the afternoon we managed to go through the first bullet point of the list, but we made really good progress on it, and we managed to assign each sub-issue to a prospective owner that is going to be in charge of it.

hopefully, we’re going to go through the other points during the rest of the hackfest much more quickly.

Sponsored by the GNOME Foundation

by ebassi at May 01, 2014 11:01 PM

Berlin DX hackfest / Day 1

we had a fairly productive first day here, at the Endocode offices in Berlin. everyone is pretty excited about working on the overall experience for developers on the GNOME platform.

at first, we decided what to tackle in the next three days, and drafted a rough schedule. the hackfest then broke down into two main groups: the first tackled GObject models for the benefit of GTK+ widgets acting as views; the second worked on the developer documentation available on

I decided to stay on the sidelines for the day, and worked on a small utility library that I’m going to use in the development of GSK, the GTK+ scene graph API that will replace Clutter in the near future; I’m going to do a proper blog post on both things later this week. I’ve also worked a bit on my old nemesis, GProperty. I have really high hopes that after three years of back and forth we’re going to finally land it in GLib, and let people have a better, easier, and more efficient way to define and use GObject properties.

In the evening we went to the Berlin GNOME beers along with the local GNOME community; it’s been a great evening, and we met both familiar faces and new ones.

I’d like to thank Endocode for kindly giving us access to their office in order to host the hackfest, as well as the GNOME Foundation for sponsoring travel attendance of many talented members of the GNOME community.

Sponsored by the GNOME Foundation

by ebassi at May 01, 2014 04:00 PM

February 05, 2014

Ross Burton

Better bash completion?

Bash completion is great and everything, but I spend more time than is advisable dealing with numerous timestamped files.

$ mv core-image-sato-qemux86-64-20140204[tab]

This isn’t an obvious choice as I now need to remember long sequences of numbers. Does anyone know if bash can be told to highlight the bit I’m being asked to pick from, something like this:

$ mv core-image-sato-qemux86-64-20140204[tab]

by Ross Burton at February 05, 2014 11:55 AM

January 21, 2014

Ross Burton

Remote X11 on OS X

I thought I’d blog this just in case someone else is having problems using XQuartz on OS X as a server to remote X11 applications (i.e. using ssh -X somehost).

At first this works but after some time (20 minutes, to be exact) you’ll get “can’t open display: localhost:10.0″ errors when applications attempt to connect to the X server. This is because the X forwarding is “untrusted” and that has a 20 minute timeout. There are two solution here: increase the X11 timeout (the maximum is 596 hours) or enable trusted forwarding.

It’s probably only best to enable trusted forwarding if you’re connecting to machines you, well, trust. The option is ForwardX11Trusted yes and this can be set globally in /etc/ssh_config or per host in ~/.ssh/config.

by Ross Burton at January 21, 2014 11:17 AM

January 08, 2014

Ross Burton

Network Oddity

This is… strange. Two machines, connected through cat5 and gigabit adaptors/hub.

$ iperf -c melchett.local -d
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
Client connecting to melchett.local, TCP port 5001
TCP window size: 64.0 KByte (default)
[  4] local port 35197 connected with port 5001
[  5] local port 5001 connected with port 33692
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.08 GBytes   926 Mbits/sec
[  5]  0.0-10.0 sec  1.05 GBytes   897 Mbits/sec

Simultaneous transfers get ~900MBits/s.

$ iperf -c melchett.local -r
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
Client connecting to melchett.local, TCP port 5001
TCP window size: 22.9 KByte (default)
[  5] local port 35202 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec   210 MBytes   176 Mbits/sec
[  4] local port 5001 connected with port 33693
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec

Testing each direction independently results in only 176MBits/sec on the transfer to the iperf server (melchett). This is 100% reproducible, and the same results appear if I swap iperf client and servers.

I’ve swapped one of the cables involved but the other is harder to get to, but I don’t see how physical damage could cause this sort of performance issue. Oh Internet, any ideas?

by Ross Burton at January 08, 2014 12:38 PM

November 28, 2013

Ross Burton

Solving buildhistory slowness

The buildhistory class in oe-core is incredibly useful for analysing the changes in packages and images over time, but when doing frequently builds all of this metadata builds up and the resulting git repository can be quite unwieldy. I recently noticed that updating my buildhistory repository was often taking several minutes, with git frantically doing huge amounts of I/O. This wasn’t surprising after realising that my buildhistory repository was now 2.9GB, covering every build I’ve done since April. Historical metrics are useful but I only ever go back a few days, so this is slightly over the top. Deleting the entire repository is one idea, but a better solution would be to drop everything but the last week or so.

Luckily Paul Eggleton had already been looking into this so pointed me at a StackOverflow page which used “git graft points” to erase history. The basic theory is that it’s possible to tell git that a certain commit has specific parents, or in this case no parent, so it becomes the end of history. A quick git filter-branch and a re-clone later to clean out the stale history and the repository is far smaller.

$ git rev-parse "HEAD@{1 month ago}" > .git/info/grafts

This tells git that the commit a month before HEAD has no parents. The documentation for graft points explains the syntax, but for this purpose that’s all you need to know.

$ git filter-branch

This rewrites the repository from the new start of history. This isn’t a quick operation: the manpage for filter-branch suggests using a tmpfs as a working directory and I have to agree it would have been a good idea.

$ git clone file:///your/path/here/buildhistory
$ rm -rf buildhistory
$ mv buildhistory

After filter-branch all of the previous objects still exist in reflogs and so on, so this is the easiest way of reducing the repository to just the objects needed for the revised history. My newly shrunk repository is a fraction of the original size, and more importantly doesn’t take several minutes to run git status in.

by Ross Burton at November 28, 2013 05:07 PM

November 24, 2013

Richard Purdie

YZ Engine Rebuild

Back in August I found the YZ’s engine needed “a bit of attention”. Its taken a bit longer to get back to it than I’d hoped, partly due to building work but I can now complete the story. I stripped the bottom end down and concluded the easiest way forward was to buy a complete new crank shaft. This was slightly more expensive than just a conrod kit however it meant I didn’t need to press in the new rod and rebalance the crank, both things I could probably do but would need to buy/make tooling for. Luckily the wear on the top end was to the piston, the barrel looked fine. Bottom and top end kits were therefore duly ordered and turned up.

I started to reassemble the engine only to find the replacement crank was right, apart from the taper and thread on the ignition side. It had an M10 thread, I needed an M12 for my ignition. The bike is a 2002 model, the engine is a 2002 engine however it appears to have a 2003 crankshaft. This is probably due to the aftermarket alternator and weight. I ended up deciding to get another 2003 model crankshaft.

Since I was doing a complete overhaul I put new main bearings and seals in:

The photo shows some scary looking “cracks” in the casings although every two stroke I’ve ever rebuild looks like this to some degree so I’m doing my best to ignore them.

One nice feature of modern Japanese engines is the gearbox stays as one lump. Trying to put those back together and getting all the thrust washers in the right places is “fun”.

The crankshaft installed and casings mated back together. Of course life isn’t simple and whilst taking the engine apart, I found the likely cause of the scary sounding rattle. A worn power valve linkage. The part looks like this:

and the wear is in the first joint next to the coin in the photo. Its very hard to photograph “play” however this gives a better idea, after I’ve ground off the weld and separated the joint:

You shouldn’t be able to see light through there! Yamaha wanted a sum of money I considered excessive for this part so I decided I’d have a go at a home “oversize rebore” repair. This means drilling the hole in the outer piece larger (to make it square) and then machining a new oversize internally collar/bearing. The only lathe available to me was a little bit overkill for the job, weighing in at about 3.5tons:

however I did manage to get it to machine something that small, just about anyway:

Its hard to tell any difference from the final part however it has much less play:

After putting the crankshaft in and mating the cases, the clutch basket, plates and primary drive gear on the RHS of the engine can be installed:

A view of the ignition side of the engine showing the ignition and aftermarket flywheel weight in situ:

The clutch casing/cover can now be installed and the lovely new shiny piston can be connected to the conrod. You can see the power value linkage on the bottom left of the green base gasket. It sits in the clutch cover where there are spinning weights which control the power values depending on engine speed. The main bearings, both ends of the con ron, piston and rings were all liberally coated with two stroke oil as it was assembled.

Sadly it won’t look this shiny for long. You get a good idea of what the ports in a two stroke engine look like from this view:

A view of the power value chamber on the front of the cylinder. The repaired power value linkage rod connects to the end of the shaft on the left of the photo, turning it to different positions depending on engine rpm. The YZ has three power values, a main one on the centre exhaust port actuated by the springs in the centre and two secondary ports on the sides which are actuated by the cams and levers at the sides of the chamber. This was the only point throughout the rebuild I consulted the manual about since I’ve never actually tried to set up power valves before. The manual was a bit vague so I did what seemed right…

After all the access covers are installed, the engine is then complete. You can see the power value chamber on the front with the chamber on the side covering the repaired linkage. The cylinder head has also been installed.

All that is left is to fit it back into the bike. It took less time than I thought to do so and I’m pleased to report that whilst it didn’t start first kick, it did fire up pretty readily and whilst I didn’t run it for long, it sounds much happier!

by Richard at November 24, 2013 05:16 PM

October 25, 2013

Michael Wood

Insight recorder updates

Insight recorder updates.

Insight recorder is a user testing session recording tool that allows you to record various types of UX testing sessions on the Linux desktop. It supports webcam/webcam, screencast/webcam, webcam and screencast setups. You can download it from github as a zip.

It looks like this..isr3 isr2 isrHere is an example of a testing session recorded with insight recorder where the task was “Clear history” in Web (epiphany) , normally in a user testing session you’d have a facilitator who would be encouraging the user to speak about their experience as they’re doing it.

A few of the updates..

  • Project Autotooled – better supported installation mechanism and for translation generation
  • Two new languages (es, fr)
  • Updated VU meter to show microphone level betterer
  • Opacity control for secondary video
  • “Online” recording – seems more reliable than trying to mash videos together afterwards
  • Fixes for project file updating and loading
  • Various crash fixes
  • Cleaned up video preview ui
  • new ‘New project dialog’


by Michael Wood at October 25, 2013 04:33 PM

October 07, 2013

Michael Wood

Updating HTC One X via usb on Linux

The wifi was broken on the HTC One X (wouldn’t activate) I had and thought it might be fixed by an update (it was), having no SIM for it yet over the mobile network wasn’t an option (and it’s a 300MiB+update), but you can do reverse tethering or “internet pass-through”, without the htc sync program you can do this on Linux:.

You will need: nmap, iptables, dnsmasq and python

  • Plug in phone, select “Internet pass-through”
  • Check dnsmasq is running to provide dns, (check by `host localhost` )
  • Set up forwarding/gateway to your interwebs
  • echo 1 > /proc/sys/net/ipv4/ip_forward
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    iptables -A FORWARD -i usb0 -j ACCEPT
  • Any luck both your PC and the phone will have themselves IPs, find the phone’s IP: “nmap -sn -v | grep “Host is up” -B 1″ replacing xxx with the current subnet. e.g.

by Michael Wood at October 07, 2013 04:22 PM

October 02, 2013

Damien Lespiau

HDMI stereo 3D & KMS

If everything goes according to plan, KMS in linux 3.13 should have stereo 3D support. Should one be interested in scanning out a stereo frame buffer to a 3D capable HDMI sink, here’s a rough description of how those modes are exposed to user space and how to use them.

A reader not well acquainted with the DRM sub-system and its mode setting API (Aka Kernel Mode Setting, KMS) could start by watching the first part of Laurent Pinchart’s Anatomy of an Embedded KMS Driver or read David Herrmann’s heavily documented mode setting example code.

Stereo modes work by sending a left eye and right eye picture per frame to the monitor. It’s then up to the monitor to use those 2 pictures to display a 3D frame and the technology there varies.

There are different ways to organise the 2 pictures inside a bigger frame buffer. For HDMI, those layouts are described in the HDMI 1.4 specification. Provided you give them your contact details, it’s possible to download the stereo 3D part of the HDMI 1.4 spec from

As one inevitably knows, modes supported by a monitor can be retrieved out of the KMS connector object in the form of drmModeModeInfo structures (when using libdrm, it’s also possible to write your own wrappers around the KMS ioctls, should you want to):

typedef struct _drmModeModeInfo {
    uint32_t clock;
    uint16_t hdisplay, hsync_start, hsync_end, htotal, hskew;
    uint16_t vdisplay, vsync_start, vsync_end, vtotal, vscan;

    uint32_t vrefresh;

    uint32_t flags;
    uint32_t type;
    char name[...];
} drmModeModeInfo, *drmModeModeInfoPtr;

To keep existing software blissfully unaware of those modes, a DRM client interested in having stereo modes listed starts by telling the kernel to expose them:

drmSetClientCap(drm_fd, DRM_CLIENT_CAP_STEREO_3D, 1);

Stereo modes use the flags field to advertise which layout the mode requires:

uint32_t layout = mode->flags & DRM_MODE_FLAG_3D_MASK;

This will give you a non zero value when the mode is a stereo mode, value among:


User space is then responsible for choosing which stereo mode to use and to prepare a buffer that matches the size and left/right placement requirements of that layout. For instance, when choosing Side by Side (half), the frame buffer is the same size as its 2D equivalent (that is hdisplay x vdisplay) with the left and right images sub-sampled by 2 horizontally:


Side by Side (half)

Other modes need a bigger buffer than hdisplay x vdisplay. This is the case with frame packing, where each eye has the the full 2D resolution, separated by the number of vblank lines:

Frame Packing

Frame Packing

Of course, anything can be used to draw into the stereo frame buffer, including OpenGL. Further work should enable Mesa to directly render into such buffers, say with the EGL/gbm winsys for a wayland compositor to use. Of course, fun profit would the last step:


A 720p frame packing buffer from the game WipeOut

Behind the scene, the kernel’s job is to parse the EDID to discover which stereo modes the HDMI sink supports and, once user-space instructs to use a stereo mode, to send infoframes (metadata sent during the vblank interval) with the information about which 3D mode is being sent.

A good place to start for anyone wanting to use this API is testdisplay, part of the Intel GPU tools test suite. testdisplay can list the available modes with:

$ sudo ./tests/testdisplay -3 -i
  name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot flags type clock
[0]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x48 148500
[1]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148352
[2]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74250
[3]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x20015 0x40 74250 (3D:SBSH)
[4]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74176
[5]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x20015 0x40 74176 (3D:SBSH)
[6]  1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 0x5 0x40 148500
[7]  1920x1080i 50 1920 2448 2492 2640 1080 1084 1094 1125 0x15 0x40 74250
[8]  1920x1080i 50 1920 2448 2492 2640 1080 1084 1094 1125 0x20015 0x40 74250 (3D:SBSH)
[9]  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 0x5 0x40 74250
[10]  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 0x1c005 0x40 74250 (3D:TB)
[11]  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 0x4005 0x40 74250 (3D:FP)

To test a specific mode:

$ sudo ./tests/testdisplay -3 -o 17,10
  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 0x1c005 0x40 74250 (3D:TB)

To cycle through all the supported stereo modes:

$ sudo ./tests/testdisplay -3

testdisplay uses cairo to compose the final frame buffer from two separate left and right test images.

by damien at October 02, 2013 06:38 PM

September 28, 2013

Michael Wood

vmware makefiles not compatible with make 3.82

make[1]: Entering directory `/usr/src/linux-headers-3.10-3-amd64′
Makefile:10: *** mixed implicit and normal rules.  Stop.
make[1]: Leaving directory `/usr/src/linux-headers-3.10-3-amd64′
make: *** [vmnet.ko] Error 2

Using make version 3.82-1 downgrade to  3.81-8.2 0 (or go fix their make files)

"In previous versions of make it was acceptable to list one or more explicit
  targets followed by one or more pattern targets in the same rule and it
  worked "as expected".  However, this was not documented as acceptable and if
  you listed any explicit targets AFTER the pattern targets, the entire rule
  would be mis-parsed.  This release removes this ability completely: make
  will generate an error message if you mix explicit and pattern targets in
  the same rule."

by Michael Wood at September 28, 2013 09:07 PM

September 16, 2013

Emmanuele Bassi

Do not link against PulseAudio and JSON-GLib < 0.16

this is a public announcement.

if you link against PulseAudio, whether you want it or not, you’ll get an automatic dependency on json-c, a small C library that parses JSON and doesn’t have any dependency1. sadly, json-c leaks symbols all over the place, and one of them is called json_object_get_type2.

JSON-GLib, the library that yours truly wrote about 6 years ago to parse JSON using a decent C library as a base, also has a type called json_object_get_type3.

if you link against PulseAudio and JSON-GLib4 then you’ll get a segmentation fault with a weird stack trace, like this one and its duplicates5.

the solution is to use a version of JSON-GLib greater than 0.16.1, which builds JSON-GLib with the -Bsymbolic linker flag6.

that would be all.

  1. which is arguably a plus for a system daemon
  2. which returns an integer for I don’t know which reason
  3. which returns a GType for the JsonObject boxed structure, so that you can use them in properties and signal marshallers; as it happens, GType is a long lookalike
  4. or any other library that depends on JSON-GLib, like Clutter
  5. since both return values and arguments of the functions above are compatible, the linker won’t moan about it, so you won’t see any warning or error when building your code
  6. another solution is to statically link json-c inside PulseAudio instead of dynamically linking it; another solution is to link json-c with -Bsymbolic; yet another solution would be for PA to not use a dependency to parse JSON – or drop JSON entirely because I can’t for the life of me understand why an audio server is dealing with JSON at all

by ebassi at September 16, 2013 01:36 PM

September 10, 2013

Ross Burton

Using netconsole in the Yocto Project

Debugging problems which mean init goes crazy is tricky, especially so on modern Intel hardware that doesn’t have anything resembling a serial port you can connect to.

Luckily this isn’t a new problem, as Linux supports a network console which will send the console messages over UDP packets to a specific machine. This is mostly easy to use but there are some caveats that are not obvious.

The prerequisites are that netconsole support is enabled, and your ethernet driver is built in to the kernel and not a module. Luckily, the stock Yocto kernels have netconsole enabled and the atom-pc machine integrates the driver for my hardware.

Then, on the target machine, you pass netconsole=... to the kernel. The kernel documentation explains this quite well:


        src-port      source for UDP packets (defaults to 6665)
        src-ip        source IP to use (interface address)
        dev           network interface (eth0)
        tgt-port      port for logging agent (6666)
        tgt-ip        IP address for logging agent
        tgt-macaddr   ethernet MAC address for logging agent (broadcast)

The biggest gotcha is that you (obviously) need a source IP address, and netconsole starts before the networking normally comes up. Apart from that you can generally get away with minimal settings:


Note that apparently some routers may not forward the broadcast packets correctly, so you may need to specify the target MAC address.

On the target machine run something like netcat to capture the packets:

$ netcat -l -u -p 6666 | tee console.log

If you get the options wrong the kernel will tell you why, so if you don’t get any logging iterate a working argument on an image that works, using dmesg to see what the problem is.

Finally instead of typing in this argument every time you boot, you can add it to the boot loader in your local.conf:

APPEND += "netconsole=@,@"

(APPEND being the name of the variable that is passed to the kernel by the boot loader.)

Update: when the journal starts up systemd will stop logging to the console, so if you want to get all systemd messages also pass systemd.log_target=kmsg.

by Ross Burton at September 10, 2013 11:21 AM

September 03, 2013

Thomas Wood

Displays Settings in GNOME 3.10


The display settings for GNOME hasn’t seen a major change since before 3.0, so with the design help of Allan Day, I had the chance to completely update the interface for 3.10. The interface now follows the new visual style of the other settings panels and simplifies tasks such as setting the primary display. It also includes simpler and clearer display indicators. Full details of the redesign, including the mockups, are available on the wiki page. Not everything is complete yet; “presentation mode” needs some additional support from the windowing system before it can be implemented. However, Wayland support is now available thanks to Giovanni Campagna’s work on Mutter and gnome-desktop, which also includes a new confirmation dialog provided by gnome-shell.


by thos at September 03, 2013 01:45 PM

August 26, 2013

Richard Purdie

YZ Engine Rebuild in Progress

As anyone reading would note, YZ hasn’t been happy recently. Its been making noises I didn’t like the sound of so I decided to pull the barrel off and take a look, the first time I’ve done so. You can do this with the engine still in the bike. The first thing of note was the piston, the exhaust side was unremarkable but the inlet side had fairly deep scoring, above what I’d consider normal:

Its a widely accepted fact of life that two stroke engines do need maintenance from time to time and with two years of (ab)use, I can hardly complain and I’d expected it would need a piston. The barrel didn’t photograph well but I think its probably serviceable which is a relief as getting a new coating put in is a pain. I had removed the piston so I turned my attention to look at the bottom end of the engine and specifically the big end bearing:

The big end was fine however in checking it, I thought the little end felt like I’d filled it with sand. A closer look revealed:

Which is something I’d not expected, the little end is to put it technical engineering terms, knackered. I’ve damaged two stokes in a multitude of different ways but I’d never broken a little end bearing until now. First time for everything I guess. Sadly, with damage like that a new con-rod is needed and that means splitting the casings to get the crank out. That in turn means taking the whole engine out the bike. To do that there are a number of serious nuts that need undoing. It was one of these that I previously managed to snap ligaments in my hand whilst attempting to undo. This time around with having the barrel off, its possible to rather robustly brace things to stop them turning:

This may look abusive but the little end is already broken so it can’t really damage much else. The bike looks rather sorry for itself without the engine. You can see from the photo how spindly the frame is which makes more sense when you realise the engine is actually part of the frame (a stressed member):

So I’ve found it needs a new piston and a new con-rod but why was the bike rattling? My best theory so far is the power valves are also in need of attention. The push rod from the bottom to top end is loose and the free play in it could account for the rattle. The fact it doesn’t work directly as engine rpm changes also matches well with the symptoms. In looking at the valves themselves on the workbench, it was clear the left hand valve was not completely closing. Wear in the power valve cams and the cam following pins would appear to account for this. In an ideal world, I would just replace all these parts however to do so looks like adding hundreds of pounds to the repair bill. I think there is adjustment which would allow the free play in the cams to be taken up, the push rod may need to be replaced however.

A photo of the engine partially dismantled on the workbench. I can’t split the casings until I find a puller to take the ignition off. The cams are on the left and right of the square oily opening on the barrel. The followers are on the ends of the forks on the black thing on the workbench on the bottom left.

It could be a lot worse, something could have seized whilst it was running and caused considerably more damage. Finding reasonable priced spare parts seems to be a bit of a challenge and I haven’t figured out what to do with the power valves yet. The YZ has some life left in it yet and will live again!

by Richard at August 26, 2013 06:51 PM

August 17, 2013

Richard Purdie

My Centennial Rally Experience

A while ago I volunteered to help out with marshalling at the centennial rally which is up in and around the north this weekend. Saturday they were going into Kielder/Wark forest so this morning it was an early start. I met up with some fellow TRF members and together we made our way out to Gisland and up past Spadeadam. I volunteered to take the fuel for the group in the discovery into the forest. So far so good.

On the way in, I hit a deep pothole and stotted bike off the back window of the discovery. On the one hand it has marked the glass, on the other it didn’t smash it, how I don’t know. I made a mental note to take it easy even if at this point crazy forest worker come marhsals towing trailers with quads on appeared and were flying around and asking if I’d left the hand brake on.

So we found where we needed to be, I unloaded, kitted up and found the others. We were to be on course in the special test. Two roving posts at the start/end and a static in the middle. I took the first stint on the static and was there for a couple of hours, I had been promised some relief and it did come. I then roved around the end section a bit. There was a corner the bikes seemed to be having trouble with where many were going straight on into the grass and a nice deep ditch which I helped pull several out of.

The day had started off dry, turned into a drizzle and then by now was a near constant light rain. The rain eventually ran into the boots since I’d put the trousers into them, to try and avoid ripping them into any more shreds on the YZ kickstart. I gave up on the googles and just let my glasses get wet.

At one point I was offers a trip down a “hard” short cut, I suspect I made a bit of a fool of myself since I was going slowly, coming off and then was too worn out to continue. At this point someone else got the bike out of the rut I was stuck in, making it look easy. They did check it if was a 125 or a 250 to know how much throttle to give it :) I’m sure I could have done that myself, had I been able to get enough oxygen into my blood stream to think clearly. Anyone who is honest about their first off road experiences on bikes will know the vicious circle of come off, tire getting things back on track, come off again because you’re tired and so on. Its been a while since I suffered quite like that. I couldn’t suppress a chuckle when the two I was following both came off themselves.

By this point, the YZ was making worrying engine noises, there is something wrong, the next suspect is the power value mechanism since it doesn’t seem to be coming into the raw power it should (not that is mattered on a day like this!). I also found I’d run out of back brake pads.

Being rather wet by this point, it was good when we figured out the course was closed and we helped demark it. It was then a case of loading the bike onto the discovery, finding some dry clothes and heading home. I went back out via Spadeadam so I could drop the fuel back to the others.

Driving on the forest fire roads on the way out, I wondered if something wasn’t quite right. I’ve had this feeling on previous occasions driving the discovery off road and this time told myself to ignore it, every little noise makes my jumpy. I could see the bike was fine in the mirrors and the car seemed level and all that. The stability control light did briefly light on one occasion accelerating which seemed odd.

As soon as I reached tarmac, I knew something was very wrong. Having stopped and walked around I noticed a not very happy looking tyre which was clearly written off. No problem, reverse into the layby to get off the road and I’ll have to change it for the spare.

Reversing into the layby totally destroyed anything that remained of the tyre. Ok, no use crying over spilt milk. I calmly flicked through the owners handbook to the section on changing a tyre. Firstly, I have to say that whoever wrote it should get a different job, preferably after being made to change a tyre in the pouring rain. Its full of things like explaining how to jack the car, then mentioning that before jacking you should loosen the wheel nuts. The main reason I was reading it was to figure out where the tools were, how to release the spare wheel and what to do with the self levelling air suspension.

Obviously the jack and tools were in a compartment in the rear of the car, with piles of wet bike gear filling the boot and the boot door inoperative due to the bike on the rack on the back. There was also 85L of petrol in the way amongst tools and all kinds of other junk. I also noted with dismay that to lower the spare wheel you need to access a winch under the rear two pop up seats, which have all this stuff on top of them. I would also note it is raining, it would be, right!

To cut a long story short, I did manage to move things around, I was able to jack the car up, put the spare on, stow the shredded wheel and continue home. The self leveling suspension did quite an amazing job of hiding the flat. I bought the discovery to use and have a bit of adventure with so I guess I’m getting that and these things happen. Nobody can accuse me of not using it as it was designed or call it a Chelsea Tractor! :)

I am now totally worn out, I think I’ll need to take it easy for a few weekends and I’ve some work in the garage to do now. I haven’t dared closely inspect the rim yet, if I’m lucky, it might be ok, we’ll see tomorrow. Marshalling tomorrow? I think not.

by Richard at August 17, 2013 10:12 PM

August 16, 2013

Michael Wood

Q Light controller 64bit deb

I’ve rolled a 64bit deb for Q Light controller I “fixed” some missing includes/distcheck type issues to make it build the modified source is here

by Michael Wood at August 16, 2013 02:12 AM

August 07, 2013

Richard Purdie

The 675 for a change

On Sunday with Cadwell coming up it made sense to check the 675 still works and scrub in its new tyres a little. Scotland seemed the logical direction choice. I’d started heading for Morpeth/Rothbury and then found myself in the middle of a cycle event which seemed to head to Bellingham. I’d not have liked to be cycling up some of those hills. The roads seemed otherwise quiet.

Going past Kielder, the fuel warning light came on, I’d evidently incorrectly ‘remembered’ filling the bike last time I used it :( . This is about the worst place to run out of fuel as there isn’t any for many miles, particularly on a Sunday. I was closer to Scotland at this point so continued to head for the border, it being touch and go whether I’d reach anywhere selling fuel. I remembered someone telling me the old garage at Kielder had reopened so there was a small chance that would be open and I’d be passing it anyway.

Going past the garage at Kielder the garage looked deserted and shut, the signs said open. The fuel pump looked odd. I’m pleased I stopped and checked as its now an automated self service one and I could get fuel there which solved my worries about running out.

It was then into Scotland and onto roads which were mostly single track with passing places ending up in Hawick which was the planed refuelling stop. Since I wasn’t in a hurry, I then looked around some roads over to Langholm and Newcastleton using some further minor single track roads going from the Scottish Borders into Dumfries and Galloway and back before heading back to Kielder in my native Northumberland and then home via Chollerford. The weather was mostly good with odd rain showers, the only one I really got wet in was near Langholm (hence the dark photo) other than that there were just wet roads as evidence of them.

It was nice to use the 675 again, I do love that bike although I’m not used to the riding position any more which was comparatively painful, particularly after the couple of hundred miles I covered on this trip. The 675 behaved well and the new tyres seem good although it has a few squeaks for example in the air intake mechanism and will benefit from a good service.

by Richard at August 07, 2013 07:31 AM

August 05, 2013

Richard Purdie


I’ve had some extended vacation time recently and shortly I’m probably going to get questions about how I enjoyed it. It would be tempting to nod and smile and quickly change the subject since the answer I’d truthfully give is hard to understand and not what people would want to hear or expect, I’ve actually found it rather like a form of torture.

Its an open secret that for whatever reason I seem to suffer from some kind of fatigue. There is no known medical explanation for it, the catch all “we don’t know” of chronic fatigue syndrome (CFS) being the “diagnosis” once you rule out everything else. So what does that mean in practise? Imagine having a finite store of energy which replenishes at a fixed rate. As long as I use it carefully at a rate approximating the replenishment rate I’m perfectly fine. If I do something strenuous, I need to go easier for a while to allow the store to replenish and for example with the motorcycle trail riding, there will be a mild price to pay (say approximating flu like symptoms the following day). The real problems start if you use up a large amount of the store, I’ve experimented to varying degrees and near involuntary collapse followed by a week of feeling like you were badly beaten in a boxing ring is a possible outcome. I’ve carefully improved my general health and fitness over the past few years in the hope it would help. Sadly the size of the store or rate of replenishment doesn’t seem to change, even if I’ve noticed significant other improvements in my general fitness.

A colleague recently posted about being unable to do nothing and I had to smile since I share this “problem”. Combine this with the fatigue and you can see where this is going. There are a ton of things I want to do yet I know that if I try and do them, there will be a price to pay. The availability of extra time puts temptation in place and to be honest, I’ve totally overdone the activities and physically feel like a wreak now, yet I haven’t used the time as fully as I’d have liked either.

So if you ask me if I enjoyed my vacation and I laugh you might better understand why. That isn’t to say I haven’t done some things I’ve wanted to do for a while or enjoyed. I also appreciate things could be much worse too!

by Richard at August 05, 2013 11:30 AM

August 02, 2013

Richard Purdie

Historic Karting at Rowrah

For five years my kart (CR250 powered) has been buried behind mountains of “stuff” at the back of two different garages quietly dreaming of once again driving on open tarmac. Partly this has been a time issue, partly its due to not being able to drive it on any of the local circuits after they deemed gearbox karts too dangerous on them.

The kart is “only” 19 years old and is water cooled so is frowned upon in historic kart circles however I was invited to attend their annual meeting over at Rowrah last weekend. The circuit is my favourite kart circuit since its somewhere unexpected (a national park) and is picturesque, nestled in the bottom of an old quarry. Since I was last there (must have been years) they have built a new clubhouse replacing the corrugated iron shack I remember of a canteen and generally improved facilities there.

Prior to the event I’d cleaned out the carb and fuel lines, found slick tyres for it, filled it with coolant and was pleased to find it started up on the rope without any real issue. My Dad was also there with two karts, one a Bellotti with a air cooled ‘red rocket’ CR250 on it, the predecessor to my kart’s engine and the other, the cougar, a kart from 1979 which has its main components manufactured then but was only recently brazed up on the jig which was dug out from under a compost heap. This was the Cougar’s first outing after several late nights last week finishing putting it together.

After arriving on the Friday night and meeting some people I’ve not seen since the School’s Karting Association (SKANE) days and a good night’s sleep on the top of a hillside, the Saturday had beautiful weather. The sessions were alternating between class ones and class fours, 20 minutes each. That is ancient terminology for 100cc direct drives (ick) and then anything with a gearbox (the proper karts).

Basically my kart performed wonderfully given its condition, the only issue was that it was geared for long circuit (26:30) and I was only using the first 2.5 gears. There were some modern 125cc karts there which were thrashing me on acceleration. Initially I decided to ignore this but I appear to have some kind of competitive spirit as I ended up taking the sprockets off and changing to 26:36 which was chosen from the available sprockets and chain availability. This gave me 4 gears and made a massive difference to keeping up with the modern 125s as I could now act as a road block and keep up with them. I’m not sure I could have overtaken one, would have needed better gearing again for that but I was happy enough.

I played in various sessions, torn between pushing the kart and not wanting to break it, particularly the engine. I soon realised that the back bumper had cracked around the radiator mounting on one side, an age old problem its suffered with since forever however I decided to ignore that. I was less able to ignore the squealing the kart was now making under braking. A quick check showed the rear pads were not looking healthy, it turned out one has partially disintegrated:

thankfully, I’d taken a set with me having realised the pads were low and even had the cordless drill to make the oval hole round on the new pads to fit.

I tried Dad’s red rocket and it was fun, the engine makes much more sense on that chassis that some of the others we’d had on it 10 years ago in the SKANE days (2.5 YZ125s reduced to shrapnel in the end). We then turned attention to the cougar, the engine fired up no problem although pushing it up the hill to start it was hard work as the brakes were new and binding a bit. Dad took it out onto the track and it threw the chain. Hmm. We replaced that and tried again. As I was push starting it, I had a hand on the engine and as it fired and set off, I noticed the engine move 4″ sideways. My brain registered that it shouldn’t do that, ever. I signalled for Dad to stop and we found the engine mounting posts had sheared from the chassis, the engine literally now able to fall off. Game over for the weekend but it can and will be fixed and the weekend was always meant as a shakedown for it.

The memories of how to drive a kart came back, I only spun once over the weekend and kept the engine running. When chasing 125s, I did run wide off the chicanes onto grass on a few occasions and despite effectively rallying the kart, kept it on full throttle and didn’t lose ground. I suspect I’m channelling some of its former rally driver owner there (who’s name is still on the front bubble).

At this point I was bruised and battered from bouncing around in the seat, a seat bolt finding a particular connection with my ribs which were now visibly bruised along with my left shoulder blade. I had quickly resorted to driving with a towel wrapped around my waist but even that didn’t stop things. Dad took plenty of photos and I also swapped roles and took from photos of him in kart for a change, venturing out onto the circuit in the high-vis with a camera much to the bemusement of people (its usually Dad doing this).

It rained heavily over night and part of the Sunday morning, I wasn’t optimistic the track would dry but it did. I hadn’t slept too well due to the bruised ribs and shoulder. I did get out a bit more on the track and was pleased with the kart holding its own apart from against a particularly quick twin 250. One of the things which I regret from the SKANE karting days is there weren’t many photos despite hundreds of hours in the various karts. I now at least have some photos of my in the 250 thanks to Dad, its only taken 20 years to get them!

by Richard at August 02, 2013 11:23 AM

Robert Bradford

GUADEC: Wayland talks today

The order of the Wayland talks are going to be flipped compared to the printed schedule. This means my introductory talk to Wayland will be before the panel discussion which should give valuable background for the subsequent discussions. Hopefully see you there!

by robster at August 02, 2013 09:01 AM

Richard Purdie

More wheels than normal

I’ve been wanting to try this since I brought the Discovery. Last Friday on my way elsewhere with a full load of karting stuff in the back I took it over Long Cross since I was passing. This is a steep rocky climb with no tarmac surface, just rocks. I decided not to stop for photos on the steepest/most technical bits and the sun was in the wrong direction but you get the idea from these. I was impressed with the way it handled things as it never missing a beat. Stopping and starting again wasn’t a problem anywhere and it slowly but surely crawled its way up and over everything.

One thing which didn’t impress me is when I took it out of low range and the rock crawl mode at the top of the hill, it also decided to drop to normal suspension height itself without prompting. This lead to the vehicle grounding out which was annoying, the towbar/bike rack mount took the brunt of it.

I think the weirdest feeling of all was after this, feeling bumps and twists through the steering, driving back onto tarmac and resuming 60mph cruising of twisty roads up and over Hartside and into the lake district. It feels so at home on both.

The size does make things interesting on some of the narrow roads over in the lake district but it also has its moments where it shines. For the trip back there had been heavy rain which had washed large gravel onto the A686 but this wasn’t a problem. Hitting a few inches of water flowing over the road at speed was also interesting, its the first time I’ve felt it thinking about aquaplaning but the main issue being its tendency to seemingly remove all the water from the road and put it on the windscreen making seeing where you’re going trickier. All in all I’m quite enjoying it!

by Richard at August 02, 2013 08:54 AM

July 30, 2013

Robert Bradford

The Waylanders are coming

This GUADEC there will be a couple of sessions on Friday afternoon from 2pm about Wayland. I’ll be giving a presentation with a brief introduction to what Wayland is, what new features we’ve worked on in the last cycle as well as what’s planned for the next one. As this is GUADEC i’ll of course be covering how we’re doing with getting Wayland integrated into GNOME. There will also be a Wayland panel discussion where you can ask your tricky questions of myself, Owen Taylor, Robert Bragg and Kristian Høgsberg – to get things started i’ve got some already prepared!

And if that’s not enough Wayland for you, on Monday we’ll be BoF’ing between 10am and 2pm in room A218. It would be great to see you there.

by robster at July 30, 2013 03:16 PM

July 22, 2013

Richard Purdie

Trail Riding in the Yorkshire Dales

Whilst I know some of the roads and places from road motorcycling and camping I’d never been trail riding in the Yorkshire Dales so when the offer came up, I was happy to accept. We met up on the A1 and made our way to Leyburn which was to be our starting point.

I was with a group of people I’ve not really ridden with before, often just passing out on trails so it was a nice change and they seemed like a friendly enough bunch! :)

I had no idea what kind of terrain to expect and it turned out to be quite rocky, kind of like the lake district but quite different too. This meant learning a new kind of surface which is always interesting.

I thought I might have gotten away with my rather worn front tyre, in hindsight, I should have changed it as it caused problems with a lack of grip and confidence. The YZ’s gearing was also suboptimal for that kind of terrain and as I couldn’t go slow enough yet have the engine behaving comfortably.

Whilst there had been rain overnight and there was plenty of cloud cover, it was dry and the trails were hence very dusty. At least the cloud cover kept the temperature reasonable.

The trails themselves were rather nice for a change with some interesting variety of different types. Unfortunately one of the group started having problems with a rear tyre puncture. Attempts were made to pump it up but it became clear this couldn’t be sustained. Shortly after that, after being stopped my bike started rattling. It was hard to figure out where it was coming from but it became clear it was from the engine which is never good.

It seemed to be coming from the kickstart area but inside the casing so we did take the clutch cover off to see if anything untoward could be spotted but there wasn’t anything visible. I therefore made the decision just to ride it and see what happened. Through several more trails it became clear that the rattle only happened when the clutch lever was engaged. Clearly this meant I should just not use the clutch so I switched to clutchless/crash gear changes. Unfortunately the gearing made use of the clutch unavoidable on some uphill sections but on the plus side, the noise didn’t seem to get any worse.

At the lunch and fuel stop in Hawes they patched the problematic rear tyre and I noticed my brake light lens had been smashed and gone missing at some point. We set off for the return journey with the warning that an “interesting” uphill section was coming up and a comment about stopping for photos. For the newbie who has never ridden the trail, this is always a good sign.

Initially it didn’t seem so bad but it did indeed have an interesting section. I decided to try and save the clutch but ended up stalling, I turned around to see the person following then falling off in sympathy (sorry)! Once I’d decided to (ab)use the clutch and got going again, I made it up the rest of the steep section without incident other than stalling it again in relief having made it up the worst bit!

Some of the trails are quite a decent length, some of them being old Roman roads and the Yorkshire Dales scenery is spectaular as ever. Sadly I don’t have many photos as I seemed to be going slower than others for whatever reasons and it wouldn’t have been fair to stop the group to get the camera out.

Sadly the patched tube didn’t hold up and we ended up stopping again to change it and put a spare front tube in the rear wheel to replace it. There appeared to be a trials event going on over that section of trail. Changing the tube over seemed easier this time, perhaps as the tyre was loosened up already.

With the various stops we were a little behind schedule but we did decide to put the final loop of trails in and I’m pleased we did since I think these were the most enjoyable of the day for me. The surface was a different type of stone and for some reason I and the bike were a lot happier on it. There were a couple of small fords and some massive eroded tracks. I’ve never seen a road eroded before the “unsuitable for motor vehicles” sign like that before, it did get even worse after the sign too although not enough to trouble an appropriate motorcycle, just made it more interesting. It was they back to Leyburn, load the bike onto the disco and time to head home.

I’m grateful to the group who took me out, I hope I didn’t hold you up too much and thoroughly enjoyed going somewhere new, and being with some different people too!

by Richard at July 22, 2013 02:24 PM

Lake District Trails

The Lake District is a place I haven’t been as often as I’d like recently. I’ve spent school holidays camping there, sailed on its lakes, raced karts in one of its quarries and ridden motorcycles over its passes. I’ve don’t comparatively little trail riding there though so when the opportunity came up I decided to go for it.

It meant an early start so I loaded the bike onto the bike rack the night before. We met up near Tebay after an uneventful trip on the A69 and M6 which the Discovery coped with nicely. Parking wasn’t a problem since I’d have been complaining to trading standards if it couldn’t get itself back off a grass verge!

There were four of us, we met up and the first shock of the day was one of the bikes tank ranges, at 45 miles which is worryingly low. We set off and the first trail of the day was Breast High road. There is an interesting slimy ford near the start which caused some fun and is good for catching riders who haven’t quite woken up yet, we all did make it through without an early bath.

There is a photo of my only other attempt of Breast High road where you can just see the underside of my bike and I’m lying on the other side of it, I’d hoped to do better today. The road is covered in comparatively large rocks which are hard to ride over since they’re big enough to deflect the bike. I passed one of the group who’d fallen off but was ok, shortly after that I managed to hit a rock which bounced the front wheel off the edge of the track. I did the sensible thing and stood off the bike whilst it plunged over the edge and onto its side, ending up lying there teetering on the edge.

Given some time to think through the recovery all would be ok however the bike was leaking fuel rapidly and the fuel tap was under the bike so I couldn’t get to it to shut it off. I therefore made the decision to lift the bike and it started off over the edge again, the front brake wouldn’t hold it. I therefore decided to let it find its own way down the 10ft drop and which point it was still on its side leaking fuel :/. This time I could lift it, roll it into some handy rocks to stop it and start to think about how to get back onto the trail. I gave the fallen rider I’d passed a thumbs up as he went past at this point, it being clear I’d had an issue given the bike was pointing the wrong way and I was off the track. Once I’d caught my breath, I was able to get back onto the track and continue up past where I fell off last time (another rider was off there today) and continue up to the top.

The trip down the other side was less eventful and there wasn’t that much water in the ford on the other side. We covered a few more trails and then stopped to discuss where the turning for the next trail might be. We were navigating with a paper based route but I was tracking it on the GPS and it was interesting comparing the two to figure out where we were since my GPS had no useful basemap of the area. We were in one of two places and decided and as it turns out, we picked the wrong one so ended up with the mandatory U turn. I also noticed one of the bikes was chucking out a lot of oil like smoke to the point it looked like a two stroke yet I knew it was a four. At the next stop, I mentioned this to the rider.

We set of again and found the lane we were looking for however half the group was missing. We turned back and found the smoking bike now wouldn’t start, seemingly with a lack of electrical charge. We tried bump starting it but we couldn’t find a problem, or get it going so we towed it to a junction with decent signposts and they called their recovery policy. Then we were three.

We made it to the first garage at 47 miles so we never did get to test the 45 mile tank range since it had broken down first. After a quick food/drink stop, we continued on looping around the southern lakes and then northwards towards Coniston Water. We stopped and chatted to some other trail riders but didn’t see much in the way of walkers or other road users, presumably the baking hot weather had put them off.

One interesting moment of the day was on a nice single track tarmac road which weaved both horizontally and vertically. I had to admit I’d underestimated how much it did so and ended up feeling like the bike was rather light on traction with a trajectory projection heading towards the grass verge. I remember thinking that as vehicles go, this was not a bad one to have that issue on and that I’d aim for the tarmac/grass join which I targeted correctly and continued without incident. I’m reliably told by the person following that “rather light” was in fact airborne, oops.

We then headed up through Grizedale and over to the Langdale area where we did see a few more people and a chain of 4×4s. The route ended up cut a little short since it was now after 6pm and we needed to get back as we looped around and then back over Breast High Road. I made a better job of getting back over it than I had that morning (or its easier going to other way). This is the first time I’d done it the other way since we’d “shortcut” our way back on the previous Lake District trip using the M6 instead of going back over it.

For the return trip, I took the Discovery complete with bike on the rack along the A686 over Hartside. I have to admit I also thoroughly enjoyed doing it. For a vehicle as heavy as it is, you can’t often feel the weight with the engine power, brakes and power steering hiding it and having beautiful handling for something of the size. You do however notice it going down hills since it picks up speed like crazy. Despite some spirited driving, enjoying the road, the bike rack held the bike solidly, I was quite impressed.

The A686 has some hairpin bends and it was amusing to note that with the weight of the bike on the back, putting the power down on hard lock uphill on the hairpins did get the front end slipping. You could feel the electronics waking up and taking note :) . I’ve been noticing that sliding in a 4 wheel drive is something quite unlike anything I’ve ever driven too since it can do all wheel powered drifting and the stability control system seems either unable to detect it, unable to do anything about it, or probably both.

All in all I thoroughly enjoyed the day although it was very hard going (in all senses) and I ached for days afterwards. Thanks to Phil for leading!

by Richard at July 22, 2013 02:24 PM

July 16, 2013

Robert Bragg

Rig 1 - A UI designer & engine

For anyone interested in graphics and in the design of user interfaces (UIs) I hope I can invite you to take a look at our release of Rig 1 today. Rig 1 is the start of a new design tool & UI engine that I've been working on recently with Neil Roberts and Damien Lespiau as a means to break from the status quo for developing interfaces, enabling more creative visuals and taking better advantage of our modern system hardware.

In particular we are looking at designing UIs for consumer devices with an initial focus on native interfaces (device shells and applications), but also with an eye towards WebGL support in the future too.

With Rig we want to bring interactivity into the UI design process to improve creativity and explore the possibilities of GPUs beyond the traditional PDF drawing model we have become so accustomed to. We want to see a design work flow that isn't constrained by the static nature of tools such as Photoshop or mislead by offline post-processing tools such as After Effects. We think designers and engineers should be able to collaborate with a common technology like Rig.

Lets start with a screenshot!

This gives you a snapshot of how the interface looks today. For Rig 1 our focus has been on bootstrapping an integrated UI design tool & rendering engine which can showcase a few graphics techniques not traditionally used in user interfaces and allows basic scene and animation authoring.

If you're wondering what mud, water, some trees and a sun have to do with creating fancy UIs; firstly I should own up to drawing them, so sorry about that, but it's a sneak peek at the assets for a simple "Fox, Goose and Corn" puzzle, in the style of a pop-up book, we are looking to create for Rig 2.

I'd like to highlight a few things about the interface:

It all starts with assets:

On the left of the UI you see a list of assets with a text entry to search based on tags and names. Assets might be regular images, they could be 3D meshes, they could be special ancillary images such as alpha masks or normal maps (Used for a technique called bump-mapping to give a surface a perturbed look under dynamic lighting).

Assets don't have to be things created by artists though, they might also be things like scripts or data sources in later versions of Rig.

The basic idea is that assets are the building blocks for any interface and so that's why we start here. Click an asset and it's added to the scene and assets can sometimes even be combined together to make more complex things, which I'll talk more about later.

Direct manipulation:

In the center is the main editing area where you see the bounds of the device currently being targeted and can directly manipulate scenes for the UI being designed. We think this ability to directly manipulate a design from within the UI engine itself is going to be a cornerstone for enabling greater creativity since there is no ambiguity about what's possible when
you're working directly with the technology that's going to run the UI when deployed to a device.

These are the current controls:
  • Middle mouse button to rotate the whole scene
  • Shift + middle mouse to pan the scene
  • '+' and '-' to zoom in and out
  • Left click and drag to move an object (object should not already be selected)
  • Left click and drag a selected object to rotate
  • Ctrl-Z and Ctrl-Y for Undo and Redo respectively
  • Ctrl-S to Save the current document

In-line previews...

Without leaving the designer it's possible to toggle on and off the clutter of the editing tools, such as the grid overlay, and also toggle fullscreen effects such as the depth-of-field effect shown here.

Currently this is done by pressing the 'P' key.

Editing properties:

Properties are another cornerstone for Rig but first I should introduce what Entities and Components are.

A scene in Rig is comprised of primitives called entities which basically just represent a 3D transformation relative to a parent. What really makes entities interesting are components which attach features to entities. Components can represent anything really but examples currently include geometry, material, camera and lighting state.

When you click an asset and that's added to the scene, what actually happens is that we create a new entity and also a new component that refers to the clicked asset which is attached to the entity. The kind of component created depends on the kind of asset you click. If you click an asset with an existing entity selected, that lets you build up a collection of components attached to a single entity.

Each component attached to an entity comes with a set of properties. The properties of the currently selected entity and those of all attached components are displayed on the right hand side of the interface. The effect of manipulating these properties can immediately be seen in the main editing area.

The little red record button () that you can see next to some of the properties is used to add that property into the current timeline for animating...


Once you've built up a scene of Entities then authoring animations is pretty simple. Clicking the red record button of a property says that you want to change the property's value over time and a marker will pop up in the timeline view at the bottom. Left clicking and dragging on the timeline lets you scrub forwards and backwards in time. If you scrub forwards in time and then change a recorded property then a new marker pops up for that property at the current time. Left clicking markers lets you select and move marks. Property values are then automatically interpolated (tweened) for timeline offsets that lay in between specific markers.

These are the current timeline controls:
  • Left click lets you scrub the current timeline position
  • Left clicking markers lets you select marks; Shift + Left click lets you select multiple markers
  • Left clicking and dragging lets you move selected markers left and right
  • Delete lets you remove markers
  • Ctrl-Z and Ctrl-Y also let you undo and redo timeline changes


We started with a fairly conservative set of effects for Rig 1, opting for effects that are well understood and widely used by game developers. This reduced some of the initial development risk for us but there is a chance that our choices will give the impression we're simply trying to make UIs that look like console games which isn't the intention.

Modern GPUs are extremely flexible pieces of hardware that enable an unimaginably broad range of visual effects, but they are also pretty complex. If you really want to get anything done with a GPU at a high level you quickly have to lay down some constraints, and make some trade-offs.

The effects we started with have a long history in game development and so we know they work well together. These effects emphasize building photorealistic scenes but there are lots of non-photorealistic effects and generative art techniques we are also interested in supporting within Rig. Since these are more specialized we didn't feel they should be our first focus while bootstrapping the tool itself.


I'm sure you can guess what this effect enables, but here's a video anyway that shows a 3D model loaded in Rig and how its colour changes as I rotate it or if I change the lighting direction:

Although I don't envisage using glaringly 3D models for core user interface elements I think there could be some scope for more subtle use of 3D models in live backgrounds for instance.

Shadow mapping

Shadow mapping is a widely used technique for calculating real-time shadows that basically involves rendering the scene from the point of view of the light to find out what objects are directly exposed to the light. That image is then referenced when rendering the objects normally to determine what parts of the object are in shadow so the computed colours can be darkened.

Shadows can be used to clarify how objects are arranged spatially relative to one another and we think there's potential for user interfaces to use depth cues perhaps to help define focus, relevance or the age of visible items but also for purely aesthetic purposes.

Bump mapping

This is a widely used technique in game engines that lets you efficiently emboss a surface with bumps and troughs to make it more visually interesting under dynamic lighting. For an example use case in UIs, if we consider where we use simple silhouette emblems in UIs today, such as status icons you might be able to imagine introducing a subtle form of lighting over the UI (maybe influenced by touch input or just the time
of day) and imagine the look of light moving over those shapes.

Rig provides a convenient, standalone tool that can take an image and output a bump map, or take a bump map to output a normal map. These examples show an original icon, followed by its bump map and then its normal map:

Note: There are sometimes better ways calculate normal maps for specific use cases but this tool at least gives us one general purpose technique as a starting point. An artist might for example at least want to hand tune the bump map before generating a normal map.

This video shows the gist of what this effect enables, though for a more realistic use case I think it would deserve a more hand-tuned bump map, and more suitable texture mapping.

Alpha masks

Rig provides a way to associate an alpha mask with an entity that can be used to cut shapes out of an image and since the threshold value (used to decide what level of alpha should act as a mask) can be animated that means you can also design the masks with animations in mind. For example if you have a gradient mask like this:

If we animate the threshold between 0 to 1 we will see a diagonal swipe in/out effect applied to the primary texture.

This video shows a simple example of animating the threshold with two different mask assets:

Depth of field

Rig implements a basic depth of field effect that emulates how camera lenses can be made to bring a subject into sharp focus while leaving the foreground and background looking soft and out of focus.

This example video alludes to using the effect for moving focus through a list of items that extends into the depths of the screen.


At this point Rig can be used for some kinds of visual animation prototyping but it isn't yet enough to create a standalone application since we can't yet incorporate application logic or data.

Our priority now is to get Rig to the point where it can be used end-to-end to design and run UIs as quickly as possible. As such we're defining our next milestones in terms of enabling specific kinds of UIs so we have concrete benchmarks to focus on.

Our next technical aim is to support application logic, basic input and the ability to interactively bind properties with expressions. As a milestone benchmark we plan to create a Fox, Goose and Corn puzzle, chosen due to its simple logic requirements and no need to fetch and process external data.

The technical aim after that is to support data sources, such as contact lists or message notifications as assets where we can interactively describe how to visualize that data. The benchmark for this work will be a Twitter feed application.

I'm particularly looking forward to getting our ideas for data integration working since the approach we've come up with should allow much greater creativity for things like showing a list of contacts or notifications while simultaneously also being naturally efficient by only focusing on what's visible to the user.


So hopefully if you read this far you are interested in what we're creating with Rig. We're hoping to make Rig appeal to both Designers and Engineers who are looking to do something a bit more interesting with their interfaces. I'd like to invite the brave to go and check out the code here, and I hope the rest of you will follow our progress and feel free to leave comments and questions below.

by Robert Bragg ( at July 16, 2013 12:05 PM

July 15, 2013

Robert Bradford

Wayland & Weston 1.2.0 is out

The latest release of the Wayland protocol and support library along with the Weston compositor is now out. For the GNOME community this release is particularly interesting:

  • It is the first one to advertise a stable API for the implementation of compositors (libwayland-server) – which will prove useful with the porting of gnome-shell & mutter to Wayland
  • Two new protocol enhancements have been staged for inclusion: subsurfaces from Pekka Paalanen which will be the basis for implementing Clutter-GTK on Wayland and support for input methods from Jan Arne Petersen. These are not yet in the core of the Wayland protocol but will be moved there when the API has been proven.
  • HiDPI support – Alexander Larsson implemented this for Wayland and GTK+ too

At GUADEC i’ll be speaking about the current state of the Wayland project and plans going forward. If you have a particular topic or question you’d like me to cover please let me know in the comments.

by robster at July 15, 2013 01:06 PM

Robert Bragg

Rig Status Update

I've been continuing my work on the Rig project I introduced back in September, as well as helping add Wayland support to GnomeShell, and was feeling bad that I haven't made time to post about the progress of either project and so wanted to give a quick status update for Rig...

I think the easiest way to get a quick idea of how Rig has been shaping up is this overview video I made back in May that goes over the initial UI layout and features:

The main thing that's been changing UI wise since I made that video is that the bottom area is evolving beyond just timeline management into an area for "controllers" that must handle more then simple key-frame based animations.

Controllers will support several methods of controlling properties, where key-frame animations would be one way, but other methods would be physics simulation, expressions that relate properties together and all manner of other high level behaviours. As an example of a behaviour Chris Cummins, one of the interns I've been working with, is experimenting with a Boids based flocking simulation which might offer us a fun way to introduce emergent, nature inspired aesthetics to the backdrop of a device.

Probably the biggest architectural change in Rig is that it's now designed to be connected directly with a device that you are designing for to enable immediate feedback about performance, responsiveness and quality on real target hardware. We've added a networking layer using avahi and protocol buffers to discover devices and for synchronizing UI changes made in the designer with the device.

Rig is aiming to help optimize the workflow of UI development and it seems that one of the biggest inefficiencies today is that interaction and visual designers often use tools that are completely unconstrained by the technologies and devices that will eventually be used to realize their ideas.

Going further, the plan is to directly incorporate remote profiling visualization capabilities into Rig so that we can also allow device metrics to influence the design stages as early as possible instead of only using them as a diagnostic tool. UIs need to work within the limits of the hardware they run on otherwise the experience suffers. If we don't move to a situation where real metrics can influence the design early we either have to continue being ultra conservative with our UIs or we risk big problems being discovered really late in the development process that can either force us back to the drawing board or leave us scrambling to fix the technology under pressure.

To keep this update relatively short here's a quick run-through of the work that's been going on:

  • UI design work
    • Thanks to Mikael Metthey for his help creating mock ups for Rig, clearly a marked improvement over the very first visuals we used:

  • Device connectivity - as mentioned above.
  • Neil Roberts has worked on basic OSX support.
  • Neil also added binary update support since we'd like to aim for a browser like development model of continuously rolling out small features so once Rig is installed it will automatically evolve, getting better over time.
  • Bump mapping support for 3D models, for detailed lighting effects over complex models.
  • A pointillism effect by Plamena Manolova as a fun example of a generative art algorithm that can be handled efficiently on the GPU.
  • Default cylindrical texture mapping of models that don't have their own texture coordinates.
  • Plamena is currently implementing an algorithm for tiling images across an arbitrary mesh.
  • Plamena has added initial support for real-time fur rendering, another visual style that clearly diverges from what's achievable with the traditional PostScript rendering model.
  • Chris has been working on a particle engine.
  • Chris has also been working on a Boids simulation engine to emulate flocking behaviours. The inspiration for this basically came from an exhibition made by Universal Everything: (Full disclosure - I work for Intel, although the point here isn't the advertising, but just the idea of bringing more natural forms into user interfaces.)
  • We've made some early progress experimenting with WebGL support.
    • The low level graphics layer of Rig now supports WebGL but we have some further integration work to do still in the higher level engine code before we can really test the viability of this idea.
  • Drag & Drop, Copy & Paste - work in progress. Not having this is really getting in the way of lots of other important interaction and feature work that we need to move onto next.
Next week I'm off to Siggraph where we'll be publishing a whitepaper explaining why we feel there is a big opportunity to really raise the bar for how we manage UI development and we'll also have a short video introducing the Rig project.

I'll also be at Guadec in August and I'd love to chat with anyone interested in Rig.

I'll try not to wait so long before posting my next update here.

by Robert Bragg ( at July 15, 2013 11:23 AM

July 07, 2013

Richard Purdie

Alnwick and back

Its been a while since I’ve ridden the northern lanes from here. Even though there were just two of us interested/available to do it, I decided to go ahead since the weather was lovely for some river crossings.

We met up and set off with the run up to Alnwick being slightly more tarmac biased, stopping for fuel near Morpeth. Its always interesting to see how rivers and river crossings change over time, what was a 1m deep raging torrent I drowned the bike in last time I went through it was a silted up few inches this time!

We kept a fairly leisurely pace but that didn’t stop me sliding out a rut and falling off, first time I’ve done that for a while :/. Kept the bike running and felt ok at the time but appear to have hit the top of my pelvis with the elbow armour and have a lovely bruise there today.

One of the lanes had notices about police action against motor vehicle use so we didn’t use it and and will need to look into it what the rights are there. Near Alnwick we came across the first deep crossing which did look rather washed out. We ended up going slightly downstream to cross where it was a much more reasonable depth.

After a fuel and lunch stop in Alnwick we headed back southwards covering a lot more lanes including a few more interesting fords. I think this part of the trip really made the day for me.

The only downside was that time was getting on and many fuel places were now shut. I thought I should make it back to the start point on the fuel in the tank. There was a minor panic when the bike spluttered out of fuel but that turned out to be a kinked breather hose. A while later it needed to go onto reserve for real though.

Waiting at the bridge to cross over to the start point I glanced in the tank and fuel was conspicuous by its absence. I knew the garage at the start point was also now shut too so I headed straight for the other nearby garage that should still be open. As I waited in traffic to make the right turn into the garage, the bike spluttered completely out of fuel. I knocked it into neutral and pushed it the 5m to the fuel pump. Never have I had such a close run on fuel!

All that remained was to ride back home but there were still a couple of interesting twists left. I decided to ride through Newcastle, something I’ve never done on the trail bikes, taking a route past the football stadium. I’m still a little unclear about what happened but I think someone who had likely had a bit too much to drink decided my hand signal for a turn meant I wanted a hug and therefore ran at the moving bike with his arms outstretched. It was that or a rugby tackle. Thankfully I managed to avoid him, how I’m not entirely sure.

The final part of the route home was the coast road where I kept the bike at comparatively high speed/revs for several miles. Pulling up and stopping in the queue for the roundabout, I was looking at my shadow and noticing a strong swirling haze at the back of the bike. This caused me to turn around to see copious amounts of smoke coming from the exhaust as if something was on fire which in all likelihood, it probably was. I think the oil in the exhaust was probably burning however the engine sounded fine so I continued without unduly worrying about it.

It was an enjoyable day out, thoroughly worn out now mind!

by Richard at July 07, 2013 03:15 PM

June 21, 2013

Emmanuele Bassi

The King is Dead

I guess a lot of you, kind readers, are pretty well-acquainted with the current idiomatic way to write a GObject type. it’s the usual boilerplate, plus or minus a bunch of macros:

// header
typedef struct _MyObject MyObject;
typedef struct _MyObjectPrivate MyObjectPrivate;
typedef struct _MyObjectClass MyObjectClass;

struct _MyObject {
  GObject parent_instance;
  MyObjectPrivate *priv;

struct _MyObjectClass {
  GObjectClass parent_class;

GType my_object_get_type (void);

// source
struct _MyObjectPrivate
  int foo;

G_DEFINE_TYPE (MyObject, my_object, G_TYPE_OBJECT)

static void
my_object_class_init (MyObjectClass *klass)
  g_type_class_add_private (klass, sizeof (MyObjectPrivate));

static void
my_object_init (MyObject *self)
  self->priv = G_TYPE_INSTANCE_GET_PRIVATE (self,
                                            my_object_get_type (),
  self->priv->foo = 42;

boring stuff that everyone had to remember1. the last big change in the way people write GObject happened 10 years ago, and it was the addition of per-instance private data. it seems to me like a good way to celebrate that occasion to change this stuff all over again. ;-)

at the latest GTK+ hackfest, Alex and Ryan had a very evil, and very clever idea to solve a problem in how the per-instance private data is laid out in memory. before that, the layout was:

[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]

as you can see, the offset of the private data for each type changes depending at which point in the class hierarchy initialization we are, and can only be determined once the whole class hierarchy has been initialized. this makes retrieving the pointer of the private data a pretty hard problem; one way to solve it is storing the private pointer when we initialize the instance, and we spare ourselves from type checks and traversals. the main problem is that, in order to get to the private data faster, we need to rely on a specific layout of the instance structure, something that is not really nice if we want to have generic accessors to private data2. for that, it would be really cool if we could only have offsets to through to G_STRUCT_MEMBER().

well, it turns out that if you’re doing memory allocations for the instance you can overallocate a bit, and return a pointer in the middle of the memory you allocated. you can actually allocate the whole private data in a decent layout, and only deal with offsets safely — after all, the type information will store all the offsets for safe access. so, here’s the new layout in memory of a GObject3:

[TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]

that’s neat, isn’t it? now all private data can be accessed simply through offsets, and accessing it should be just as fast as a private pointer.

I can already see people using Valgrind preparing torches and pitchforks — but fear not, my fellow developers: GLib now detects if you’re running under Valgrind, and it will communicate with it4 about this new memory layout, as well as keeping a pointer to the beginning of the allocated region, so that you won’t get false positives in your report.

this was the state at the end of the hackfest. on top of that, I decided to contribute a bunch of “syntactic sugar”5 to cut down the amount of lines and things to remember6, as well as providing a good base towards making GProperty work better, and with fewer headaches.

so, here’s how you create a new GObject type in the Brave New World:

// header
typedef struct _MyObject MyObject;
typedef struct _MyObjectClass MyObjectClass;

struct _MyObject {
  GObject parent_instance;

struct _MyObjectClass {
  GObjectClass parent_class;

GType my_object_get_type (void);

// source
typedef struct {
  int foo;
} MyObjectPrivate;


static void
my_object_class_init (MyObjectClass *klass)

static void
my_object_init (MyObject *self)
  MyObjectPrivate *priv = my_object_get_instance_private (self);

  priv->foo = 42;

the my_object_get_instance_private() function is generated by G_DEFINE_TYPE, so you can forget about G_TYPE_INSTANCE_GET_PRIVATE and all that jazz. also, no more g_type_class_add_private() — one less thing to remember is one less thing to screw up. you can still store the private pointer in your instance structure — and if you care about ABI compatibility, you really should — but for new code it’s not necessary. you can finally hide the private data structure inside your source code, instead of having the typedef in your header, sitting there, taunting you. finally, everything is just as fast as it was, as well as backward compatible.

stay tuned for the next blog post, because it’ll finally be about GProperty…

  1. or commit to a script to autogenerate it
  2. say, for instance, if we’re re-implementing the way properties are handled in GObject
  3. well, of any GTypeInstance, really
  4. yes, you can do that, and it’s an impressive amount of crack, luckily for us hidden behind the valgrind.h header provided by the Valgrind folks
  5. i.e. pre-processor macros
  6. the port of GIO to the new macros lost around 900 lines

by ebassi at June 21, 2013 01:40 AM

June 19, 2013

Ross Burton

Guacamayo 0.2

Last week we (well, mostly Tomas if I’m honest) made our first release of Guacamayo, a reference Linux distribution for media playback devices in a networked world. The core technologies are the usual suspects: Yocto for the distribution, GStreamer and PulseAudio, Rygel and Media Explorer.

The first release caters for the “connected speakers” use-case.  On boot it connects automatically to the network over ethernet (wi-fi coming soon) and using Rygel exposes a UPnP/DLNA MediaRenderer, with hot-plugged USB speakers automatically switched to if plugged in. I’ve been happily using it on a laptop with my Raumfeld system, and Tomas has tested it on a BeagleBoard with a UPnP control point app on his Android phone.

So, what’s next?  I’m working on a web-based configuration tool for the headless systems, and Tomas is integrating Media Explorer so we’ll have something you can plug into a TV.  Tomas is testing this on a Zotac ZBox at the moment, and any week now I’ll have a RaspberryPi to experiment with.

If you’re interested and want to know more, we have a small wiki at GitHub and you can often find us in #guacamayo on FreeNode.

by Ross Burton at June 19, 2013 02:17 PM

June 10, 2013

Richard Purdie

Marshalling at the K2 Rally

They were looking for volunteers to marshal at the K2 rally around Kielder forest at the weekend, I decided after having enjoyed the enduro last year I helped with last year, I’d give it a go.

Even the trip up to Bellingham that morning turned out to have its interesting moments. The A68 is a very straight Roman road with lots of steep dips with blind summits. I had the bike on a bike rack on the back of the vehicle and naively set the cruise control. I soon found that it would plummet down the dips like a stone, then come to the other side, realise the incline needed throttle and that the speed was rapidly decreasing so it would open the engine right up. It would do this up to the summit of the hill with an effect like applying rocket boosters. The only way to describe the result is “big air”. Thankfully the air suspension does appear to be able to cope with this, much more gently and gracefully than I expected.

I’d not actually been able to get much information other than what time to turn up, even where was a little bit vague. The rally was two 80 mile loops of mostly forest fire road. The day was looking to get rather warm and the fire roads would be extremely dusty.

Firstly, I found out there were two refuelling points and the fuel trailer was leaving ASAP so I put 5L on each and hoped for the best since I had no idea where I’d be. At this point I didn’t even know what the organiser looked like. I figured out who he was and was assigned to the group manning the first section. We set off and followed the course around getting a feel for where we were supposed to be although the section with two way traffic where it loops back on itself confused us.

We shortcut some of the section and reached the first refuelling point. We decided to split up with some going to do traffic management on the two way section and some of us figuring out our shortcut to loop back to the start and the enduro loop we were responsible for.

I found the GPS invaluable at this point. We had a paper map of the route and comparing the trace on screen with that gave some idea of where we were, even if the scale seemed incorrect and the route had changed a bit from the one marked.

The final part of the course has some horrible bends covered in large rocks which I really hated, our enduro loop was good fun, starting off with brash, a drop and hill climb, then a nice green lane forest track.

I did have one interesting moment where both wheels lost traction and I was travelling along the track semi sideways doing a lowside in slow motion. I remember thinking that it felt like I could just tweak it back into line however there was a significant risk of turning it into a highside. I gently tried anyway and much to my surprise the front wheel started working properly again, even if the rear was fishtailing like crazy which was a much less serious issue. I think that stands as the single best recovery I’ve ever made on a motorcycle, I just wish I had it on camera.

So we made it back to the start and waited around a bit for the bulk of the riders to head through, then set off ourselves. We soon came to a fallen rider who was in a bad way. The fractured wrist was clear, the back pain worrying but they were conscious and alert which was a big plus. We had a few marshals around and some riders had summoned emergency services having been unable to get the satellite phone link to the organisers to work properly. I went back to the start and escorted paramedic to the scene who decided to call for air support. At this point there were too many people around the scene so I moved further down the course. The marshalls there were going to flush the first section so I skipped to the first refuel and refuelled, watching the air ambulance come in from a distance. We realised no marshal had been over the section to the first test so agreed I’d change plans and head over that way.

I rode for what seemed like hours without seeing another person, eventually reaching the special test. Great, except there was no safe route back to the start that I could see, so I did the only thing I could and continued onwards. I stopped and checked a couple of people dealing with punctures were ok. I also found someone who’d had an off and damaged their wrist, I advised just following the course since there was no shortcut out that section of forest I knew of. Eventually I came to the second refuel point and refuelled. I waited there for a bit and was able to direct the injured rider on a bit of a shortcut back.

The course was due to close at 2pm and I was supposed to be helping close it so I didn’t look at the enduro loops and headed back to the start, meeting up with another start marshal who’d had to find fuel point two since his fuel was there. We made it there slightly late but were the first there. Two others left to close the course, I was left manning the tape. I spent the next four hours there since I’d been told that I was not to move on account of anything, or let any rider onto the course. I was pleased when the closing marshals finally appeared.

Sunday started an hour earlier and for us, had the added fun of demarking. The riders would only do the first section on the first lap, then it was getting closed and demarked. The course would close at 1pm and then we’d sweep through and close/demark the remaining parts to the start of the special test.

The day started with ensuring the first section was clear and all the correct gates were open. It had rained overnight which meant there was more grip and less dust. There was a nasty bog in the first section which was interesting. I picked a line and took some reasonable speed into it. The bike threatened to stop half way but I really wasn’t keen on that, opened the throttle and put the weight on the back. Much to my surprise the front lifted to head height and the YZ did what it does best and powered onwards. I was in a deep rut at this point and using the front wheel for steering is overrated anyway :) . I was mildly concerned that there might be something in front but there wasn’t and I was able to land safely on the other side. Another of the marshals hadn’t faired quite as well but we all got through in the end.

Some of us went to figure out who the last man was so we could start the demarking, I went on with another to check the rest of the course to the first test. With riders setting off behind us, we were needing to get a move on but I was finally starting to remember how to ride fire roads (inside line on corners instead of road riding stick to the left for example). We were able to back track from the special test a little and short cut back to the start where we refueled.

When we got back, demarking had started but the gates needed locking. No problem, I can do that so I set off. This meant I was off by myself and reached that bog. This time around I tried a different line and managed to ground the bike out. I therefore spent quite a while extracting it and ended up rather muddy. Moments like that where the bike is on its side and your foot is trapped under the front wheel are always good fun. With the gates shut we went to the start for course closing. On the way there I found someone struggling with a stuck throttle after an off. I pointed out the cable was jammed by the barkbuster and helped them free it. A short while later I also loaned out an allen key to stop the guard catching their brake lever.

With the course closed, we set off, demarking as we went. I got the awkward signs to do since I had the sidestand. Obviously getting off the bike for each one is a pain so you attempt to ride the bike through some interesting obstacles. Occasionally you’d ride into what looked like a nice safe area, only to find for example it was full 1ft sized lumps of rock covered in moss. All good fun though. We demarked all the way to the special test, then passed on the batten to the team there. We’d passed a broken down rider so we went back with a tow rope for them and took some short cuts to pull them out the forest. I then manned the tape for half an hour before calling things done and headed back to camp and then home.

The bike is going to need some TLC now, the rear tyre was worn at the start, now its totally knackered. My number plate is also disintegrating and the sidestand spring gave out when I was unloading the bike. My hands now have blisters on the blisters and muscles I’ve never felt pains from before are aching. All things considered it was a good weekend :) .

by Richard at June 10, 2013 10:41 AM

June 03, 2013

Damien Lespiau

Working on more than one line with sed’s ‘N’ command

Yesterday I was asked to help solving a small sed problem. Considering that file (don’t look too closely on the engineering of the defined elements):


The problem was: How to change value1 to VALUE!. The problem here is that you can’t blindly execute a s command matching <string>.*</string>.

Sed maintains a buffer called the “pattern space” and processes commands on this buffer. From the GNU sed manual:

sed operates by performing the following cycle on each line of input: first, sed reads one line from the input stream, removes any trailing newline, and places it in the pattern space. Then commands are executed; each command can have an address associated to it: addresses are a kind of condition code, and a command is only executed if the condition is verified before the command is to be executed.

When the end of the script [(list of sed commands)] is reached, unless the -n option is in use, the contents of pattern space are printed out to the output stream, adding back the trailing newline if it was removed.3 Then the next cycle starts for the next input line.

So the idea is to first, use a /pattern/ address to select the the right <key> line, append the next line to the pattern space (with the N command) and finally run a s command on the buffer now containing both lines:


And so we end up with:

$ cat input 
$ sed -e '/<key>key1<\/key>/{N;s#<string>.*<\/string>#<string>VALUE!<\/string#;}' < input 

by damien at June 03, 2013 01:24 PM

May 30, 2013

Emmanuele Bassi

California One Youth and Beauty Brigade

now, that was a title of a Decemberists song that I’d have never expected to use as a blog post title

I did announce it on foundation-list, given that it impacts my position on the Board of Directors of the GNOME Foundation, and I did a sneaky tweet as well, but I guess the blog (and Planet GNOME) is still the Old Fashioned Way™ to do these things — and seeing that Cosimo beat me to a punch, it’s worth saying that I have joined Endless Mobile as well.

my last blog post about my work life was a bit depressing, I guess; I received a ton of support and encouragement from many, many people — too many to thank effectively in the narrow margins of this blog. I did take the announced month off, and I was already on my way to recovery; then I met Matt, who told me about Endless, and what they were trying to do with GNOME, and I felt the absolute need to help them as much as I could. after all, aren’t we trying to make GNOME a viable proposition for OEMs and OSVs to take and put on their own devices? I’m sure we’ll be able to start telling the community at large more details about what we want to achieve, and how.

in the meantime, I expect to see people in San Francisco a bit more often (though I’m still going to be based on London for the foreseeable future), and I’ll obviously be at GUADEC in Brno.

by ebassi at May 30, 2013 10:25 PM

April 20, 2013

Emmanuele Bassi

GTK+ Hackfest 2013/Day 1 & 2

Day 1

it turns out that this week wasn’t the best possible to hold a hackfest in Boston and Cambridge; actually, it was the worst. what was supposed to be the first day passed with us hacking in various locations, mostly from home, or hotel lobbies. nevertheless, there were interesting discussions on experimental work, like a rework of the drawing and content scrolling model that Alex is working on.

Day 2

or Day 1 redux

with the city-wide lockdown revoked, we finally managed to meet up at the OLPC offices and start the discussion on Wayland, input, and compatibility; we took advantage of Kristian attending so we could ask questions about client-side decorations, client-side shadows, and Wayland compatibility. we also discussed clipboard, and drag and drop, and the improvements in the API that will be necessary when we switch to Wayland — right now, both clipboard and DnD are pretty tied to the X11 implementation and API.

after lunch, the topic moved to EggListBox and EggFlowBox: scalability, selection, row containers, CSS style propagation, and accessibility.

we also went over a whole set of issues, like positioning popups; high resolution displays; input methods; integrating the Gd widgets into GTK+, and various experimental proposals that I’m sure will be reported by their authors on Planet GNOME soon. :-) it was mostly high level discussion, to frame the problems and bring people up to speed with each problem space and potential/proposed solutions.

we’d all want to thank OLPC, and especially Walter Bender, for being gracious hosts at their office in Cambridge, even on a weekend and the GNOME Foundation.

by ebassi at April 20, 2013 08:58 PM

April 19, 2013

Emmanuele Bassi

GUADEC is coming

this is a PSA: if you’re thinking about submitting a talk for GUADEC 2013 in Brno, you have a week to do so. :-)

by ebassi at April 19, 2013 03:00 PM

April 09, 2013

Thomas Wood

Sharing Settings in GNOME 3.8

One of the new features I was able to contribute to GNOME 3.8 was the sharing settings panel.

Sharing Settings

The goal of this panel is to provide the user with a way to control what is shared over the network. The sharing services are provided by various existing projects, including Vino, Rygel and gnome-user-share. If any of the services are not installed, the relevant settings are not displayed. The panel also allows the user to configure various options for the services.

Bluetooth Sharing

More details about the design of the panel are on the wiki page.

by thos at April 09, 2013 02:21 PM

March 25, 2013

Emmanuele Bassi

I’ve been asked to review the GNOME 3 Application Development Guide for Beginners; I went through the book in about half a day and wrote this somewhat short review afterwards, and published on G+; sadly, I used a limited distribution, and G+ does not allow changing that without resharing your own post. given that I wanted to push it on the blog, I took the chance to review some of the stuff I wrote, and expand it.

my initial impression of the GNOME 3 Application Development Guide for Beginners book is fairly positive: the topics covered are interesting, and the book never loses itself in them, so that beginners will not feel utterly stranded after the first three chapters, as it too often happens with “for beginners” books. I appreciated the “pop quiz” sections, as well as the small sections that recommended improvements to the example code.

obviously, writing a book enshrines a certain set of requirements and APIs, and that is problematic when there is high churn – like what happens in GNOME 3, especially in terms of development tools (libraries and applications) and overall experience. for instance, the section on Clutter (which is the one I can immediately give feedback on, given my position) still uses the deprecated “default stage”, and yet it uses the new ClutterActor easing state for animations; the default stage was deprecated at long last in Clutter 1.10, but its use was not recommended since the days of 1.0; the actor easing state API was introduced in the same release that deprecated the default stage. also, the example code published in the Clutter section does not use any of the layout managers provided by Clutter, preferring the fixed positioning of the actors, which is perfectly fine on its own; the book, though, then proceeds to mention the amount of code necessary to get something on the screen, compared to the equivalent code in GTK, that uses boxes and grids. in general, that’s an utterly fair thing to say: Clutter sits at a lower-level than GTK, and it doesn’t have complex constructs like GTK does; I’m pretty sure, though, there are better examples than a row of boxes that could have used a BoxLayout, or a FlowLayout, or a GridLayout, or a TableLayout; or better examples than using an explicit PangoFontDescription instance with a ClutterText to set a specific font name and size, instead of using the ClutterText:font-name property which wraps the whole thing for the developer’s convenience. in short: Clutter is more “raw” than GTK, but there are convenience APIs for developers.

it’s been a long time1 since I started off as a beginner in developing with (and) GNOME, so all I can say about book for beginners is whether they are using what I write in the way I think it’s supposed to be used; as far as I’m concerned, apart from a couple of issues, this book is indeed providing a solid base for people that want to begin developing for GNOME and with GNOME.

the price is pretty accessible, compared to the cost of similar books: I’ve paid much, much more for an introductory book on Core Animation, or on Perl books; the ebook version, if you dislike the dead tree version, comes in various formats, including PDF and Kindle.

I’m not going to give votes or anything: it’d be a pointless number on an equally pointless scale; but if you’re a beginner, I think this book may be fairly interesting to you, if you want to start coding with GNOME technologies.

  1. this year is actually my 10th bug-versary

by ebassi at March 25, 2013 05:31 PM