LIBV Intentionally Breaks Videodrivers

FOSDEM Aftermath.

Fri, 10 Feb 2012 12:56:44 GMT

FOSDEM was awesome this year. We had an overbooked schedule for our DevRoom, we inaugurated the beautiful and fantastic K building, and i got to present the lima driver.

First off, i would like to thank the FOSDEM organizers and the ULB. The already unique event that is FOSDEM just keeps getting better and better. Pascal & friends: congratulations, like every year, you've outdone yourselves.

Secondly, i would like to thank all the speakers in my devroom. It is clear by now why the first-come-first-serve algorithm has to be used, and it is also clear that it is working. But thank you all for making this a successful event (even Chris, who couldn't make it due to a train derailment). I hope you guys had a lot of fun too, both during your talk and with the rest of FOSDEM.

Lastly, to all those who attended my talk (and those who couldn't get in anymore as well): Thank you all for your very positive feedback. No matter what happens with lima in future, this talk will be the most memorable moment. (oh, and a big thanks to Will Stephenson, from SuSE and KDE, for getting a webcam up that quickly). To whoever shouted something along the lines of "we don't see that, it looks like a perfect cube to us" when the caching went off in the rotating cube hack: this is the open source spirit in its most tangible form. Thank you very much.

To end this post, let me plug the lima website again. We also have a mailinglist and the #lima channel on freenode. The limare code has been available since yesterday night. Heise and lwn posted the story already, and the videos from the FOSDEM talk should soon hit phoronix as well.

XDC 2012: Nuremberg!

Fri, 09 Dec 2011 04:32:10 GMT

Yes! The board has decided! XDC comes to Nuremberg!

For 2012 we (Egbert Eich, Professor Hopf, and I) will be hosting the annual X conference in Nuremberg!

Egbert will try to get the main SuSE conference room, or, failing that, Matthias will try to get us a university aula, so the venue itself will work itself out beautifully in one way or another. Then... Nuremberg is one of those places which is perfect for large crowds who need food and some liquids in the evening (frankonian/bavarian beergarten culture), so it is the perfect (and highly affordable) conference area from that point of view. And, the best part, even though Nuremberg is not the international hub that Frankfurt is, or the european hub that Munich is, it is halfway between the two, and travel is relatively easy from either of those points, either you take the plane, or you take a much more comfortable train from either airport, and get to Nuremberg in pretty much the same time. You can really make a big save comparing those two airports when flying inside european aerospace, and this for no time difference. One insider tip though: you get to ride the ICE at full speed (300+km/h!) when traveling from Munich (you do have to endure the rather pedestrian S-bahn for 45 minutes though).

Anyway, the main action item now is that Egbert can start to poke SuSE to see when their main conference room is available for 3 days in september 2012 (working network and enough power sockets are a given then!). I doubt that we will get an answer still in the three remaining weeks of this year.

The actual proposal e-mail sent to the board is sadly only available to X.org foundation members, but a wiki page will soon be created which recreates most of that information. But rest assured, we will get close to the wonderful experiences of XDC Toulouse (thank you Matthieu!) and XDC chicago (thank you Michael!) indeed!

(oh, and btw, we have a FOSDEM DevRoom this year, which is rapidly getting its schedule filled! If you are coming, get your talk in right now: first come, first serve!)

Wheelbuilding...

Fri, 12 Aug 2011 22:46:01 GMT

(Bicycle-) Wheel building is an art. An art perfectly suited for a geek; it requires technical insight, knowledge, feeling and some experience. For those interested, here are some tips and pointers from my own experience.

1) Buy "Professional guide to Wheel Building" by Roger Musson, it is going to be the best 9GBP you have spent in a long long while. [HINT1]
2) Read it, twice!
3) Buy the rims and hubs before you buy the spokes (and get the necessary tools too if you haven't already).
4) Measure the ERD (Effective Rim Diameter) using the old-spokes with glued-on nipple method that Roger describes [HINT2].
5) Buy the spokes that spocalc.xls then calculates for you.
5) Lace your wheel like Roger describes, to the letter.
6) Tension your wheel like Roger describes, to the letter [HINT3].

HINT1: Do not read any other sources, Gerd Schraner's book is just pure nostalgia and does not help you much. Especially his explanation for tensioning your spokes should be ignored: while it might get you a straight wheel, your spokes might have wildly varying tension, and are therefor likely to either break due to fatigue or have the wheel go out of true quickly.

HINT2: For creating the cut-off spokes for measuring the ERD as Musson describes; screw your nipples onto your spokes so that your spoke only _just_ comes out of the nipple into the groove for the nipple-driver. This is the measuring length you should use. If you use the absolute top of the nipple for measuring the length, then you will have no room for error, and you will very likely use up all of the thread on the spoke while bringing the wheel up to full tension (this is the experience bit right here). If it is still inside the nipple, then you most likely will end up with too short a spokes, with thread still showing, this too is a nightmare for wheel-building (your nipple-driver will not disengage). Once you bring your wheel up to its final tension, the spoke (especially double butted spokes) will come slightly further out of the nipple as with the measurement-spokes.

HINT3: For the final stage of tensioning, where the spokes tend to turn with the spoke-key, I marked the rim-sides of the spokes with different colour alcohol markers. This gave me the ability to view the turning of the spokes, and to undo it, close to the rim and nipple, without hampering the spoke-key. Since this is an alcohol based marker on stainless steel, you can rub it off afterwards, or you could just take some alcohol to wipe it off. I just kept it on now, knowing full well that most of it will disappear soon enough in the rain and mud.

I am using Extreme Airline 3s, which i got from Rose. These are rather deep rims that are very stable and sturdy, and they have a wear-indicator still. The joint is not done well, and you will always have a third or so of a mm difference in diameter there, but for trekking or mtb tires, this is no issue, it is just annoying when working on the wheels in the stand. Because these rims are so sturdy, the Schraner method becomes quite unreliable, you can much more easily get away with differently tensioned spokes, as the rim is much more likely to even differences out for you instead of showing where the differences are. You actually need to pluck the spokes instead, like Musson describes, early on in the tensioning process, to get rid of the differences in tone and therefor tension.

I ordered a pre-built set of Airline 3s (28" with LX hub and 3N72 dynamo) from Rose more than a year ago, and they seem quite sturdy and have served me well so far. But, sadly, these pre-built wheels were not up to tension, which I could hear on steep climbs as the spokes were rubbing against eachother with heavy and changing load. They were subsequently very hard to tension further, my guess is because of badly oiled nipples before assembly.

Recently I built a first set according to the Schraner method, and while this went well, and the wheels feel good, I am not sure how good they really are as I haven't used them yet. It could be that they go out of true quickly, especially after pumping quite a bit of heat in them going down some slope in the Fränkische Schweiss. The spoke lengths I used for the 28" Extreme Airline 3 rims, triple crossed (of course!) and with 12mm nipples are 276mm for the front, 281/283 for the back.

For the 26" version of the same rim, with the same hubs, same lacing, same nipples, I used 246mm for the front, and 251/253 for the back. This was calculated with spocalc after measuring the rim, according to Musson, and the ERD is 523mm (after correcting for my mistake). These wheels are for a velotraum cross crmo frame that I am just now building up, so there are no kms on them either, but I have a very very good feeling about them, as I did use Mussons book for them, and the wheels came together as good or even better than described. So while my own handiwork is still untested in real-life conditions, at least I can tell the difference between Schraner and Musson, and the spoke lengths are (now) correct too ;)

In any case, if you are into cycling, have done all other jobs around the bicycle, and mastered them, already, then try your hand at wheel-building to complete the skill-set. It is not black magic, it is actually highly logical, but you should not use sentences like "How hard can it be?" or "Right, I'll get my hammer!" when doing so. Read the right book, get the right tools and the correct spokes, and then take your time; it is really very rewarding.

This way, the free software desktop is never going to make it.

Sat, 15 Jan 2011 15:52:40 GMT

In order to get easier access to Nokia things, and to boost security (as in, encrypt stuff, for a change), I've been reinstalling my trusted hp 6715b. Most nokians use ubuntu, so i went for 10.4LTS. I already severely disliked the way in which you have no installation options to chose from. You get the grandmother version every time, no "i have a clue, let me decide what i want to do, myself" button anywhere.

I was lucky, in 10.4 my now 3y old graphics card was still working out of the box. But, of course, i want to have my big virtual screen back. This, of course got dropped with randr 1.2 and the Virtual keyword was reused for something else. Matthias Hopf then re-added it in 1.3; mostly to appease me, and the handful of other weirdos out there. But, try finding this option in the xorg.conf manpage. Nothing! Try googling for it, and the first 50 hits either only explain the commandline version or the old style Virtual (which got broken). Apparently, you need to add 'Option "Panning" "${H}x${V}".

Easy, pico /etc/X11/xorg.. Damn. Nothing. head /var/log/Xorg.0.log says xorg.conf.d. Type man xorg.conf.d. Damn. Nothing: "No manual entry for xorg.conf.d" Suuuper. Apparently people are supposed to _know_ that this is part of the xorg.conf manpage.

So, create a new screen, device and monitor section in 01-screen in xorg.conf.d, and press ctrl-alt-backspace, like any experienced driver developer is used to. Damn. Nothing. Head into gnome preferences stuff, enable key combination. Try again. Drop into the console. Wait for the display manager to try again. And wait. And wait. Damn. Nothing again. Ok, the DM might have died, and i don't trust this new gnome stuff, so it might be better to reboot. So Ctrl-alt-del, which worked first time round. At least something one can depend on.

Next time i look back, ubuntu is showing its plymouth style loading, but the panel is gradually turning white. Something is not driving the panel and the driver died, for whatever reason. WTF? Try some key combinations to get a console. Damn, nothing! Pinging the box still worked, but of course, no sshd was installed. Attempting a reboot didn't bring anything either, it just runs into the exact same issue. Nothing is checking whether a previous boot got one to a working console or a working X.

So, insert the ubuntu installation cd, choose live system, mount the fs, chroot to it, apt-get install ssh, and less /var/log/Xorg.0.log to reveal:

> (==) Using config directory: "/etc/X11/xorg.conf.d"
> Parse error on line 3 of section Monitor in file /usr/lib/X11/xorg.conf.d/01-screen.conf
> The Option keyword requires 1 or 2 quoted strings to follow it.
> Parse error on line 3 of section Monitor in file /usr/lib/X11/xorg.conf.d/01-screen.conf
> "2560x1920" is not a valid keyword in this section.
> (EE) Problem parsing the config file
> (EE) Error parsing the config file
>
> Fatal server error:
> no screens found

I forgot to put apostrophes around "Panning", and i got greeted with a bleeding panel, with no option to easily get around it. What on earth are we thinking here?

This is Ubuntu LTS, with radeon, KMS, plymouth and xorg.conf.d. 5 nails in the free software desktops coffin.

OpenSuSE 11.1 and a recent scanner

Wed, 05 Jan 2011 14:24:39 GMT

As some might know, I am switching ("intermediate") employers, and i am going to do home-office from now on. Home-office probably has tons of advantages, but one disadvantage is that you need to own your own office hardware, like a printer and a scanner. Such beasts were sitting around in Belgium, but in the 3.5 years that i have been in Nuernberg, i have either depended on the office i was respectively working for, or i ran to the copyshop around the corner. The latter is extremely unpractical and becomes rather expensive.

So, today, a Canon Canoscan LiDE 110 arrived from amazon (plus a basic samsung laser), and i have just succeeded in getting it to work with openSuSE 11.1, albeit in a very unscientific way. Here is how.

Sane is divided in front and backends. openSuSE 11.1 requires just an updated backend.

For the LiDE 110, only very recent sane (git from halfway december 2010) supports the LiDE 110 and 210, so grab the git repo.

Then, grab a recent openSuSE sane-backends package, for instance from here. Get yourself the src.rpm, and install it.

A crude way of getting something our specfile can work with is to tar -jc up the sane-backends git repo, and to move that to /usr/src/packages/SOURCES

Then edit the specfile, make sure to bump the "Version" and/or "Release" directives. Then have the "Source0" directive is pointing to the correct tarball, and make sure that the line with "%setup" is pointing to the right %{name}-... directory.

If you are as lucky as i was today, the existing patches, which are mostly about integration, will apply rather cleanly, and rpmbuild will succeed.

Install the created files (you probably won't need -devel), and you should now be able configure your scanner using yast. If yast complains about hal, then run rchal restart.

Now scanimage -L should be happy, and then you're all set.

Happy scanning!

The linux desktop is dead!

Fri, 17 Sep 2010 13:36:10 GMT

Or so it will be, soon, if these guys get their way.

Apparently, and this has been the hot new idea for the last year or two; for Xserver 1.10 people want to get rid of one of the greatest things that XFree86 brought us, and one of the better changes that happened after the X.org fork: modular graphics drivers.

While the current proposal is simply to undo the modularization work of the mid-naughties (thanks jezza!), it immediately sparked the imagination of others to go even further (to which Alanc answered rather strikingly). But merging drivers back is in itself already a very damaging move.

So what is the goal behind merging drivers?

The official reason for this is "cleaning up the API", but I fail to see any logical link between being able to clean up APIs and mashing everything together.

There is simply nothing that stops APIs from being improved when drivers are not a full and whole part of the xserver build tree.

A mashed-together tree has no more advantage than a buildsystem like our tinderbox.

And having modular drivers does not mean that one has to have a fully static API and ABI, you just need to have dependable ABI bumping, and, for the sake of overhead, sane and forward-looking API changes. Free software drivers are of course best able to keep in sync with API changes, but this is no different whether they are external or internal to the server build tree.

However, there is a difference in how one approaches API cleanups in a modular world, as one needs to think a bit more about how to do such API changes. This often leads to a cleaner design, a better structure, and it often means that people spend time trying to understand existing code, and how to best adjust it to fit the new needs, without throwing out the baby with the bathwater. By moving the drivers into the xserver tree, and outlawing the API, we will only open the door for having a libpciaccess type breakage every month.

So maybe this is the real wish behind wanting to merge back drivers: being able to pull crazy stunts with halfarsedly designed, badly structured and untested code, without implications, without accountability.

Apart from APIs degrading further, there are other more fundamental issues with this, with actually far reaching consequences.

When tying in the graphics drivers with the X server, the only way one could get driver updates, to get bugfixes, new features or new hardware support, is by installing a new Xserver.

This is probably going to be claimed as a benefit, as people want more testing of upstream code, but a slight increase in usage of upstream code, will mean a much bigger decrease in userbase on released code, and people will be even more afraid of updating anything in their system than today.

But this is how the kernel does it!

We've all heard this from our mothers: "If some other kid jumps off a cliff, is that a reason to jump off that cliff as well?"

Basically, while it might be a good idea for the often much simpler devices that have rather complete drivers (at least compared to graphics drivers :)) in the kernel to be a full and whole part of the kernel, it does not and will not work well for graphics drivers.

The complexity and the amount of movement in graphics drivers, especially with the many parts staying in userspace and the very unstable interfaces to them, makes this rather messy. And the only way that this is feasible is when those drivers are rather stable, and they definitely need to have a very stable ABI to userspace.

No-one will be able to maintain such a level of stability for graphics drivers, and i am sure that no-one will stand up to defend going that route, if this requirement is mixed into the discussion.

How to sneak in a 1 to 1 version dependency between xserver, mesa and the linux kernel... Pt. 1.

In January this year, in the run-up to xserver 1.8, there was a commit to the xserver, labelled "xserver: require libdri 7.8.0 to build", where an autoconf rule was added to depend on this version of "libdri". I believe that this was mainly because of DRI2 changes.

When I say depend here, there is not a complete dependency on a given version of libdri. One can always build the xserver without any DRI support whatsoever. But who, on the desktop, really wants that today?

So while this all-or-nothing decision is in itself questionable, there is another question to be asked here: what is this libdri?

There is a dri.pc on most systems today, and there is a libdri.so on most systems today. The former is a package config file coming from the mesa tree, the latter, is an xserver internal convenience library (hence the lack of so versioning). Smells fishy, doesn't it?

Now, while you might want to spend time looking high and low for the libdri from mesa, you will not find it. Mesa comes with 10 or more different libdris, one for each driver it supports, with the whole of the mesa linked in statically, in the form of driver_dri.so...

Urgh, how broken is that?

So, the xserver now depends on 10 or more different, driver specific, enormous binaries, all because its dri support now depends on a given version of the dri protocol. Or, re-stating that, the xserver depends on a very specific version of the monolithic, 80s style, mesa tree.

Expanding the logic for the xserver and the drivers: why not just mash the mesa and xserver trees together then? :)

More parts come into play... (or dependency Pt. 2)

The xserver depends on the standard drm infrastructure, and this is compatible up to a 4+ year old release of libdrm, namely version 2.3.0, as the basic libdrm code has barely changed since.

Mesa, however, is a different story altogether. It depends, hard, on the latest version of libdrm, and this has been so since Oktober 2008, when intel introduced libdrm_intel in libdrm 2.4.0.

In essence, this libdrm_intel is nothing more than a driver-stack internal convenience library. It only contains code that is specific for intel hardware and the only dependencies are parts of the intel driver stack (if those parts were living separately already). There are no direct dependencies from anything else.

But, ever since Oktober 2008, both the intel x driver and the intel mesa driver depend on the latest libdrm version, and since then, both radeon and nouveau joined in the frenzy.

So, while there might be some backwards compatibility between dri drivers and libdrm drivers, the reality is that intel, radeon and nouveau are today playing hopscotch. Because mesa is monolithic, and at least one of its drivers is going to depend on the latest libdrm version, the whole of monolithic mesa simply depends on the latest libdrm version.

Since mesa has been depending on the latest libdrm for a few years now, and the xserver has been depending on the latest mesa version since the start of 2010, in turn, the xserver now depends on the latest libdrm version.

Nice!

How does this tie in the kernel? (dependency Pt. 3).

Well, since libdrm has the driver specific sublibraries, those of course call drm driver specific ioctls, and of course, these ioctls change all the time. While some people claim that they try to abstract at this layer (and that this strategy is good enough for everyone...), and claim to try to keep the kernel to userspace interface stable, this of course is only true for a very limited range of kernel and userspace parts. Now, we have intel, radeon _and_ nouveau playing at this level, dividing whatever median compatibility range there is, by three.

The result is that libdrm can pretty much only be backwards compatible to the kernel by accident.

So, continuing our logic from earlier, the latest xserver depends on the latest mesa, the latest libdrm and the latest kernel.

Smashing lads! Well done! And all of this on a set of connections and foundations that make a house of cards look like a block of granite.

The root of the problem.

Graphics hardware is horribly complex. Several years ago, a single graphics card already broke the terraflop boundary, managing what a huge IBM supercomputer only managed a good decade earlier. Single graphics cards come with many hundreds of shader cores, running at frequencies above 1Ghz, have multiple gigabytes of ram, eat 200+ Watts, and can drive up to 6 displays today. There is no other single piece of hardware which is this complex.

And this complexity is of course also there in software.

You cannot count the different parts of a modern graphics driver stack on free software on one hand anymore. There is the kernel drm part, the firmware, the libdrm part, the X driver, a pair of mesa drivers, an xvmc and possibly another media acceleration driver. A graphics driver stack, can be made up of up to 8 parts today.

All of those parts are scattered over the system. There is 2 parts shipped with the kernel, 1 part shipped with libdrm, 2 drivers shipped with mesa, and the remainder can be found in an xf86-video tree.

Naturally, in order to work most optimally, these different parts have a very direct and acute dependency on each other. Bugs, new features and new hardware support usually incur changes to interfaces between those different parts all the time.

The way that those different parts are spread all over the place today make it almost impossible to have an optimal setup. Most of the time one is glad if it works at all. What's more, this spread is the core reason for the de-facto 1-1 version tie between kernel, libdrm, xserver and mesa.

The consequences of a 1-1 version tie between kernel, xserver and mesa.

With graphics hardware and graphics drivers being this complex, there is simply no way to have them in a bugfree or a constant "useful" state.

We just _have_ to live with the fact that graphics drivers will be buggy, and we should try to handle this as gracefully as possible.

This means that we should be able to replace all or parts of the graphics driver stack at any time, without negatively affecting other parts of the system.

This is what our audience, our customers as it were, expect from us.

But, by having kernel, libdrm, xserver and mesa tied together, and the different parts of the driver stack spread over them, it is impossible to exchange 1 part of the graphics driver stack, or to exchange just the graphics driver stack, without changing the whole.

By forcing our users to update all this infrastructure each, we will usually trigger a cascade of updates that reach far up the whole software stack, to the extent where trying to fix some small issue in the graphics driver, might mess up openOffice or another program that your average linux desktop user depends on.

Also, what is the chance of getting both wireless, suspend/resume and your graphics driver working to an acceptable level at the same time? This becomes very very small, and when it does work, you better not run into issues somewhere else, as an update might ruin that very precarious balance.

Killing the desktop for everyone.

No normal person can then run a free software desktop system, and expect to use it, because an arbitrary mix of hardware cannot possibly work together acceptably, at least not for a measurable amount of time.

What will be left over is preloads and embedded system.

Preloads is when some OEM, either itself, or through a linux distributor, spends many many man-years on making all parts work together properly. In the end, images will be produced which install on a very specific system and cannot be updated or maintained, except by a specialised team of people. Embedded systems basically work the same way: one combination of hardware, one image, no updates for average users except those provided by the manufacturer or their partners.

So while people might buy a free software based system in a shop around the corner, and be somewhat happy with it for a while, normal desktop users will be left out in the cold.

Looking further, by shutting out our own users, we will take away the breeding ground that free software is based on.

What solution is there?

By now, that should be pretty obvious.

Bring the different parts of the graphics driver stack together, and make its parts independent of the infrastructure they depend on.

This allows driver developers to change internal structure and API at will, while at the same time providing the infrastructure compatibility that users, hardware and distribution vendors require.

All it takes is a little care in designing infrastructure APIs, and a little care in keeping driver stacks compatible, even if that compatibility comes at the cost of disabling some features for some combinations of the infrastructure.

This is not hard to do, and it is done in multiple places.

Why the Nvidia binary driver is that popular.

In a recent phoronix survey, the amount of users using Nvidia hardware and drivers is larger than the users using any other combination.

This has a reason, and it has nothing to do with Nvidia being a completely closed source shop. Nvidia gives users the ability to install any graphics driver stack, and it should mostly be compatible with the environment it is installed in. This is simply what our users need.

What is affected by Nvidia being binary only, is that Nvidia has to put in a lot of work on making things compatible. Free software drivers have a much much easier task, or at least they would, if they, and the infrastructure they depend on, was developed in a different fashion than is the case today.

An open proof of concept.

My talk at FOSDEM, of course mentions my unichrome driver a lot, as it pretty much is my playground these days.

Even though the featurelist of this driver is very limited, it is now integrating X, DRM and DRI drivers in one massively backwards compatible build-system, with autotools detecting all the API changes across all currently used versions of the necessary infrastructure. What one can see there is that, when some care is taking in structuring the driver, it is not that hard to achieve this: it basically just takes the will to do this.

When I talked at FOSDEM, some people were stating that, while it might be possible for DRM and the Xserver, it would be totally impossible on Mesa/DRI, but for Mesa/gallium it should be easy.

In the next month or so, I took all Mesa versions that were out in the wild, and split off the main libraries from the actual DRI drivers, created a set of headers as required by the drivers, created package config files, and then move the drivers out to their own git repositories. Basically, a DRI SDK was created, and the drivers were now building and running externally to this SDK. This across 3 years of DRI development.

When I took that back to the Mesa community, what I of course got was indifference, and, suddenly, claims that while this SDK might be possible for mesa/DRI it would definitely not be possible for Mesa/gallium!

The future?

The proposed future direction for graphics drivers is to create graphics driver stacks. If not, we, the developers, might just as well stop working on free software graphics drivers altogether.

And while the current situation currently is bad, it is not impossible to fix. The problems are known and clear, a path to the solution should by now also be clear, but the willingness to put in the bit of extra thought is simply lacking.

So guys, if you really want to move into the wrong direction, please state the real reasons for doing so, state the consequences to your users; and know what the end result will be.

The DRI SDK and modular DRI drivers.

Wed, 17 Mar 2010 00:29:22 GMT

At FOSDEM I held a talk about "The free software graphics driver stack", analyzing the structure and the distribution of the different parts of the graphics driver stack, and, based on clear requirements, proposing a re-organization to be able to bring the individual parts of the graphics driver stack together. The slides for that talk are available here, and the audio and video of this talk have been made available too (Thanks Michael!).

Since I do not like to talk thin air, i also made a fully unified unichrome graphics driver stack available, proving that it is possible to unite all of Xorg, DRM and DRI drivers in one tree, and that it is possible to provide a reasonable amount of backwards compatibility (trivial for a stagnated driver) even in the Mesa/DRI driver.

My slides have a TODO section, and the most significant of those TODOs was for Mesa. This listed providing shared libraries, pkgconfig files and the necessary headerfiles for Mesa, much like the SDK that X has had ever since xfree86 4.0.0. Of course, such a thing would not happen on its own, so a bit after FOSDEM I set off and now I have implemented just that.

You can find the SDK enabled Mesa DRI tree here, and the individual drivers can also be found in my personal git repositories. A README like document is available too, to explain what one should do to build and install the SDK and to build and install the drivers.

What this gets you, once the SDK is properly installed, is the ability to build and install just the DRI driver to be able to fix bugs, get some performance gains, or just provide the driver developers with good feedback (provided that someone updated the driver tree to the latest compatible changes that is ;)). This without having to replace your libGL, which is where all the dependencies come weighing in. Anyone who has had to update this so far, knows how painful such an update is, and that it is often easier to do a major distribution upgrade.

So this brings us another step closer to make the free software desktop happen: the ability to easily update our graphics driver stack without touching anything else in our system!

VIA Technologies takes the blue pill.

Sun, 07 Mar 2010 01:01:31 GMT

@IanRomanick, with his post on a little cultural problem that VIA encountered.

I actually had some issues when unichrome.sf.net was first created in Q2 2004. Some commit emails would get caught by the sf.net spamfilter. There was an interesting struct in this headerfile.

A quick grep of VIAs current codedrops does not show much of an improvement. The same structs name is now preceded with "NEW".

Coreboot and Xorg DevRooms at FOSDEM... Aftermath.

Tue, 16 Feb 2010 15:56:46 GMT

FOSDEM this year was another huge success.

We had a great room this year, with luxuries as windows, which massively helped to keep the temperature under control :)

We had 100% coverage all the time, and during the first coreboot, and most of the announced Xorg talks, we had to limit the number of people getting in, as there was no standing space left (100 or so people in a 60 people devroom).

Some people complained over the size of the room for a project like X.org. But given the amount of talks that X.org people offered to give this year, we should count ourselves lucky that we had a room at all. No matter how big a project thinks it is, if no-one steps up to talk, there is nothing that can be done.

For those who got refused, don't worry. Now that Michael is back in the states, he will soon have the videos up on phoronix.

My talk about the graphics driver stack did seem to cause some crap-throwing. Seems that I touched some nerves, strange how my usually very shrewd and correct insights always cause similar reactions in the same people.

The FOSDEM event wouldn't be complete without being able to go out and enjoy some good meals with other open source people. This year was exceptionally nice, the Mirabelle had an exceptional Canard A L'Orange, and we found a really nice bar just a few streets away from the grand place, where beers are reasonable, the atmosphere is great and talking is actually possible!

I would like to thank Egbert Eich, and whoever else who helped out to make this devroom run smoothly, and thanks also go to Michael for taping the talks and all the speakers for giving them and getting a mostly pleased and happy crowd in! And thanks to those visitors, who, at FOSDEM, are always very interested and very open minded.

Last Preparations for Coreboot/Xorg DevRooms at FOSDEM.

Thu, 04 Feb 2010 09:20:13 GMT

In about 30h I will be on the ICE to Brussels to FOSDEM, to have 2 DevRooms there.

The Sportsbag with kit has been packed. The meeting at the customary restaurant tomorrow evening has been pretty much set up. Both my talks should be ready, and just need some studying. And I am now making the posters with the schedules and the fliers (used for possible status changes and directions) for the two devrooms so that they can be printed out later today.

The schedule for the Coreboot DevRoom (on saturday) is unchanged since my last post:

* 13:00 : Peter Stuge - coreboot introduction.
* 14:00 : Peter Stuge - coreboot and PC technical details.
* 15:00 : Rudolf Marek - ACPI and Suspend/Resume under coreboot.
* 16:00 : Rudolf Marek - coreboot board porting.
* 17:00 : Carl-Daniel Hailfinger - Flashrom.
* 18:00 : Luc Verhaegen - Flash Enable BIOS Reverse Engineering.

All seems well, and it seems that we will have everything filmed nicely too!

The schedule for the Xorg DevRoom (on sunday) has seen one last minute change with the addition of Nicolai Haehnle's talk:

* 12.00: Nicolai Hähnle : Towards GLSL in the r300 Gallium driver
* 13.00: Daniel Stone : Polishing X11 and making it shiny.
* 14.00: Luc Verhaegen : The free software desktop’s graphics driver stack.
* 15.00: Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status.
* 16.00: Mikhail Gusarov : X on e-Paper.

This addition was very last minute, and did not make the FOSDEM folder. Nicolai was quite lucky as the FOSDEM organisers had already assigned the DevRoom to the openMoko project in the morning, which luckily left a single slot free for Nicolai.

I've finished my slides for my own talk in the X.org devRoom, and it promises to be an interesting one, albeit controversial for some.

It examines some of what we can tell a few years down the road from the modular tree, and goes over the real needs. Then it explains the unification of graphics driver stacks, how to build it for the unichrome driver, and what infrastructural changes it could use.

But before i go into details i will have a small in room survey (Which will probably become a more widespread survey online). One of the questions i will ask is: "For those using, or those who have used, the nvidia or ati closed source drivers: how would you like it if nvidia or ATI told you that you needed the very latest upstream kernel, X, and mesa to be able to run the latest catalyst or nvidia driver, especially when you might need this version for its new hardware support or for bugfixes?"

(and urgh... the msi fuzzy cn700t motherboard i was using as a mailserver just died on me, even the port80 card says that no bios code is being run. Now i stuck in another cn700 board, and it has one of those really noisy fans :()

So openSUSE needs a new community manager?

Wed, 27 Jan 2010 18:26:20 GMT

Remember this guy?

He knows a thing or two about SUSE and its community. He is used to travelling a lot, to give interviews, talking to the press, and to speaking in public, and on top, he knows how to organise events for a once big linux distribution. And thanks to a really fun group event at his previous company right after FOSDEM last year, he might actually be available for a new opportunity.

Plus, he lives like 200 meters away from the SUSE Nuernberg office, how lucky is that?

(oh, music is the stones, track 4 of 12x5, listed here as suse planet is horribly broken with respect to livejournal.)

FOSDEM: Coreboot and X.org Schedules.

Fri, 22 Jan 2010 01:22:05 GMT

coreboot DevRoom

This year, at FOSDEM, there is a coreboot DevRoom, and for the hardware-lover, there are some really interesting talks there. When putting together the final schedule, I actually had to spend some time on containing people's enthusiasm and limiting their ideas to something feasible for FOSDEM. A rather good sign, and i am sure that many people will enjoy the truly interesting and juicily in-depth talks there.

Here is a quick copy of the saturday afternoon schedule:
* 13:00 : Peter Stuge - coreboot introduction.
* 14:00 : Peter Stuge - coreboot and PC technical details.
* 15:00 : Rudolf Marek - ACPI and Suspend/Resume under coreboot.
* 16:00 : Rudolf Marek - coreboot board porting.
* 17:00 : Carl-Daniel Hailfinger - Flashrom.
* 18:00 : Luc Verhaegen - Flash Enable BIOS Reverse Engineering.

So yeah, i have a talk at 18:00 which promises to be fun.

Basically, for flashrom, we sometimes need to find out what write protection certain motherboards implement, so we can disable that from within flashrom. This usually means that someone (usually Michael Karcher or me) has to go and disassemble the BIOS to find out which GPIO line needs to be toggled.

For a single board, this is usually not a hard task (and actually fun), but the overal amount of work in flashrom is sizable, and the two of us are not available 24/7 to do this for every user in need. So this talk is meant to alleviate that.

I just wrote the slides for it, and while i might alter the notes and twiddle it a bit still in the next two weeks, it should be pretty much finished.

The structure of the talk is the following:
* quick overview of how flashes are usually wired up on motherboards.
* quick overview of how to handle Award, ASUS, AMI and phoenix BIOSes.
* example of disassembly of a BIOS.

The BIOS that is being disassembled is an especially crafted one, with an award style flash enable for a fictitious board. It's mostly filled with 0xFF, apart from the flash enable itself. And the talk itself is pretty accessible, you do not have to know much of assembly or hardware to be able to participate.

If you are visiting the talk, and you want to join in, then you might already want to download the image, and make sure that you have hexdump and ndisasm installed (as there are about 4000 others trying to use the wireless at FOSDEM).

It promises to be a blast!

X.org DevRoom

On sunday there is of course the X.org DevRoom, for which the schedule is also online.

It seems to be a tradition that I have to go and beg people to talk at truly great event like FOSDEM.

Last year, we had 7 talks in the brochure, while there was room for 13, and we eventually had 9 talks. All these talks were hugely popular, with almost full capacity usage most of the time, but the actual talk coverage itself left much to be desired.

This year I decided to split the usual two day X.org DevRoom into coreboot (saturday afternoon) and X.org (sunday), so that the X.org schedule could be tighter and more exciting.

Here is the result;
* 10.00: ...
* 11.00: ...
* 12.00: ...
* 13.00: Daniel Stone : Polishing X11 and making it shiny.
* 14.00: Luc Verhaegen : The free software desktop’s graphics driver stack.
* 15.00: Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status.
* 16.00: Mikhail Gusarov : X on e-Paper.

I, and a lot of fosdem visitors with me, thank Daniel, Jerome and Mikhail for their commitment. These talks seem very interesting and will no doubt draw in a lot of visitors and carry out the good name of X.org.

It does make one think. There seems to be a direct and inverse relationship between the size and status of a free software project, and the willingness of its members to go and promote this project on the biggest free software event on that continent that holds the majority of its current developers and the largest potential of future contributors.

In any case, I have been communicated that, as there are many very worthwhile and also very willing projects who get denied a DevRoom each year, a project with such a poor showing will not be given another DevRoom.

While I start putting together the slides for my X.org talk, I can only concede.

Emergency BIOS update, the easy way.

Fri, 15 Jan 2010 15:01:35 GMT

Jetway sells a cute VX800 mini-itx board which comes with a choice of VIA C7 and Nano cpu's: the JNF76. At the end of last year, i became the proud owner of one of the rare DVI modules for this board, and shortly thereafter there was an ebay auction which got me a brand new board at half the listed price. I now found the time to go and play with this board, to at least give the ebay seller the positive rating he deserves :)

What I found is that this board booted a debian old-stable (etch) just fine, but that debian stable (lenny), opensuse 11.1 and 9.04 ubuntu, all locked up shortly after initialising the ide controller. Some digging around revealed that this was an issue with the processor power state and recent kernels, and that this is only seen with an older bios version, and that version A03 and higher would fix this. Upon reboot, it was indeed confirmed that this was an old version, namely, A02.

Since sadly, the network controller on this board is not supported by the old-stable kernel, i had to use a usb stick. So I stuffed the latest bios and a copy of flashrom master on the stick, and stuck it in the jetway board. As i already had the libpci-dev package installed, a simple run of make got me a working flashrom binary. I then used flashrom -r jnf76.old.bios to dump the current bios, as a precaution. And then i ran flashrom -w on the new image.

When running flashrom, there is a relatively high probability (50% is my current estimate, but will improve to about 30% soon) that it will not work. Motherboard makers like to provide an extra bit of protection for their bios images, and often use a gpio line from either the southbridge or the superio chip to set write protection on the flash chip.

In flashrom, we keep a list of special board enables, which today mostly map which io line to set, and Michael Karcher and I spend quite a bit of our time digging out bioses for users to map this. So in this case, before i had tried to write to this chip, i had already done my 5 minute magic (which i will explain at the coreboot devroom at FOSDEM) and found out that there was no special protection present.

Flashrom then erased the chip correctly, and then subsequently wrote and verified the image. And i was then able to reboot into any of the installed distributions painlessly.

If there was protection present, (and we didn't handle it yet in flashrom) then this would've made the erase fail at the first byte that isn't 0xFF, and then nothing was lost. There is also another type of protection only found on LPC/FWH/Parallel chips, where the boot block can be locked, and this has the same effect, but only on the boot block part, where you just need to restore all other pages to be able to continue working. We will then happily help create the board enable with you on the flashrom mailing list, so that you still can get your bios updated correctly (now, and in future).

In any case, this was one of the easiest emergency bios updates i had ever done. No messing around with dos images and what not. I had already identified a working linux kernel when trying to nail down the issue, and then just needed to run flashrom to live happily ever after :)

Coreboot and Xorg DevRooms at FOSDEM!

Wed, 02 Dec 2009 03:20:19 GMT

Yeah, you read that correctly, there will be two close to the metal DevRooms at FOSDEM this year (or next year, Mr. Daenzer :))

FOSDEM 2010 runs on the 6th and 7th of February and in the AW building in room AW.124 there will be some really interesting things happening :)

On Saturday the 6th, the first coreboot DevRoom will be held there. It's still early days, but several key developers will be there, and we will be showing off coreboot, flashrom and will be presenting some really cool stuff. You can track the talks list on the coreboot wiki.

On Sunday, we will have the X.org DevRoom there, for the fifth time already. This DevRoom has really been one of the best filled and most interesting ones for the past few years, with highly in-depth and technical talks, and we of course will provide the same this year :) X.org tracking page is on the X.org wiki.

As per usual, we will try to get people together on friday evening and visit that one restaurant on the grand place that we tend to visit each year (whose name i can never remember :)). And if enough people give me a heads up, i will try to reserve a big table at the excellent Mirabelle again for saturday.

As for people who are interested in speaking at one of the DevRooms, check the page of the individual projects for more details and do not hesitate to mail me or Egbert.

Hardware MPEG2 Slice decoding added to unichrome driver.

Wed, 04 Nov 2009 22:06:05 GMT

I just pushed out code which adds MPEG2 slice decoding to my graphics driver. It is based on XvMC, but unlike "standard" XvMC implementations, it sends MPEG slices over to the graphics driver over the X protocol.

The base idea is the following: The MPEG engine gets MPEG slices, and outputs to a buffer. This buffer needs to then be displayed by the overlay engine. So, we need to spend most of our time managing the communication and syncing of those engines. We already have the other video engines implemented nicely, so, why not stick the MPEG code next to that and have a nice and clean implementation?

The XvMC protocol, X-wise, is mostly about telling the driver that the MPEG hardware is in use, and subsequently claiming buffers in the framebuffer, managed by the X driver. Everything else is expected to happen in the client library. For what reason, i do not know, but part of it could be that, this way, X is not seen to eat any CPU cycles. In any case, this makes it a very weird protocol, with things spread all over the stack.

Things were made worse with the advent of the XvMC wrapper. Instead of expanding the XvMC protocol slightly to provide the name of the XvMC client library to be loaded, DRI is abused for this purpose. So... a pointless hard dependency on DRI is added, and now, no working DRI means no working XvMC... Curious. Makes the pointless dependency on Shm look harmless.

So what i did now is send all the data over the X protocol, over a tiny X extenstion, so that it could be fed into the hardware and synced inside the X driver. An XvPutImage with a longword buffer containing the mpeg buffer id then makes sure that everything gets displayed correctly. And while the overlay is being set up, the mpeg engine can finish its work, and at the very last minute, the overlay code waits for the mpeg engine to finish, and then the overlay gets told to display the new image.

Other XvMC implementations went and completely reimplemented the overlay in the client library, and even involved 2d acceleration to be able to send mpeg slices to the hw a bit faster. A syncing nightmare. Another advantage is that my implementation can implement the newer mpeg2 engines in just a few hundred highly hardware specific lines.

Of course, sending this data over the X protocol in tiny bits does incur some more cpu cycles, and i also am not feeding mpeg data into the hardware over the command buffers. Because of this, my code uses about 30-35% for a normal DVD (write a comment if you guessed which :)) on a VIA C3 Samuel2 (yes, half speed FPU, not quite PPro compatible) at 600Mhz, while openchrome uses 20-25%, roughly 2/3rds. But the performance of my code is still very good, good enough to not bother with speeding things up just yet.

As usual, it is easy to get this new code. It builds and runs against all Xorg versions that are common, and the debian package build system has also been updated for the xvmc code.

For xine there is one caveat, due to the horrible implementation of video_out_xxmc. We need to fool xine into thinking that we do support subpictures (we don't as it the xxmc way of implementing things didn't even get close to how the hardware implemented it). For that, the following option needs to be set:

Option "XvMCBrokenXine" "True"

in the device section of xorg.conf.

Enjoy!

Surely i am not the only one seeing this...

Mon, 14 Sep 2009 17:04:47 GMT

I just scrolled over planetsuse. The art of scrolling over blog aggregators is mostly in filtering out all the information and retaining quick impressions and then reading that what triggers something.

And what triggered my synapses was the logo of monotouch. Here is a screenshot:

Is novell really selling enterprise versions at 1k usd of a product with a mis-designed logo which gives you the finger?

Guessing from the side-thingie off what most people will see as the middle finger, the real intention was not to make a rude gesture. Also, there are some projects for which the finger might be a good logo, but i am sure that anything involving mono just isn't suited for that.

So i am assuming that the following is was what the logo was supposed to look like.

Small change, significant difference.

Oops.

Libv, the tale of a missionary.

Fri, 07 Aug 2009 02:59:51 GMT

Tonight there was some random guy sitting at the bar in our thursday hang-out, downtown, with a t-shirt reading "League of gentlemen" and a rather clueless logo to go with it. As a fan of good British humour, I stepped up to him and this is the conversation that ensued.

"Excuse me, that t-shirt that you are wearing, is it in any way related to the magnificent BBC TV/Radio Show?"
The guy managed the following in his best english: "Eh? It is some brotherhood from Nuernberg"
"Oh, so it is a local brotherhood, for local people?"
"Yeah! That's it exactly!" is what he answered enthusiastically.

I think i have created another convert ;)

Coreboot native VGA support.

Thu, 23 Jul 2009 12:53:02 GMT

I didn't exactly intend to time this in the middle of Novell's Hackweek, as my personal hackweek pretty much started the day after FOSDEM. But oh well, it finally did happen and it happened just now. And it was much overdue, since it was mostly written in the months before i even joined SuSE. And when i was at SUSE it got pushed aside while we were freeing AMD graphics hardware and were busy fixing bugs in X.org so that it could still ship with new openSUSE/SLED releases.

On the other hand, this very week, it has been 6 years since i got the EPIA-M board that got me started on graphics driver development. This might not seem that important to you, and some people have worked hard to minimalise the importance of this too; but this board has quite significantly changed the world of free graphics drivers.

Anyway, here it is, finally; Coreboot native VGA textmode!

For those who don't know Coreboot; Coreboot provides the basic HW initialisation needed to bring up a motherboard so that an operating system or other payloads can be loaded. It was called LinuxBIOS until 2008, when everyone agreed that LinuxBIOS was too much of a misnomer. Now if you want to rid yourself of proprietary/closed source software properly, then replacing your machines BIOS with coreboot (and a payload) is the way to go.

Until now, if you wanted working graphics with coreboot, you were still tied to the PCI option rom of your graphics card. This code i just pushed out makes even this last vestige of non-free software disappear.

So if you happen to have a VIA motherboard with a K8M890 Northbridge (AMD PCI-Express) with a Chrome 9 IGP, that is supported by coreboot; then you can have native VGA textmode today.

Introducing the Asus M2V-MX SE: a nice little micro-atx motherboard with AM2 support, DDR2, VIA Chrome 9 IGP. It has absolutely stellar coreboot support, and it can be often seen at trade shows, showing off working suspend/resume and even windows 7 booting. Now if you do not want something like windows 7 booting, then you can get rid of the VGA BIOS completely and get a nice working text console with, for instance, linux.

Don't ask me what sort of fancy modes you can set with this. What you get here is just 80x25 VGA textmode. Yeah, that's right; proper old-style VGA textmode, the sort that everything PC out there supports. The sort that, when things go slightly awry, you are always happy to see. The sort that has saved you so often.

It should be clear that my intention with this was not to re-invent some BIOS infrastructure to do modesetting, or to provide an INT10 or VESA implementation. To me, having fought BIOSes for graphics for the best part of this decade, that sounds pretty pointless. And as you might remember, my unichrome driver has been able to bring up un-posted hardware without issues for quite a while. What I wanted here is the basic infrastructure to see what is going wrong with a booting system, before a proper driver has kicked in, and be able to fix it without having to rely on a serial console.

This code achieves just that goal, and it consists of two parts.

First of all, there is the general, standard part, that any IBM PC compatible graphics adapter from the last 20 years should be able to use: the VGA side of things; vga io routines, and an actual VGA 80x25 modeset complete with cursor and font handling. This code was already committed late May in the hope that my EPIA-M would stop fighting back soon, and partly thanks to the font included, it was quite a big blob of code that got pushed into coreboot then.

The second part, is the K8M890/Chrome 9 specific part: initialising the hw in such a way that a full VGA modeset can use the hw happily. This is barely a few hundred lines of code.

Why just a few hundred lines? Well, this is IGP hardware, so the gpu is sitting off the northbridge, and has a (in this case, semi-)direct route to the systems main RAM and uses part of that for its framebuffer. There is also little of this running-things-on-the-absolute-edge nonsense that is so common on discrete cards. Coreboot sets up the ram for us, it sets up the BARs and io/irq routing for us; all we have to do is set up a vga mode, and fill in the bit in between.

On a board as well supported as the Asus M2V-MX SE this bring-up was a walk in the park, it basically took the best part of yesterday morning. And this exercise is very reproducable for the other unichromes as well. But the first one after this should still be my 6y old Epia-m board into shape with coreboot still (ints and VT8235 IDE *rolls eyes*), this board deserves nothing less.

Oh, one more thing; if you have an M2V-MX SE and wish to try this code, then i would like to advice you to hold off a bit. We need to still shore up the cmos settings and make it more foolproof. I seriously doubt that people enjoy having their machines stop during RAM initialisation because they tried to change the default framebuffer size. This is due to other settings in a badly initialized CMOS getting validated when the videoram size setting fixes the checksum. It shouldn't take long to fix this, and then, running coreboot on this board shouldn't be that scary for even the less experienced hacker.

bios_extract, the tool for all, err, some of your bios extraction needs.

Mon, 13 Jul 2009 11:21:16 GMT

As everyone by now knows, i dislike bioses, for a variety of well-founded technical reasons that i am not going to repeat yet again. Not only have i been fighting BIOS based modesetting for ages, but i am also involved with coreboot and flashrom, doing (hopefully) my part on freeing hw.

But, legacy bioses are chock-full of often very important information that chip or board makers are unable or unwilling to give you, even if it is just to be able to tie 2-and-2 together so that datasheets make sense. So, being able to find what you need to know from a legacy bios is an important skill to have, even though it often resembles sticking ones hand up a drainpipe and rummaging around in the muck.

Now, you often cannot just point a disassembler to a legacy BIOS image, because, in order to save space, much of the important code is to be found in compressed modules within this larger image. At boot, these modules are decompressed as soon as some memory has been set up. And while some of this code survives long after booting in the upper segments, parts of this code gets overwritten soon after being run.

There are a few utilities around to go and extract these modules from legacy bios images into individual files, but they were not always easy to get, build or use. Plus, the code wasn't always that nice, and each tool was made for one vendor and they re-used some version of the same lh5 extraction routine over and over again.

So, using some of the very valuable information and code from these utilities, i created bios_extract, with a cleaner structure, cleaner code and a very simple interface. It currently handles AMI, award (and thus also asus) and phoenix (non-trustedbios) BIOSes, and can be expanded easily to support other BIOS types.

You can find it in my fd.o git, from which it should be easy to build, as it requires nothing but glibc. And you just point it to a BIOS image, and it will happily clutter up your working directory for you.

As usual, if it isn't working as expected for you, feel free to poke me wherever you find me :)

And of course, another nice use of this utility is extracting PCI Expansion ROMs from onboard devices, like IGP graphics, raid controllers, nic boot roms, etc, for inclusion in a coreboot image. Even though for IGP devices, i am working on getting rid of this at least for unichrome.

In any case, have fun rummaging around!

Congratulations to ATIs John Bridgman...

Mon, 18 May 2009 13:16:02 GMT

... for becoming the second most frequent poster on the phoronix forums. You've finally beaten the Phoronix Newsbot. With a total average per day posting rate of ~4.5 and a rate of more than 8 for the last 100 posts, this is an amazing effort and i am certain that AMD appreciates the time you spend on this.

According to my quick calculations, at your current sustained rate, it will only take until June next year until you become the number 1 poster, beating Michael Larabel, the person who runs phoronix, himself.

Keep up the good work!

Last preparations for the X.org DevRoom at FOSDEM.

Thu, 05 Feb 2009 16:05:34 GMT

Tomorrow morning, notlocalhorst and i will fill up the car with our stuff, and then we will head off to FOSDEM, and we're destined to arrive somewhere in the early evening, if cologne isn't too big of a traffic mess.

Since the kind organisers of FOSDEM gave X.org the H.1309 room for our DevRoom, we have massive capacity this year: 150 seats! I just went to a local DIY store to pick up some more 10x powerbars. I'll be spreading 7 of those bars around our DevRoom on saturday so that those that need power in the era of 7h battery life netbooks, can still get it :)

Next to that, i'm mostly occupied by printing nametags, some posters, some schedules i can put on doors/walls; the standard stuff that happens in the last day before a DevRoom :)

So tomorrow is travelling to brussels, checking into our hotel, and then heading to the grand place to meet some other X folks for supper.

On saturday at 13:00 we'll be busy setting up the room, and at 14:00 Matthias Hopf will start of with talking about the new features in RandR 1.3. At 15:00 Keith Packard will talk about recent achievements with GEM, KMS and DRI2 in "The rebuilt linux desktop". This is followed by Stephane Marchesin giving us an update on the state of the nouveau driver at 16:00. Then Eric Anholt will talk at 17:00 about intel's graphics projects for the next year.

On sunday things will start off with Helge Bahmann at 11:00; Multimedia processing extensions for the X Window System. Next up is Matthew Garrett talking about power management. At 14:00 Matthias Hopf is up, again, but this time talking about R600_demo. At 15:00 we get Marcheu again, as well, but now talking about LLVM and Gallium3D. Then our DevRoom gets cleared out proactively by Jerome Glisse, and he will be talking about some common algorithms for shader optimisation.

After that, it's tearing down the devroom, clearing out the trash, loading up the car, and then driving back to Nue. The latter should promise to be interesting, as we will have another burgerking versus macdonalds struggle :)

Anyway, we will have another packed DevRoom at FOSDEM, make sure you don't miss it!

X.org DevRoom at FOSDEM 2009.

Wed, 03 Dec 2008 14:43:25 GMT

I am saddened to have to announce to you that that we have yet another abominable and boring X.org DevRoom at this little known and unimportant event called FOSDEM. Terrible! Why do such horrible things keep on happening?

Maybe because the Xorg DevRoom is simply one of the biggest, most interesting and definitely one of the hottest DevRooms at the most important and most well known European free software event of the year?

I'm sure none of you need to be explained what FOSDEM is anymore, all you really need to know is when it will happen this year: the weekend of the 7th and 8th of February.

This is the fourth year running that we have a DevRoom there, and the next big X event is in the late summer/early fall in the US, so the DevRoom promises to be bigger and better than ever before :)

Check out the fosdem2009 page on our own X.org wiki for the latest information, and for the planned talks and the schedule as it materialises.

The usual suspects will be there as, so expect some interesting talks and discussions, and Michael Larabel will be recording the talks again.

But in order to get a packed schedule, we still need more speakers! We have about 13 slots maximally available. Talks of about 45 minutes, about something X related, and please don't shy away from highly technical stuff.

If you have something to talk about, please contact me as soon as possible. A FOSDEM DevRoom is one of the most ideal places to reach a large and interested audience.

But everyone, mark the 7th and 8th of February in your calendars, and start arranging travel to Brussels already! And keep on checking our wiki page for updates

The truth behind what happened at Lenz...

Wed, 19 Nov 2008 00:10:57 GMT

@The Daemon: Well... I was late, as always, so i missed this scene, and i also missed Judas, as he left already so he could talk to security people quicker :p

But remind me; who was it again who blessed the bread he got with his papardelle, and who subsequently passed that bread around that table?

@The Daemon, again: It's not size that matters; it's what you do with it! In this case; actually drinking it instead of waiting for it to die first, you sloth :)

But, to answer the question: the one which isn't being touched by an X developer, of whom you never know where he has been, and the one which was paid for by a friendly toolchain developer!

Now in radeonhd: CS and HDMI Audio.

Mon, 27 Oct 2008 21:15:19 GMT

Two weeks ago, i pushed CS into the radeonhd master tree. CS stands for Command Submission, a unified way of putting high volume register and packet writes into the radeon HDs various hardware engines.

Even though this meant a massive change to the code base (dropping close to 7k and making the lot much more manage-able and handle-able.) the fall-out of it was rather limited. One recently introduced build issue, one oversight with the rewritten engine state tracking (missed because i was too busy chasing a stupid hardlock). But all in all, quite succesful.

What does this code gain us? Well, our driver is clean again, with all subsystems kept separate as much as possible. And, it gives us an easy path for adding new CS back-ends. Changes to the drm? Direct hw support, like CP ringbuffer in framebuffer (do you want some EXA render accel or textured video without drm, then this is it)? No problem, in a few hundred lines we have a whole new back-end now. So while CS might seem boring, it makes good coding sense :)

Now today i finally managed to successfully test something else: Christian Koenig's excellent HDMI Audio code. Putting this into master was long overdue, especially since Christian's code is very high quality and fuses in with radeonhd perfectly.

The Dell 3008WFP monitor we had here has not been very helpful in testing this code, but we stole a proper TV from the SUSE playroom and got this code tested that way. I pissed off a few wii players and the facility guy in the process (shouldn't you guys be doing this thing that's called work btw?), but now Christian's code finally got libv's stamp of approval ;)

So, get the current git, and either enjoy the new CS infrastructure (r5xx) or the fantastic HDMI Audio (r6xx and up) or both (rs690). And of course, if you do run into issues, tell us asap!

Oh, and to Yaloki and Henne who made it to the openSUSE board: congrats! Now where are the celebratory beers?

Belgian expat life-saver.

Thu, 09 Oct 2008 08:50:29 GMT

When i was still in belgium, i was tracking news quite heavily, i made sure i caught at least one daily journal of the VRT (first channel of belgian national TV) and one Terzake on Canvas (a more in-depth program on three important topics of the day of the second channel of belgian national TV). This was an easy thing to do, as both were repeated throughout the night, and at one point during the night, whenever i was tired of hacking, whenever i woke up, or whenever i was hungry, i would just spend an hour in front of the TV watching these programs, and stay right up to date and very informed, even though i was pretty much living like a hermite.

But ever since i started working for SuSE, and ever since i moved to Nürnberg, i have been completely without such news. This for instance, made me miss all the fun and games after the June 10 2007 belgian national election, and the wannabe PM singing the marseillaise. Finding out about such in incident months later was rather saddening for me, as i tend to enjoy seeing what games the politicians are up to in this "interesting" little country. Reading through the fragments on the belgian TVs website is not fun at all, and i have been spending more and more time reading articles on the BBC world website now.

Now yesterday, i was reading through planet.grep.be and stumbled over Frank Goossens's blog entry about automatically re-assembling the broken-up bits of these programs that are spread all over the website of the belgian national TV. I then watched the news as part of my pre-bedtime ritual, and just now watched terzake as part of my breakfast ritual. It was fantastic! Sure, the video-stream is not the greatest. Sure, there are some sound issues going from one clip to the other. But those are minor details and don't diminish the informational value of this at all.

Thanks a bunch, Frank, this means a lot to me.