Main :: Activity Log :: June 2009
Go forward in time to July 2009.
Erik Naggum is dead. Xach posted an excellent compilation of Erik's best moments.
We now have some ultra-simple documentation on the policies which GNOME uses to handle the RANDR extension. What happens when I hit Fn-F7 to switch displays? What happens when I plug in a monitor? How does GNOME manage to remember your RANDR configurations?
I have been toying with the idea of holding a really informal BoF during GCDS for the hippie treehuggers among us. It would be a mish-mash discussion of peak oil, urbanism, architecture, gardening, permaculture, urban agriculture, and all that. What do you think? Mail me to see if we would have a suitably-sized group. Think informal, as in people sitting on the beach talking about how to make their compost heap work, not a session in an air-conditioned auditorium.
I've been giving some love to the GTK+ file chooser.
Actually, that's not quite accurate. People have been sending lovely patches, so I've been getting off my ass to review those patches.
In other news, I'm making Sabayon use Xephyr instead of Xnest for its child session window. Currently a bunch of apps crash under Sabayon because they don't handle the missing X extensions that Xnest lacks.
Fedora has a patch which simply does s/Xnest/Xephyr. That makes Sabayon work quite well, but for some reason you cannot type anything at all in the session window. Xephyr is not even getting keyboard events. Sabayon has some esoteric code to deal with focus switching and to send keyboard events to the child session... I'm trying to see why that doesn't work with Xephyr, but it works fine with Xnest.
No more Board for me
I just sent the following mail to the opensuse-project mailing list:
As you know, I have been part of the openSUSE Board for a few months now, thanks to your kind election. However, work and other duties have kept me too busy to be a useful part of the Board.
I would like to step back from my duties in the Board, and cede my post to Stephen Shaw (known as decriptor on IRC). Stephen has been very active in the openSUSE community, and I am sure that he will be a much better Board member than myself.
However, this does not mean that I will stop working on openSUSE! I am part of the openSUSE-GNOME team, and will keep working happily on the technical side of things there.
Please welcome Stephen as the new Board member, and thanks for all.
RANDR and suspending laptops
Consider this scenario:
Until yesterday, you ended up with a black screen, as nothing ever detected that you had unplugged the only active monitor. Fixing this was a bit fun.
First, the X server needed to re-probe the video outputs when the laptop comes back from suspend. X then sees if the monitors have changed. If so, it sends out the corresponding RANDR events to clients.
On the GNOME side, gnome-settings-daemon is responsible for handling RANDR events. X just says, "the monitors changed; now do something about that". Gnome-settings-daemon sees if it needs to enable certain video outputs if they got connected, or disable the ones that got disconnected. In the end all of gnome-desktop, gnome-settings-daemon, and gnome-control-center needed changes for this. The randr-hotplug branches for those modules are now merged into master.
Like many things in X, the RANDR machinery maintains a few timestamps that it uses to avoid race conditions. An X client is not allowed to change the RANDR configuration if its view of the world is out of date — for example, if monitors have been plugged or unplugged since the last time that the X client queried the state of the monitors.
Also, you can use those timestamps to distinguish between RANDR events that get generated when *you* change the RANDR configuration, from those that happen due to the user plugging/unplugging things. Gnome-settings-daemon uses the RANDR timestamps for that purpose.
It turns out that X was maintaining the RANDR timestamps incorrectly. Keith kindly fixed this.
Little bugs have been surfacing from all of this. The Intel video driver didn't detect VGA outputs correctly. XRRSelectInput() doesn't work as advertised. RANDR notifications are probably broken for X clients with byte ordering different from the server's.
The most important part of this is that gnome-settings-daemon now absolutely requires an X server with the fixes for the RANDR timestamps. Unfortunately, I don't know of a way at runtime to detect whether this is the case. If you have a buggy X server, you'll get lots of RANDR weirdness.
On the good side, all of this also means that GNOME is ready to receive hotplug events from X whenever that is actually made to work. In the ideal case, you should not need to tell your machine that a monitor got plugged or unplugged; it will just detect it and do the right thing.
Git tip of the day: Sandy asked how to cherry-pick a range of commits, instead of cherry-picking them one by one. Assuming FROM and TO are the first and last commits in that range, and mybranch is where you want to apply those commits, you can do this:
git format-patch -n --stdout FROM^..TO > /tmp/patchety-patch git checkout mybranch git am /tmp/patchety-patch
"FROM^" means "the parent commit of FROM", as git format-patch takes a range of commits in the same way as git diff.
"git am" means "apply mailbox" --- it takes an mbox file with patches, which you just generated from the format-patch command, and applies the patches in sequence as individual commits.
By the way, "git format-patch" is my new favorite way of generating patches for inclusion in RPMS. This way you can preserve patches with history, instead of having everything collapsed together into a single big blob of a patch.
Go backward in time to May 2009.
Federico Mena-Quintero <federico@gnome.org> Thu 2009/Jun/04 22:40:22 CDT