X Window System Release 7.3
2007-09-06

The X11R7.3 release incorporates the 1.4 version of the X.Org X Server, which
is most notable for the addition of input hotplugging support, with device
detection managed either through HAL or a dbus-connected manager.

Also new in the X Server since X11R7.2 is the 1.2 version of the RandR
extension, which allows for runtime configuration of outputs within X Screens
and an improved static configuration system for multihead in a RandR 1.2
environment.

This release also rolls in a new driver, xf86-video-vermilion, and re-adds
the xf86-video-glide driver which had been present in the monolithic releases.
The xbacklight command-line tool is also added for configuring backlight
properties through RandR 1.2. Other modules have also gone through the usual
host of updates and bugfixes as well.


Previous release managers may find me strange, but I didn't mind too much dealing with the release. It was approximately the expected level of stress and frustration. I made some changes this time around which greatly reduced the burden -- the old "branded" tarballs (modulename-X11Rwhatever-version.tar.b2 instead of just modulename-version.tar.bz2) are now a thing of the past, and the published directory structure is simplified. I've update the wiki instructions for the next release manager, and it's relatively short. Basically the only work that's left is what should be left -- making sure all the modules work well together, and making sure the blocker bugs for the server get resolved.

As far as that, I think it was a mixed result. Blocker bugs for the server I think I handled reasonably well -- hounding the appropriate people for the critical fixes, and not blocking to deal with the last-minute fixes for minor issues. But the whole-release integration didn't go too well, with at least one required module update having been left out initially (fixed this morning). What I hope we can have happen for the next katamari:

• I'll tinderbox the proposed module list in our ports tree to shake out integration issues.
  
• Module maintainers may update util/modular/module-list.txt to make sure their stuff lands in the next release.
  

This GUADEC has been excellent. Not quite the same environment as the last one, since we're hiding in pubs from the rain and general Birmingham dreariness, instead of getting naked in the Mediterranean, but I think the general quality of talks has gone way up. My talk (on gnome-power-manager improvements) seemed to go over pretty well, and discussions with gtk folks were great, particularly at daniels's talk tonight.

I finally took the two days needed to sit down and type out the DRM ioctl cleanups I'd committed to do at a conference probably two years ago. I tested it on FreeBSD and it worked great. I passed the branch off to daniels to test, and he said "woo glxgears works. push!". Apparently he was too far gone to notice that DRI hadn't initialized at all, so the linux side of the DRM is totally busted. But hey, it's not like I was more sober, and I wasn't going to turn down pushing +2000, -3000 lines of diff.

Now I'm working on fixing up DRM mapping on FreeBSD to be less terrible, and writing some support code in the process that will be important for kernel memory management.

keithp and I have just pushed the support code for the 965GM (laptop graphics chipset that will be available soon) to mesa, drm, and xf86-video-intel. The remaining piece is agpgart, which we just haven't done the lkml submission for yet, but if you check the patches for those 3 projects, you can probably guess what the agpgart diff looks like. It wouldn't seem like a very big addition, since it was something like 100 lines total, but there's something cool and new here: We've managed to get the ability to push the code before the chipset launch. Previously, chipset support like this has been released early only to distributions, who then try to have packages ready to go for that day (often with bugs or integration issues due to only having received old snapshots), but this still meant that you couldn't just grab a released distro CD and pop it in your machine and go. Now, there's a much better chance of this happening, depending on how your distro's release cycle aligns with ours.

Getting even little policy changes like this really gives me hope that we can fix hardware vendors to do the right thing with open source software. Ultimately, it's in their interests.

I just found out today that I had totally broken i855 LVDS support in the modesetting branch, and while fixing that, I realized that our i855 LVDS support had been pretty broken since its inception.  With some digging, I found one bugzilla entry for it, but several emails.  Please file more bugzilla entries for bugs, folks, and don't worry about finding the right bug to attach to -- more individual bugs means more a better chance that I'll end up fixing your bug instead of some less important one of someone else's.

So, if you're trying to use the modesetting branch on your i855 and having troubles, please try http://people.freedesktop.org/~anholt/i8xx-clocks.diff on your driver from a fresh boot, and either:

1) Tell me that it makes your system work
2) File a bugzilla with Xorg.0.log and a note that you tried this patch.

Today I got to implement my first X request, from design through working code. It's a simple one, but the results are nice.

Up until now, DRI clients haven't been able to report damage. As a result, screencast programs haven't been able to use XDamage to do minimal screen-scraping when GL apps are running. I added a request where you simply hand an XFixes region of the area to be damaged plus a drawable, and the server reports that damage to that drawable. The DRI drivers in cooperation with the GL library now use this at SwapBuffers time to report the drawing they do to the screen.

I tested this using gstreamer, which let me easily create a screencast that displayed on the same screen. The command I used was:

gst-launch ximagesrc ! videoscale ! video-x-raw-rgb, width=400 ! ximagesink sync=false

There was only one issue: gstreamer folks still haven't committed my improvement #342463 to ximagesrc. So if you run glxgears for example, it overwhelms ximagesrc with damage rectangles, and within a few frames it's ground to a halt trying to catch up. Someone needs to commit this (or just OK me to give myself a commit bit :) ) I ended up sticking a sleep in gears to slow things down enough for now with stock ximagesrc.

I didn't actually do this for screencasting, though that was originally why I'd thought about doing this extension. We'd run into a problem with RandR 1.2, which allows for each CRTC to have different rotation, so each CRTC may need a shadow buffer for its rotation of the framebuffer. This means the server wants more control over rotation, which was already a mess to support in the previous architecture of the DRI driver doing the shadow buffer update on its own using rotation information we jammed into the sarea. Now we can nuke a bunch of support code and do shadow updates for rotation entirely within the server, with no concern for 3D.

Next things that could be done to build on this:

• Make AIGLX support the new DRI method for damage reporting so screencasters work on it, too.
  
• Merge to server-1.3 branch once we branch that off of randr-1.2-for-server-1.2 so it hits the next X Server release after 1.2.
  
• Fix the driver to report damage for glCopyPixels and front buffer rendering
  
• Fix libXvMC to report damage for its direct rendering.
  

Spent some time again with my nemesis, the i830 laptop. With our new native modesetting, we have to know how to program every output chip on every system, and before the 915G there were a lot of chips. For the desktop ADD cards, this hasn't been hard -- look at the name on the chip, go look up the open documentation, implement, done. For laptops, it's a little uglier -- I can't see the chip without tearing the machine apart. And given that this machine is already rather flimsy, I wasn't too excited about tearing it apart and hoping it's fine after getting it back together.

I thought these laptops had Chrontel 7017 parts, generally. So a while ago, I tried writing a driver for that chip. I started it up, and I got no probe from the hardware. Hmm.

Well, I've got some BIOS source code, and each of the add-in drivers has a few strings in it. So I dumped the bios with some handy code I had, and ran strings over it. I found an instance of "ivch" and none of the other strings from drivers I had code for. So it seemed like a good guess. I found published docs, whipped up a driver, and got no probe again.

So we tried tracing what the BIOS did using mjg59/airlied's neat little tool. Unfortunately, the old driver doesn't use the same mechanism to talk to the graphics chip, so the log of the trace was rather short and uninteresting.

Then I decided to just see if I could get anything from I2C. I wrote code to try to read 1 or 2 bytes from every register of every possible slave device from every GPIO pin pair. And I got... nothing.

So today Keith and I sat down again and tried disassembling the machine's actual BIOS to try to confirm what it was doing. We confirmed that it had the ivch driver, in use, and that it was on the GPIO pair and slave address we initially expected. So we tried to run the BIOS code again just to confirm it still worked, and it can't set a video mode at all any more. And then we tried starting X with the BIOS-based modesetting driver, and that failed too now -- the backlight turns on, but nothing is displayed.

So, I think we killed our i830. Getting this one was hard -- scrounging through FreeGeek's laptop room, and finding one of them in the many 10s of laptops we looked through. I'm not sure where I'm going to get another.

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.

Well, I'm online at the new house. We got internet Monday morning, after shockingly short Qwest adventures (only a 4 day outage instead of a scheduled 1 day outage, which is a record for them). We were moving boxes from Friday night through Sunday, and things have now quieted down to unhurried unpacking and slow migration of furniture towards final destinations. The problem is, any moment when I need a break from work, there are still boxes waiting for me, and we're not even done cleaning the old place (which needs to be done by the 30th). Owning a home is pretty nice -- no more worries about when we're going to have to move next, and the people I live with are wonderful. We're planning what improvements to make, and I'm figuring out what to do with the yard, which has great potential. So far the surprise things that have needed to be done haven't surprised me that much -- ~$300 to home depot so far, with about that much on the list again for next time.

In coding news, I got the Mac Mini up into X with DRI on FreeBSD today. There was a kldload bug that had been fixed a while back and I hadn't updated past, and an AGP bug that Linux has a variant of as well. I've got my FreeBSD fix nearly tested to satisfaction, and I think tomorrow I'll be testing the Linux fix.

Huge updates for me. In the last month, we found out our house was going to be put up on the market. Within 3 days, the landlord had accepted an offer, and we had our notice. I had tried to put an offer in, but he accepted another. So, after some fast-paced house-hunting, I found a sweet 4-bedroom place on 53rd and Stark that's newly remodeled (especially the kitchen), has no major issues we've been able to find, a decent back yard with plenty of sun for some gardening, and is still roughly within the neighborhood I wanted to be in. I'm excited, and we're (no, "I'm", I guess) getting keys in less than a week. Incidentally, the offer on this house fell through, and we're all guiltily experiencing some schadenfreude.

Our new housemate is wonderful. She's funny, likes boardgames, is generally clean, and can deal with confrontation in the same way that the rest of this house can't. Plus, she's a prep cook at a nice restaurant, and brings home tasty food. Pretty much your optimal housemate. Even when she was told during the move in process that oh by the way we were probably going to lose the house and have to move in a month, she was cool with that.

Work's been going well. Projects are stacking up, but at least I'm writing open-source driver code like I wanted, and I'm still learning new skills. Recently that was lex and yacc, which I'm ashamed I'd never learned before.

I'm also starting a group to look at converting the FreeBSD repository to git. I've put up a wiki page on the progress, and alexbl and I have been talking about what we should do to come up with a credible proposal. The more I look at git in comparison to hg and svk, the more I'm convinced that it's the right choice not just for xorg but for FreeBSD. Sadly, tonight's conversion experiment failed, and I've got to either fix parsecvs (probably a weekend project, if I had a weekend) or look at the tools that mozilla is using for their conversion. Apparently they're using cvs2svn followed by git-fastimport, taking about 2 hours to convert a repository of comparable size to ports or src.

In my free time, I've been trying to get AGP working in FreeBSD on the G965 I've got sitting next to me. The current patch is here, and it doesn't work yet. Bonus points to whoever figures out what I'm doing wrong.

I did some more work on the xorg modular ports for FreeBSD today. Bunches of dependencies are fixed up, there's a working libGL, and some server updates. At this point a lot of the work left is tedious little stuff -- adding comments and descriptions to the ports, adding a couple more missing packages, and fixing up dependencies and a few plists.

The big step remaining is going to be when we test setting X11BASE=${LOCALBASE} in bsd.port.mk. This will likely have significant fallout with ports that assume X11BASE=/usr/X11R6, though in theory ports are already clean for this (Ha! Ha!). And then after that we have to come up with some sort of script for people to run to migrate their existing systems' X11BASE over to LOCALBASE. That may be ugly.

I've arrived at GUADEC, and started pushing out patches I wrote on the plane. First to land were new linux_dri ports, so we can run googleearth. Man, someone needs to write an open source version of that program. Then dri-devel for the r300 users. And finally, a cleanup of agp_i810.c that will make adding new PCI IDs cleaner (it was one of two things that have bothered me about agp_i810.c), and slipped the i945 IDs in commented out so that it'll be easy for mux@ and company to test.

Now, people are all excited about the hotpluggy modesetting stuff I'm working on. I need to finish that up. I'll get to nuking the extra copy of libdrm (unfinished patch from the plane) later.

I'll be flying out Saturday to head to GUADEC. It's 9+ hours on the plane, but I'm still really looking forward to this -- conferences with desktop people are always fun, and I think we've got some neat WIP stuff to talk about with where we're taking xf86-video-intel's modesetting and what that'll offer for configuration.

In preparation for lots of travel again, I finally got my suspend/resume working. It turned out to be easy -- I had to disable the ioapic (sad because it means no hwpmc, but it sounds like jhb might get to it some day), and I had to set a flag to tell the mouse driver to poke the mouse and see if it wakes up. It sounds like the flag might become the default soon, at least.

I've also made a dummy driver to turn off unused devices in my system. There's a sysctl to do this by default for anything that doesn't get a driver attached, but it causes issues because sometimes other drivers are relying on the functions of another device that doesn't specifically have its own driver attached. For example, I bet setting D3 on the windows dummy second head device of my graphics chip wouldn't give me a result I wanted. So, dummy_powerdown only matches specific device IDs, and I've got a script to dump out the list of devices and their power states. I haven't actually measured any difference in power consumption, though. My kill-a-watt meter is really the wrong thing for this job -- it's on the AC side of things, and doesn't report fractional watts.

So, next step is to find a spare IBM power adapter and hack it up. That and get a bigger battery for next time I travel. I wish I'd remembered to get that two days ago.