One of these runs MPD and outputs music to the sound card of the host in addition to a web stream that I can access from anywhere in the world. Since the host and guest are using the same kernel, passing the soundcard on to the guest was as simple as bind mounting /dev/snd of the host into the root filesystem of the guest. I’m not quite sure how ALSA handles concurrent access, but it could be that this also works if several guests (or the host+guests) are playing to the same device.

But what is required to have working Xorg inside a cgroup/lxc container? Can we just do something similar? Turns out we can. Basic Xorg with the vesa driver and the old style input (no hal input hotplugging) works if you bind mount in /dev/tty7 (or another tty), /dev/mem, /dev/dri and /dev/input. Here is the obligatory screenshot:

Xorg running on the host graphics card from within a cgroup

So whats my motivation for trying this out? Curiosity mostly, but in a multi-seat system it could be nice to have each seat run as separate OS in a lxc container. It would allow each seat to run different distributions (within certain limits) and make sure that resources (CPU time, memory) are distributed evenly. And to provide isolation for security reasons.

That we need access to /dev/mem is currently a deal breaker as far as security goes, because it means that whoever gains root access in one of the guests will have control over the host (and thus the other guests) because they can modify the physical memory. There has been some interest in running Xorg as a unprivileged user, and that might address this issue. Locking it down with SELinux or similar might also be possible.

Obviously for multiseat you will need multiple screens somehow, either by using multiple cards or by sharing a single card (using one output each). I don’t immediately see any reason why the former should pose any problems, and with Dave Airlies recent work on multiple X servers on a single card that might also be possible in combination with cgroups/lxc.

I plan to test that this also works with the Intel driver, and perhaps also the Nvidia propriatary one with time. And perhaps try to get input with hal hotplugging working.

The required kernel bit, a “merge target” in the DM layer, was merged in the just released linux 2.6.33 and the lvm parts are there from 2.02.58.  LVM can now do snapshot merging with lvconvert –merge! I’m assuming here that the device-mapper code thats in between those two components has also been finished and released, which ought to be a safe assumption.

This makes me wonder why Fedora has chosen to base their System Rollback feature for Fedora 13 on btrfs instead of LVM, which would work on any file-system. There are probably good reasons.

I managed to the GIMP OpenRaster plug-in into mainline GIMP. This means that GIMP 2.7.1 and forward will have rudimentary saving and loading support out-of-the-box. Users of GIMP 2.6 or 2.7.0 can download and install the plug-in from here.

Luka Čehovin started work on a reference library (libora) for OpenRaster. Hopefully this will, along the way, make it easier to provide OpenRaster support in applications. Perhaps it can also help solve some performance issues we currently have in MyPaint when saving large images.

MyPaint

In late January we released MyPaint 0.8.0. The release was delayed a couple of months from the initial planning, and we did not get to integrate as much as we’d like from external git branches, but it was about time to get the changes we do have out in a stable version.  It was very nice to have a Windows installer ready from day 1, and that we were able to translate it into 12 languages! This weekend we also released MyPaint 0.8.1, which fixed a nasty memory leak and some minor issues. No Windows installer or DEBs yet tho.

Just recently, MyPaint has also been successfully built and run on Mac OSX, pressure sensitivity and all. Hopefully we can make it solid and easily available to end users with time.

I’m also hoping that we’re able to get 0.8.1 into official Ubuntu Lucid repositories. Sadly we missed the deadline for being imported from Debian, and I’m not sure who or how to approach this, but at least we got an issue for it filed on Launchpad. If we also got into the spring releases of Fedora, OpenSUSE, Mandriva et.c. that would be great, but thats of lesser importance.

More important is documentation, we are currently way behind on end-user documentation. I started a skeleton for a manual, and I suspect that I’ll be the one to do finish it also as no-one else has shown an interest in working on it. If I get motivated I might also do some screen-casts showing and explaining some features. Another area of documentation is making sure potential contributors have the information they need to easily be able to contribute, and I’m hoping to make all the relevant information available from the Development page on our wiki. And I’ll probably document up some of the code also, eventually. Lots of things to be done in a software project besides writing code!

As a side note, Krita 2.2 (due in early May) will include a MyPaint brush-engine, which is very cool. And apparently a commercial OS X application (that I cant remember the name of) already uses the it!

Going to Libre Graphics Meeting?

I’m looking at going to LGM in Brussels this year, to meet with MyPaint, GIMP, Krita and developers of free and open source graphics software.  Sadly its on 27th to 30th of May, which really is a bad time for me; May 27th being the dead-line for my senior project report and on June 2nd is my first exam.  But we’ve planned completion of the report 2 weeks before that and I’m trying to prepare in advance for my exams, so I’m hoping that I can go.

To make this event happen and enable developers to go  a money-raising campaign has just been launched on Pledgie: http://pledgie.com/campaigns/8926  Please support this effort if you are able!

I also plan to do some OpenRaster / GIMP-integration improvements and perhaps a small statusbar. I’m even considering writing a C library (with Python wrappers ofc) for OpenRaster, mostly to sped up saving and loading. A reference implementation would of course be nice to have.
But that is somewhat unknown territory for me and I’m not sure if I’m able to set aside the time necessary for such a task… We’ll see!

Recently I’ve also become involved in MyPaint development. It’s “a fast and easy open-source graphics application for digital painters”. You can follow development over at gitorious. Things fixed untill now:

• Filenames in the title bar!
• Improved file handling; Nice and consistent error messages when trying to open a file that doesnt exist or you dont have permissions to read.

My artistic skills are severly limited, and I’ve never used a tablet before but here is the obligatory screenshot.  Needless to say, I dont do this awesome program any justice at all. Here is someone who does (David Revay). But hey, I’m at least halfway there right?!

If you are on Arch Linux, packages are avaliable from AUR, both stable version and -git. Somehow I’m also the maintainer of those now… If you are on anything else, you will have to go to the homepage and get it there. Hopefully packages will be in Debian and Ubuntu official repos shortly.
Do note that it currently does not build on Windows, or cygwin at the moment. So if you are the type of person that can make such magic happen, please step up for the task!

I hope to do some more adventurous coding on some of my own project ideas soon, but for now I expect to continue contributing bits and pieces on MyPaint to gain some experience.