FOSDEM 2007 Notes

Here are my personal notes for the FOSDEM 2007. I only managed to attend a couple of sessions this year, as I was chatting to people instead! Please send corrections, and keep in mind that although detailed, these should not be taken as quotable transcripts!

10:15 Met Pippin, Karl Worth and Keith Packard in the entrance hall and chatted to them about Kalliculator style stroke editing. They suggested that this can all be done in Metafont, theres just no interface!

14:00 Keith Packard,

Whats going on in right now?

Usually I talk about in an abstract fashion; today I’ll talk about Who We Are, with our photos up on the screen.

This is Adam Jackson (ajax), who is working hard on release management. 7.2 came out last week, and Xlib based on Xcc(?) and loads of cool stuff. The first release thats pushing the modular system. There’s the X server 1.3 release in the next month, to push the pace of releases up in the indivudal projects, so its faster than a 6 month schedule to get into distros. We’re now autodetecting monitors and inputs, so most of the time you can run without an xorg.conf! To be able to change things after the server started, without restarting the server, is the main benefit of this. Collecting photos for this talk, I noticed a lot of us spend time drinking.

Dave Early(?) works on Radeon driver, r300, and hes in a rare position, working in the gambling industry and has access to ATI documentation. But as it would be terrible for ATI chipset documentation to leak out in source code, he has to be careful.

Ben Herrenschmidt(?) is also working on Radeon drivers. AMD is not supporting radeon driver at all at this point. This means driver development is a tedious process, with no documentation. The r300 driver is usable, the r500 driver is just starting and 2D should be working on that one pretty soon.

Michel Denzel works on the Intel drivers.

Jeremy Fau (?) works on the Noveax drivers, but they are not usable yet. This is going to have a tipping point where it goes from unusable to very usable in a short period.

Eric Kolb, a coworker of mine at Intel. Note he’s actually drinking water :-) Tungsten graphics started the 3D driver, and at Intel we have about a dozen people working on this totally free driver. Usually conferences are a time when people working on the same codebase get to meet :-) But Eriks not here today, alas.

The team works on Quality Assurance, development, distribution - getting the drivers into distros - and we have 6 people testing that it works on legacy hardware, so you can use our newest drivers on your old i810 laptops. There’s a new texture memory management system that works with any UMA hardware - shared memory cards. Their limitations are being overcome, so we can have unlimited graphics memory using such graphics cards. I wish I had stock in a memory company :-)

Alan Hourihane, wanted stuff like rotate the screen, different modes on multiple screens, and he had this crazy BIOS modesetter with a lot of stuff on top to get this working. The driver he made was solid, but we threw it all out. There should be no need for a legacy BIOS. When everything was plain VGA, and we had direct access to the hardware, this was fine. We could reprogram the video mode with a simple and small piece of sofware. But in the mid 1990s, all graphics cards got their own modesetting hardware, thanks to Windows 95’s architecture.

A few X drivers could lean on the Video BIOS for modesetting, linear FrameBIOS modesetting, and a little code in the Xserver. Using the Video BIOS was great for fast development, right up until we realised the Video BIOS doesnt actually do everything we want to. If the video BIOS doesnt do what you want, you couldn’t do it, at all.

For example, here on this laptop I have 2 screens, the laptop screen and the external display, and my Video BIOS cant handle it. Alans code set up a display initially using the Video BIOS, and then went in afterwards and changed the Video BIOS registers.

Thomas Winischofer, (?) said this was a bad idea, and we want to do a lot of things the BIOS cant do, and native modesetting started here. Its still early in its development though.

Ludviq Hagen, doing the same thing to the Via driver. There are 2 Via drivers, the old BIOS one and an entirely native modesetting one.

Daniel Stone, an Aussie working for Nokia in Finland, on their Internet Tablets. They really wanted Bluetooth input devices, and that means multiple keyboards. So with classic hacker foo, there was this tiny feature that the management wanted, and it got blown up into a massive free software project, reworking the X Windows Input System, to replace all the old stuff to do with keyboard inputs. So now you can start an X server with no input devices, and hotplug everything.

Peter Hutterer, his friend, an Austrian living in Australia, Adelaide, is working on multiple pointers - as in, multiple pointer inputs plugged in with multiple points on the screen, at the same time. I’ve watched him use 3 mice at once, with his chin! This requires a new window manager, but then you can grab the handles of a window with two pointers at the same time. This could well be expanded to deal with multitouch screens that input all ten fingers. It has multiple cursors working with the core protocol, so that the existing architecture still that thinks theres only one cursor. One window manager worked out of the box, Fluxbox, and you can move two windows at the same time. We got him over to the X developers conference!

Professor Bart Massey, another Portland resident, did Xlive. When we had 1 CPU. For the entire lab. So thread handling and multiple applications were not such a big deal. This is before shared libraries. In 1987, there were no shared libraries in any UNIX system, which I know can be hard for you guys to imagine today. To keep program linking from breaking, Xlive grew and grew, with internationalisation, even colour management. It was huge and bloated. The University of Portland rewrote it in to a 30x smaller codebase.

Jamey Sharp, did XCB implementation work, and lots of cool automation of Lisp/Python/etc bindings. Until now, every Xlib marshalling function was done by hand. In the last year, we found half a dozen buffer overrun bugs, caused by bugs in the protocol unmarshalling code. The bugs were there because it was all hand written. So we’ve made a descriptive XML format, and we will keep having root exploits until we get this XML description going. XCB is going to be a total replacement for Xlib, and distros will have it soon.

Matthew (?), is working on Zephr. We used to have Xnest, which was kinda cool, despite creating remote objects for everything you were doing. Zephr is a dumb framebuffer based Xserver, so you get all the whizzy new extensions locally that are rendered remotely, and you can detatch. And you can dither down 24bit if the thin client can’t support that. Matthew is at OpenHand, who work on things like Nokia’s Internet Tablets and such. They do other X work too, such as Xrestop, centered around embedded work - and for embedded work, the main problem is running out of memory.

Eric Andholt, is working on eXa, new acceleration. The goal is to be able to write REALLY FAST X servers. With the new shared memory stuff, we can do ALL the acceleration we need to with the graphics rendering. It used to be that we thought we needed to do some things on the CPU. Since everything can be done on the video card, given enough memory, the paging of GPU memory can be smarter. EXA will become a viable acceleration architecutre this year, and things will be good.

Jon Palmieri, (J5) is a One Laptop Per Child guy. Jim Gettys talked this morning about OLPC, and for me its not more important than any other platform, but the whole OLPC platform is very important. The large number of units and the low CPU performance is pushing improvements.

David Reveman, made XGL and Compiz. Compiz recently got plugins, and David is now working on transforming input as well as output. In Mac OS X Expose, you cant manipulate the windows in a exposed state. You can drag them round, but not manipulate them. But if you want a screen magnifier, for example, you want to do this. He’s solving this now, and its a hard problem, and really the final piece for compositing architecture.

The Xorg board elections were in fall 2006, and Eghert Eich is here at FOSDEM. We changed things at the board level, so if a group of X developers want to meet to sprint on something, we can help sort this out for them.

Matthew Herb, an OpenBSD developer, is responding to the security alerts we get, and ensuring that bugs are closed, and disclosure happens on time. OpenBSD gets credit for its OpenSSH support, but Xorg is getting a really big hand from him and the OpenBSD crowd, which is important to recognise.

14:40 Questions

Q: What about moving the drivers to kernel space? A: There are a lot of pieces to a video driver. The 3D drivers have significant kernel parts, that just cant be done anywhere else, as they have to manage interrupts in the kernel. Also modesetting is going there - to support suspend/resume, and to be able to handle panic messages that come up on the console. ALSA takes a similar approach.

Q: Thoughts on OpenGraphics - the “open source” hardware people? A: I’m all for it and want to see their code in the Xorg tree.

Q: Thoughts on XGL? A: In OpenGL, what looks good, is good. OpenGL displays are usually used in animated environments, so the quality is much more about performance, and GL implemenations go for that instead of some abstract spec. This is okay for video games and CAD drawing, but its not okay when you’re doing 2D and looking at text and icons being drawn on the screen with several pixels out of wack. Building an X server on an existing OpenGL library means you feel very constrained when exploring the quality/speed space. Maybe OpenGL will get there, but 2D is very simple, so the pain on the OpenGL implementors for the payoff doesn’t make sense at the moment. Perhaps we can retain the 2D API, and Glucose is a project to do this. You have a 3D library that works, so instead of writing code to the hardware, you just call the 3D library. With AIGLX, you can call 2D operations using 3D calls, but as a driver function call instead of being integrated. Its a slow and steady migration. For me, a combination, using AIGLX, makes more sense than XGL style appraoches.

1505 LinuxBIOS

There are drivers that fail only in the BIOS. Vendors are faced with maintaining their own driver, forever.

Its simpler and cheaper to have the same drivers in the BIOS for the OS.

The “DRM BIOS” issue. Intel EFI is a DRM bios, since it has unlimited control of your memory and I/O, and implements a full network stack. So the BIOS can veto your I/O, and report your being veto’d over the network. By design. I know people at banks who are very unhappy with this. They thought they were running GNU/Linux and knew what the whole thing was doing.

A few years ago Intel were explaining the cool EFI stuff, how EFI can download a new version of the BIOS and burn it to flash, on its own. They explained how convenient this is - but chaos went off when the banks heard about this. For the banks, like LANL, when we buy a consumer machine, we either demand full, buildable, source code to their BIOS, or that they ship LinuxBIOS, now.

The BIOS is a bootloader too - do you really want to write a new filesystem driver for EFI or in Forth? I don’t. And its slow. EtherBoot used to be the fastest way to boot, and you’d think it has less stuff to do, so it would be faster. With LinuxBIOS, there is so much overlap, its actually quicker than EtherBoot.

One day, at a 4096 node cluster, all machines had rebooted, and every single one said “Press F1 to continue”… I cant name the lab or company, they are so embarrassed. What do you want to see when things go wrong? “CANT BOOT DISK. OK.” What is okay about this?! I want to see a shell prompt and a set of busybox binaries.

Extending the BIOS for debugging is so simple with LinuxBIOS. Some hardware needs a process running to function, a process from proprietary hardware, which is particularly hard to reverse engineer at the moment. Such as this Vaio, which requires an Intel ‘regulatory daemon’ thats binary only. Another extension would be to have a WPA supplicant in the BIOS so you can connect to a modern wireless network at boot time.

The future is more complex BIOSs, and freedom wins yet again. Newer drivers are more and more complex.

So what does the Linux kernel need to do hardware startup? Enable and bug fix the CPUs. Hardware needs to be discovered, configured, and enabled. Before PCI this was hard, PCI was easier, and an OS ought to be able to confgure hardware with no help from firmware. Generally, if you know how to make Linux kernel do things, you know how to make LinuxBIOS do things.

The first version was very simple: jump straight to kernel. This didn’t work because of the “DRAM problem”. This is the hardest thing to do on any kind of machine.

We can do SMP startup with Linux, and this is the first Pentium SMP startup in C that we know of. The AMD K7 required SMP to be done very early, so LinuxBIOS is a SMP BIOS. This is now becoming really useful with Opterons.

In 2000, we were fitting 2.2 kernels in 512kb flash with ease. 2.4 ended this - the penguin got fat. And the flash on motherboards shrank from 1Mb to 512k to 256k. In 2002, this changed things a lot, and LinuxBIOS wasnt really Linux and it wasn’t really a BIOS either. But in 2006 we returned the project to its roots, thanks to motherboards with 2-16Mb ROMs that make a full Linux kernel and Busybox easy again. “NAND flash is free”. Our work with vendors suggests its the most favoured payload so far, despite is offering a lot of payload options.

Google offered Stefen Rainer of CoreSystems money to do Quality Assurance. We have asynchronous development, with 50+ motherboards, and no developer house can keep all supported boards in house. So we have an automatic, distributed test at every commit. Flashing a BIOS has risk of bricking, but we can recover from bricking! The “bios saviour” you cant buy any more, we’ll need to solve that soon.

So the idea is that MSI, Tyan, so on, can set up these “systems under test” servers for their stuff, and if they find a problem, and fix it, that may help other companies. This is an ideal example of the cooperation the free software community is known for. So we have some really nice test results on the wiki pages, using the DejaGNU test framework to build it.

CoreSystems is looking for people to join in!

I talked about Version 2 so far, because the Opteron was so advanced with its 3 processor busses. Version 3 will be different, designed to be an easy to use system, for ‘casual’ users, like BIOS engineers who need it 2 days a year. This will use the Linux kernel’s Kconfig system, and we’ll minimise the use of stuff thats giving us problems, like ldscripts. One big change is the removal of our ‘romcc’ C compiler, in favour of cache-as-ram, now that we know how, and cache-as-ram is on most major chips today.

And: Poltics. We can’t escape it when the opposition is non-technical. We continue to push on vendors so they can see there is a business case for freedom. Intel don’t release documentation on their chipsets, such as 440LX, and theres one document about how to program SDRAM. 3 years later, there is just NOTHING out there, and you need an NDA to see anything at all. So we need to deal with this kind of political stuff, and we really need to show people we mean business.

AMD/Nvidia released all the information needed to do Nvidia chipsets, and we got a bunch of boards working all at once! This was the happy ending of a story that started with me contacting Nvidia in 2002, who said “Tell us how many million chips we will ship if we do this”. My advise for dealing with politics: Don’t demonise people, but don’t give up pressure.

We show that the highest quality BIOS can be done as free software. LinuxBIOS has wide usage - it boots millions of machines! - and in systems you and I have never heard of. People simply like computers that show something on screen as soon as you hit the button.

Now we need help to get it into your laptop. We want your help and support. The laptop guys in IBM stopped our guys in IBM, and then the laptop guys got sold to Lenovo. So if you have ideas about who to talk to, for any laptop manufacturer, please do let us know!

To conclude, I’d like to mention Brandon Howard’s Febuary 22nd 2007 annoucement of LinuxBIOX code for the M57SLI-S4. We think the next hurdle is “M57SLI-S4-LB” - to have it ship with LinuxBIOS preinstalled. AMD is being really great here, so support them by chosing this board next time you buy machines!


Q: Will it boot my OS of choice, like OpenSolaris? A: FreeBSD still wants to make BIOS calls directly. This is a bad idea. I heard OpenSolaris works.

Q: How to install?

A: Go on the list, and ask if anyone has experience with the motherboard that you’re using. Sometimes you’ll just get an image. BuildROM wil pull down what you need and built you a kernel, an initrd, and an image. The mailing list is the best place to start. Also, get a second BIOS chip, get a chip claw to ease installation/removal, and then you can always swap out the chip if you brick it. These parts are only be a few euros, and we sometimes organise group-buys on the list, so ask on list if you’re going to do that.

16:00 I randomly met the legend that is Rob Savoye, and spend pretty much the whole day hanging out with him. He had a B2 OLPC, and we were showing that off at the Fedora booth - I got to play on it for like an hour, and its awesome.

1315 Bling it up - Mirco Muller

So, whats all this Cairo/XRender/EXA stuff? Cairo uses XRender. XRender is what really brought X to modern times. EXA is the acceleration architecture, so that all the things XRender wants to draw are passed to EXA and drawn to/on the graphics card properly. EXA replaces XAA and KAA. On top of these is Cairo, an API on top of Xrender that makes ‘bling’ accessible to programmers like you and I. This is not restricted to Xorg though.

Why are we bothering with bling? I think there are three main reasons:

  1. Competition: The proprietary operating systems do it. Some are good, and some think they are good. So its foolish not to step up and give them competition, as operating systems developers! :)

  2. Users: Both application developers and end users have raised expectations, because of proprietary competitors.

  3. UI Designers: They gain more artistic freedom, and can put it to use for real usability work, like the tango project - which does not mean just icons, but also proper transitional effects for dialogs and application switching and so on. Its not just an on/off binary like interface, the toolkit level effects are important.

Ultimately: Sex sells.

Don’t underestimate the power of looks - if A looks good, and B has something technically better but looks worse, people go for A.

Most Flash applications are better at this stuff than any operating system’s native toolkits, for all platforms. This is not cool.

Where can we make good use of bling?

Everyone always talks about Compiz, but this is just part of the equation. Compiz is window level effects, and does not work on the toolkit level. All the translucency and animation stuff that Compiz does for window frames needs to happen WITHIN applications.

GTK+ itself is getting this, such as with offscreen widget drawing that does some work for this kind of thing. Its planned and will be in there soon! GTK+ theme engines also help with this to an extent. Murrine and Clearlooks already do some things, but it could go a lot futher. Neil J Patel has some mockups on flickr, Jeff Waugh blogged about it recently. I hope the Clearlooks, Murrine and other guys will work together on something, as there is A LOT you can do with Cairo.

Canvas libraries: libccc, goocanvas, clutter - by openhand guys, pigment - a canvas-like thing used in Eliza and by Fluendo. Somewhere in all this we have what I want for GTK to become more like how I’d like it to be: Possible for totally customised apps, with UIs way out of the HIG, and for special devices like N800 and cell phones.

Now some demonstrations!

And now for my Dos and Donts.

Do ue native surfaces, on X11. use cairo for backend.XCreatePixmap() and cairo_xlib_surface_create().

DO SURFACE BUFFERING. update buffers i configure-handler, or when the geometry changes.

Do use glitz, when its available, tho this only benefits surface-buffering.

Do clipping as much as possible with cairo!

Don’t use images surfaces, avoid cairo_image_surface_create()

Don’t ignore clipping

So lets walkthough one of the demoed effects.

Inkscape is a real workhorse for all this, and in combination with librsvg things are good. Tip: Put UI elements in separate layers of an SVG.

Also, keep in mind laptop/battery powered users, because burning CPU means burning power. For smooth animations, aim for 60fps, as its not too much and not too choppy, although 30fps is okay. With hardware accelleration in place, hitting 60fps is not a problem.

Common mistakes?

Not clearing the context/surface.

Forgetting the stroke() fill() paint() and _preserve() calls!

Conclusion: Cairo and glitz still need to get faster. Hardware accelerated filters in Cairo will be good. The clock has tiny drop shadows on the handles, but Cairo doesn’t directly support any kinds of filters. Maybe I’ll work on this. Xorg and EXA drivers will sort things out very soon I’ve heard this weekend! Canvas libraries will do all the heavy lifting and thinking in the future: libccc, goocanvas & friends. GTK+ needs some (a lot?) of rework for sophisticated UI toolkit level effects. Maybe this even needs a REWRITE? (ducks! :) I don’t know, I just want to use it, I don’t care how it happens.

And how to obtain source for my demos?

$ git clone git:// $ git clone git://

1350 End

Creative Commons License
The FOSDEM 2007 Notes by David Crossland, except the quotations and unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.


Leave a Reply