|Last Preparations for Coreboot/Xorg DevRooms at FOSDEM.
||[Feb. 4th, 2010|10:21 am]
|[||Tags|||||coreboot, fosdem, xorg||]|
|||||The noise of a crappy high speed via mini-itx fan.||]|
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 :()