Contributed by pitrh on from the roomful of puffies dept.
|For a few days in September (16th through 23rd), the Slovenian capital
Ljubljana was also the World Capital of OpenBSD hacking, hosting the
s2k11: General hackathon, with
25 developers participating. We asked each of the the developers to
send us a short summary of what happened at s2k11 as soon as they'd
caught up on sleep, and several of them obliged quickly.
We published a small selection in Part 1 of this series, here we present the second installment, with insights into the development process and previews of features that may soon appear in -current and snapshots before they make it into an upcoming release.
The hackathon had 25 developers attending, gathered in a large room toghether. Here is an overview picture of the action:
In this second part of the series of the developers' own summaries we turn first to our X.Org developer extraordinaire Matthieu Herrb (matthieu@):
“ I worked on kernel mode setting (kms) for X.Org. As many readers probably already know, this is the infrastructure that allows X drivers to get information about the available outputs (CRTCs and connected screens) on a graphics card through the kernel instead of poking the hardware directly.
KMS is using the Direct Rendering Infrastructure (DRI) as its interface. It's a set of new driver independant ioctl(2)s to gather information and control the card's crtc and outputs.
During s2k11 I ported most of the driver independant code. Using a fake driver I can verify that the information is flowing from the kernel to the X server as expected or not, and debug issues found.
I also started to implement KMS support for a simple driver (I chose geode because it's simple enough and I could carry a small Alix 3c3 with me to .si for testing) to better understand what's needed at the hardware interface in the BSD kernel. Specifically, i2c busses' controllers are used to gather supported modes from monitors through the DDC protocol. I'm figuring out how to use the existing i2c(4) framework for that.
Before someone asks, this is far from beeing complete, a lot of stuff is still missing before OpenBSD can get KMS for the mainstream drivers (intel, radeon). In particular the way KMS is going to coordinate itself with wsdisplay (to handle going to/from X mode and VT switching) and the hardware-specific drivers are still missing. I've also let many locking issues for MP systems pending.
In short, important changes are due to become visible soon in the X system. Several of the major consumers of X services lives in the package system, where Jasper Lievisse Adriaanse (jasper@) reports on the evolution of Gnome and several other popular packages:
“ The monday before s2k11 started, Antoine and I merged our GNOME 3 subtree into the regular ports tree. This would give us enough time to run some bulk builds before flying out to Ljubljana where we'd focus on fixing issues and polishing the ports. So naturally a large part of the hackathon for us had a focus on GNOME and various ports that are related to GNOME. Sometime during the hackathon I committed my biannual Telepathy update to facilitate some further GNOME work. Over various dinners during the week Antoine and I discussed and for a large part redesigned the gnome.port.mk module which makes other Makefiles a whole lot cleaner (final bits were committed last week).
I also spent some time on finishing and importing some hardware related ports and finished an Arduino port (currently without GUI) started by ckuethe@.
Already mentioned by (jasper@), Antoine Jacoutot (ajacoutot@) participated in the Gnome porting efforts, and it seems he even had time to touch other parts of package related rc(8) infrastructure:
“ Slovenia was when Jasper and I planned on merging the gnome3 subdirectory in ports on which we've been working for the last few months, into the regular x11/gnome path. i.e. move OpenBSD to GNOME 3.0.
In fact, we decided to do the merge right before s2k11 so that we have the entire hackathon to fix the most outstanding issues and this is pretty much all I did during the week. There were lots of plumbing, updates and new imports required all over the ports tree.
We also started working on the updates needed for GNOME 3.2 which was starting to show up. So I had to move glib and gtk+3 to a new major version then fix some old ports that were using deprecated functions from both libraries.
Meanwhile, Landry Breuil (landry@) has been busy working on the various Mozilla products in the packages collection. Landry writes:
I didnt do much things related to the portstree (not many commits), but I've spent most of my time on getting our mozilla patches upstreamed, with quite some success (cf http://hg.mozilla.org/mozilla-central/log?rev=landry%40openbsd.org on the s2k11 time window..). That won't reach the ports tree until firefox 9, but getting patches from bug 648735 commited was quite a success!
On the mozilla front, I've done some babysitting on my buildbot (buildbot.rhaalovely.net) to ensure mozilla-central still compiled fine, and I've set up a mozilla.org mirror on ftp.fr.openbsd.org (in pub/mozilla.org). On the ports tree itself, I've finally updated x11/avant-window-navigator to a non-broken version, done a bunch of bugfixes updates for x11/xfce4, I've ported BackupPC, worked a bit on my wip nemiver port (still not working fine due to our lacking of grantpt()/unlockpt() and I've run a bunch of bulk builds to make sure the hobbits were not destroying too much the portstree while commiting their Gnome 3 work.
And of course I've enjoyed Ljubljana, the city, the locals, and the road trip I've done from France to go there through all the Alps by motorbike!
From kernel and new platforms land, Mark Kettenis (kettenis@) reports on progress in both HPPA and Amd64 contexts:
“ Mostly worked (with jsing@) on OpenBSD/hppa64. We made some good progress there. Some serious kernel bugs were fixed (things don't work all that well when your bcopy implementation isn't quite right). And jsing@ rediscovered that cross-building for a 64-bit system on a 32-bit system doesn't work because of gcc limitations. With a couple of (uncommitted) hacks we get multi-user now, although things aren't completely stable yet.
I also worked a bit on Sandybridge support in the intel video drivers to get my [ThinkPad] x220 in a usable state. And I failed at giving i386 more interrupt vectors for doing MSI (Message Signaled Interrupts).
A huge thank you to all the developers who attended the hackathon and especially to those who contributed reports. With a few reports promised but not in yet, there is enough material for a third and final installment in a few days.
Photos by Vito Antešič.
(Comments are closed)