X.org DevRoom at FOSDEM2010
Time: Sunday, 7th of February 2010.
Place: At FOSDEM 2010 in Brussels, Belgium.
X.org will this year have its fifth X.org DevRoom at FOSDEM. The goal of X.org DevRoom at FOSDEM is to have X developers meet, discuss and hack and X.org will have a very clear presence at one of the most highly regarded Free and Open Source community events. So FOSDEM is the perfect place to get exposed to both the X.org developer and (advanced) user community.
X.org at FOSDEM Schedule
Sunday, 7th of February 2010:
12.00 - 17.00: X.org Devroom.
A DevRoom is a project/topic specific room on FOSDEM, holding up to 60 people. It is public but doesn't tend to draw the crowds the main FOSDEM talks tend to get. In general, the FOSDEM public consists of developers and more advanced users and people interested in X.org and the topic in the talk scheduled then will attend such talks.
The DevRoom is free and open to everyone, there is no registration required. If the devroom is dangerously full, like during the 2006 Xgl or the 2008 Gallium talk, you will just be denied access
Due to FOSDEMs Distribution mini-conf, we will no longer have access to the enormous room we had last year (which we used rather well). We have room AW.124, in the building across the main campus road from the main building, which has some nice luxuries like some windows for ventilation.
On Saturday, the 6th of February, the same DevRoom as the X.org one will be used as the coreboot DevRoom. Due to limited coverage, on Sunday, from 9 until 12, the DevRoom will be used by the OpenMoko project.
DevRoom Talks Schedule
The fosdem website also has a page with our schedule.
Once again, Michael Larabel from phoronix will be covering this event and even produce HDTV videos this year.
Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status.
The GPU is one of the most complex piece of hardware in modern computer. With kernel modesetting, more part of the driver move from userspace to the kernel allowing a cleaner support for suspend/resume and others GPU specific handling. The complexity of OpenGL driver, and also driver for new API such as OpenCL, are in userspace and will more than likely stays there. This presentation will look at the uniq problem of GPU kernel API to userspace. How userspace can interface with the kernel to submit GPU command in an as efficient as possible way. A brief review of what have been done and what is done now for various GPU, and insight on what might be better solution in the future will be given. Last part of the presentation will devolve to the status of radeon kernel modesetting which is now the largest driver inside the linux kernel with more the 70 000 lines of code and supporting more than 7 different GPU families.
Mikhail Gusarov : X on e-Paper.
e-Paper is a relatively new display type with very unusual characteristics. Some of them, such as greyscale, bring back memories of the distant past, whereas others, like a 1Hz refresh rate, are completely unique. This talk will outline the special requirements that e-Paper imposes on X.
Daniel Stone : Polishing X11 and making it shiny.
There are a few niggles about X11 today that mean every embedded device vendor patches the server in various unpleasant ways, whereas on the desktop it just looks suboptimal and we suck it up. This talk will cover a few parts of X11, such as client-side cursors, the video API, Composite, RandR, which currently need to be improved to make X11 look as good as it possibly can, without going to Wayland or X12.
Luc Verhaegen : The free software desktop’s graphics driver stack.
4 years after the modular X tree was released, we can clearly see that we did not fully satisfy all expectations and that we are really holding the free software desktop back. In this talk, the current situation gets analysed, and the next step, providing more integrated graphics driver stacks, a change that will make life easier for all involved, is introduced and demonstrated.
Nicolai Hähnle : Towards GLSL in the r300 Gallium driver
After a very brief overview of some relevant details of the hardware-level programming interface of Radeon R300-R500 shader hardware, I explain the high-level structure of how fragment and vertex programs are compiled in the modern Gallium 3D driver and how we got there. Finally, I talk about the big remaining challenges for full GLSL support.
This is a fairly technical, hardware-specific talk. However, it is kept (hopefully) understandable to people who haven't spent hours writing shader compilers, and there will probably be some musing about which parts of code could possibly be shared with other drivers in the future.
The social event, which was reduced to just getting a table somewhere anyway, will be decided Ad-Hoc.
Further FOSDEM information
For more information about the FOSDEM event, there's always the FOSDEM website. It includes city maps, information about transportation and a list of hotels.
If you would like a complete overview of FOSDEM, then maybe last years site will be of interest.
Registration and further information
Feel free to just mail us, libv at skynet dot be and eich at suse dot de, or the xorg mailinglist, or poke us on irc in #xorg-europe on freenode.net.