Called keithp up today and asked, "if I got a merge of RandR 1.2 to master ready, should I push it?" We agreed yes -- the protocol is where we think it will be in the final release, so we're satisfied with putting it into the main development branches.
There is remaining work to do, for sure.
- autoconfig stuff from xf86-video-intel hasn't been pushed to an xf86 randr generic layer.
- manual config stuff hasn't been written.
- more of the xf86-video-intel helpers, and ddcProperties.c code, needs to be made generic.
- Some bits of protocol don't do enough on the server side (property changes don't call into the driver).
- Some bits of protocol don't do enough on the client side (XRRSetCrtcGamma() is awfully short!).
- modesetting of xf86-video-intel hasn't been merged to master.
However, this is a pretty big milestone. The rest can be filled in with much less inter-module versioning trouble, and in relatively short order I hope. The main thing is a protocol that we're happy with, and believe we could use to write generic desktop environment support for mode setting.
Published on
November 18, 2006 in
FreeBSD.
We’re actually in pretty good shape (hah) on 6.2. 6.2-RC1 has been built, uploaded, and announced, and kensmith@ released the code freeze for the RELENG_6 codeline. This means essentially that developers are free to begin merging work that will eventually become FreeBSD 6.3, although we do request that major changes be coordinated with re@ until 6.2-RELEASE is finalized.
On top of that, kensmith@ and I worked off (I think) all of outstanding MFC requests in re’s queue this morning.
I need to go look at some stuff with the recent 7.0 snapshots (announced by kensmith@ today). If for nothing else I need to update the CURRENT manpage set on www.freebsd.org (there used to be some part of this that was automated).
Published on
November 16, 2006 in
FreeBSD.
kensmith@ created the RELENG_6_2 release branch today. This is the codeline that re@ will be using to finalize 6.2-RELEASE. All of the release candidate builds, as well as the final release, will come from this codeline, and after 6.2-RELEASE, we’ll turn over control of this branch to the security officer team. They’ll then use it as a security fix / errata branch.
I was reminded today of how difficult it is to multitask well (in human terms)…basically I broke the release notes build by trying to give advice to kensmith@ and pay attention to a meeting at the same time. Bad Bruce, no cookie.
The 6.2-RC1 build should be happening soon (probably would have been sooner if not for the aforementioned breakage). It’ll have the latest round of fixes for em(4), and a number of other bugfixes and stability enhacnements. There are still a few more MFCs pending that will happen after this build, but the plan is that what’s on RELENG_6_2 now will be fairly close to what we ship.
Followers of FreeBSD events might know that a physical relocation of many of the main FreeBSD.org machines will happen this Friday. I wonder how many committers will be going into withdrawal as machines go off-line during the move.
Published on
November 8, 2006 in
FreeBSD.
Last weekend was good fun. Friday night was nerd night (Rifts RPG) until the usual early-morning. Then Saturday there was idr's lan party. 16 people playing games in one basement. Kind of amazing, and good fun. There were some rough spots, though, such as me trying to install Windows on the new hardware to play HL2 games we had scheduled. I was really amazed once again at just how bad driver support is on Windows. I really need to look into wine on the Mac Mini (and some driver optimizations) so it can be the portable, branding-compliant gaming box.
Modesetting is continuing along. I've got CRT and SDVO outputs reliably reporting their connectedness, which is important for deciding which outputs to turn on when you've got a system with potentially 5 of them (CRT, LVDS, SDVO, SDVO, TV). RandR is slowly shaping up, and we're cutting more old cruft out of the driver. I think the next thing I'm going to do is hook up the LVDS panel fitting output property, so we've got an example of that working and can test that code path from xrandr12 all the way to the hardware. Then we need to get sensible-defaults code finished for initial output configuration, at which point we can decide if we even need to write a bunch of nasty xorg.conf support for output configuration, or can leave it up to post-startup.
I also set up a cronjob of doxygen for the X Server and xf86-video-intel on annarchy. I'd been talking about doing this since I first worked on EXA doxygen, but finally got around to it now. You can check it out at
http://people.freedesktop.org/~anholt/doxygen/xorg/ for now. The xserver bits are woefully under-documented -- DMX and EXA as far as doxygen go. xf86-video-intel is getting better in the modesetting branch, I think, but I'm still not satisfied. I'm also not happy with doxygen's output in many cases, such as the struct _ExaDriver that should have been called ExaDriver, or when I want to describe a group of fields with one block of description. But I'm pretty sure it's better than nothing. If anyone else has git trees on fdo that have doxygen, I can try throwing them into my script to generate output periodically, too.
