X.Org 7.5 will be releasing fairly soon -- within the month. Check the updated schedule for more details.

I don't use Emacs myself, and I don't recall a single Emacs user complaining about accidentally triggering Ctrl-Alt-Backspace on their way to M-C-E-A-S paste-output-of-doctor-into-irc. Most of the grumbling came from actual users (i.e. people who don't know what an X server is, let alone how to configure it, let alone to email xorg-devel@ about it), rather than people who are perfectly capable of changing the default[0].

Regardless, Peter came up with a perfectly sane plan which makes it very easy indeed to optimise for clients with stuck grabs (being that termination requires you to be processing input events in the first place, in which case you're likely doing reasonably well anyway).

[0]: Yes, the text is woeful. Sorry.

Dom: Yeah, we used PayPal to accept payments for accommodation for the 2008 X Developers' Summit, but a combination of staggering US bank incompetence and PayPal being, well, PayPal, means that we lost about $US4500 we'll almost certainly never see again. The whole thing was a nightmare. After that, I switched to Google Checkout and didn't have a single problem, aside from it wanting to give me the whole interface in Finnish for a while and not offering a choice.

This is a public service announcement: depth and bpp are different.

Depth refers to the number of significant bits (usually colour-significant, i.e. R + G + B bits for RGB modes) per pixel. bpp, i.e. bits per pixel, refers to the number of bits used altogether for pixel storage. Ignoring alpha, the usual configuration of your framebuffer will be depth 24 (8 bits each for R, G and B), but 32bpp: 8 unused bits at the top. 24bpp and depth 24 means that there are no unused bits, and that four pixels will occupy 96 bits (12 bytes), and not 128 bits (16 bytes), as there would be in 32bpp. (Thankfully, no-one actually uses 24bpp in the real world.) That is all.

Sorry for the hideously late announcement, but an extraordinary comedy of errors involving quite a long chain of people and a series of unfortunately timed holidays meant we couldn't confirm this until now.

Anyway, the 2008 X Developers' Summit will be held from Sep 3rd-5th at Edinburgh Zoo (nearest airport EDI, or overnight sleeper train from London). More details and links to come later today. See you there!

Make of them what you will.

daniels@psyence:~/x/xorg/xserver% wc -l **/*.[ch] | tail -1
  730420 total
daniels@psyence:~/x/xorg/xserver% git diff -p xorg-server-0_99_1.. | diffstat | tail -1
 2747 files changed, 178062 insertions(+), 628051 deletions(-)
daniels@psyence:~/x/xorg/xserver% echo $((628051-178062))
449989

If you're attending the excellent FOSDEM (which you should), you should make sure you get down to my talk on input. We're now at the stage where we understand not only the problems, but their causes and fixes, and the code which led us there, and I think by early 2009[0] we should be in really good shape. Finally.

I felt a bit bad posting a blog entry just about myself, but then I thought hey, at least I'm not putting a picture of myself in here.
[0]: Peter has a thesis to write, I have work to do and another move to make, et al.

The X Developers' Conference 2008 will be held at the Googleplex in Mountain View, California from April 16th-18th, 2008. If you're interested in coming, please sign up at the wiki; we're also interested in having people talk if they want to. More details as they come to hand, but start booking your flights now.

After my shameless beg, a number of people emailed me (thanks -- sorry about the lack of comments) to tell me that I should really be using awesome, and I am. (Other popular suggestions were wmii and dwm.) I'm well happy with it so far, so thanks!

Dear lazyweb,
I want to try out a window manager like Ion, but I don't want to actually use Ion due to the fact the author's an irritating nutcase who I'd rather not encourage any further, and its utterly daft license. What's a man to do?

Following on from AMD's announcement at XDS 2007, Intel have just released documentation on their graphics hardware, without NDA, available to the public. There's also a mirror at X.Org. Cheers, Intel!

< eikke> is there any "small" thing which I could be able to do, now?
< eikke> if possible wihtout breaking my hardware as there's no major company behind my back :p
< marcheu> eikke: the most likely way your hardware breaks when doing driver stuff is because you throw it out of the window

Matthew Tippett just threw a CD full of AMD/ATI specs to Dave Airlie, approved for public release with no NDA. I'm now holding one of those CDs as well. Thanks, AMD.

In the past five hours, we've pushed 72,000 PDFs, for a total of around 1TB. This ... turns out to actually push the limits of our new fd.o setup.

I'm sitting here at XDS, and John Bridgman and Matthew Tippett are announcing AMD's open source plans. In three words: 'specifications without NDA'. 2D very soon, 3D coming when the legal issues have been taken care of. Specs for the r3xx core will probably be coming later on down the track.

I don't need to say how awesome this is.

Just under a week after XDS was announced, we've already got 38 (out of 40!) attendees registered. 40 is our current cap, and we need to change it soon if we're going to break that number, so please, ensure you're registered if you're planning to come. If there's too many people, registering now won't bump other people off, it'll just mean that we know we can increase the size a bit. :)

Our accommodation is in 'single sets': a study with adjoining bedroom (single bed), and en suite (so, your own shower and toilet). For the moment, registration is everyone who's signed up on the attendees page, and hasn't told us that they're not staying in the college. Please do not contact Clare College and book the rooms yourself: we have a big group booking.

Wireless will be available in the main conference room, as well as in the bedrooms, and a common area.

So: if you're thinking of coming, register!

Update: We're now at 38 people, not 25. Two spots left.

After a bit of a delay in the announcement, I'm proud to finally unveil the X Developers' Summit 2007. September 10th-12th, at Clare College in wonderful Cambridge, UK (not the one near Boston). We'll be running a sponsorship program too, so X developers, even if you don't think you can make it, just keep those days free.

More information on the wiki page. See you in Cambridge!

Just a quick note to say a huge thanks to everyone who's offered support (financial, hardware-wise, or just verbal) to the r5xx project -- we really appreciate it. A couple of FAQs:

Thanks! Where can I send money?

Sadly, money isn't the issue: we have jobs/university theses/lives to tend to. We just lack for time right now.

Thanks! Where can I send hardware?

If you have a card that you won't be needing back (we may lose or fry it), please email myself (daniel@fooishbar.org) and Jérôme (j.glisse@gmail.com), detailing what you have, and we'll get back to you if it'll be useful to us.

Will this work with the X2xxx cards (r6xx)?

Yeah, pretty much. It just needs someone to hack up the small amount of code to deal with it.

What's happening with X1650 and above (r530/r580)?

Most of the code is written, however, initialisation doesn't happen correctly for some reason.

What's happening with 3D support?

It should be relatively simple to implement from the existing driver, as the engine is believed to be extremely similar, but we want to get the basics working before we start attacking things like this.

Which tools do you guys use?

For tracing the video BIOS, we use a hacked version of xresprobe: vbetool will instrument the BIOS quite well. For tracing fglrx, we use a hacked version of valgrind: run it against the X server, making sure that it is not suid root. For getting impatient and playing with registers, we use avivotool.

Where does the development happen?

On IRC, #dri-devel seems to serve somewhat as the ATI development centre. This gets fairly well coalesced into The Irregular Radeon Development Companion, however, so you may prefer to just follow that.

Shouldn't all this be on a wiki page somewhere?

Yes, but I have to get up in less than four hours.

Once again, thanks for the support, from all of us. It's been great.

As Jérôme announced, the Avivo driver for newer ATI chips is now available. Unfortunately we've all been very busy, so it's taken literally months longer than we'd hoped. But we have a driver that, while having no acceleration, is able to set modes on VGA, DVI, and laptop panels: all it really lacks is TV out support, and support for the complete set of models. Pretty cool stuff. Any help we can get is appreciated, so if you've done X or driver development, or are interested in same, please get in touch via xorg@lists.freedesktop.org. It's completely FLOSS, licensed under the GPL.

Part of the reason I've been so busy is trying to arrange the X Developers' Summit in Cambridge, UK, around the 10th of September. But more on that later.

Have been feeling rather unwell for the past couple of days, so I decided, while I feel like death warmed up, how could hacking at Valgrind possibly make it worse?

I took Tilman Sauerbeck's extended version of Dave Airlie's valgrind-mmt, and cleaned up a couple of minor bits -- changed the offset to be specified in hex, added support for repetitions (e.g. 'repeated 255 times', instead of the same line 256 times over), and also added support for the in*/out* family on AMD64, which was quite entertaining as I've not really touched either assembly or Valgrind before. Got it working in the end, despite libVEX's best efforts to frustrate me, and ended up feeling slightly better as well. Huzzah.

Anyway, 'sudo valgrind --tool=mmt --offset=0xc1000000[0] /usr/bin/Xorg :0 -ac > x.log 2>&1' will trap all MMIO accesses made by X or its VBIOS, provided you run the BIOS through x86emu instead of lrmi.

Postscript: spent a few minutes after writing this trying to figure out if there was anything I should've said, and didn't. Now, hours later, I realise there was one minor detail omitted: the URL. gitweb is just there, and the anonymous clone URL is git://people.freedesktop.org/~daniels/valgrind.

[0]: Get the base address with lspci -v. Your video card should have two PCI regions, of which one is big (your main video memory), and the other one is 32 or 64kB (the MMIO space, i.e. the bit you want).

Just a quick reminder: if you were planning on going to the X.Org Developers' Conference in the Bay Area, from the 7th-9th of February, then please make sure you've registered on the page. If you weren't planning to come and you work on X or related fields of endeavour (toolkits, desktops, maybe you're an IHV), then you should consider coming along as well. There'll be a mix of scheduled talks, random freestyle hacking, corridor schmoozing, dinners, after-dinner fun, and a whole world more.

If you'd like to come but your pockets don't go quite that deep, please consider applying for sponsorship. The Foundation is willing to pay for travel and accommodation to developers who couldn't otherwise attend.

Hope to see you in sunny(ish) California!

So, I finally merged the input-hotplug branches on master. Basically, this means that instead of attempting to hide behind one device (/dev/input/mice, the console keyboard), and hacking around it with gash and tape when we actually expose multiple devices[0], we finally expose multiple devices in a useful way. This is consistent through out the Xorg and KDrive servers; Xnest and Xvfb also have support, but that's not the most useful thing ever.

This required a huge overhaul of the old input code, much of which dates back to the mid-80s; the bits that don't were sticky-taped on the side, working more in spite of our core input code than with it. So, in addition to being generally useful and providing things like multiple keymaps on different keyboards and different acceleration (and so) on different pointer devices, it also actually caused a net removal of code.

So, once you've set yourself using evdev for the drivers, you can also now dynamically add and remove devices. Last night, not long before I released all the components, I removed all the input devices from my configuration file, told X not to add any, and added 'respeclaration --daemon' to my session: completely dynamic input. I've been using the core bits (the whole input API rework) for quite a long time, along with Zepheniah's evdev driver, but this is the first time I've been using a session with completely hotplugged input, as opposed to adding and removing devices every now and then to test the hotplug capabilities, which was actually a piece of cake, compared to reworking all our core input code to deal with devices appearing and disappearing.

Still, this all needs good desktop integration. Keyboard and mouse applets need to become aware of multiple devices[1], and allow people to configure them separately. The desktop should also take over the role currently filled by respeclaration, which works perfectly well, but shouldn't be generally deployed; management of input devices thus turns into a session management issue, which leaves the desktop to dictate policy.

There are still some nits in the D-BUS policy to sort out (right now, only root can reconfigure the devices), but I believe it's fundamentally the right model: it's machine-oriented, rather than session-oriented. There are still some minor changes that need to be made, but working out who should be trusted to add input devices was more or less impossible in the X security model.

xserver 1.3 (for Xorg 7.3) should be good fun.

[0]: Key presses/releases from your second device will just magically appear from your first device. Useful, huh?
[1]: In brief: check for inputproto 1.4 at build time, check DEVICE_CORE on whatever appears as the core pointer, and if 'iscore' is 1, then you have a virtual core pointer. Anything that sets status to 1 for DEVICE_CORE will also generate core events. Setting controls on the core keyboard or pointer will propagate those changes down to all the devices which also send core events. I'm going to document this soon.

Daniel, if you can somehow build a card that's at r2xx level (note the current state of the art is r5xx), not to mention be register-compatible, you are nothing short of a genius, and ATI and NVIDIA will be begging you to let them pay you a number of your choice.

It's not going to happen anytime soon. They're not worried about that.

So, thanks to the effort of our fearless team, new Xorg hotness is available, and even brings those blue sparks. You might note that this is a mere five months after X11R7.0, and note the 7.2 release plans, which have us releasing X11R7.2 in a mere six months. We're back. Oh yes, we are back.

Everyone on #xorg-devel has seen me harassing people about our current stats with bugs. If anyone with knowledge of the X codebase felt like coming in and doing a bunch of really painful, unrewarding, triage work, it'd be massively appreciated. That NEW line should really continue plummeting down! On that note, I'd like to publicly big up Erik Andren in particular, for doing a ton of awesome triage work so far to help us get that graph down, and help beat our Bugzilla into something usable that helps us, rather than its current awfulness.

Joe muses about Xlib and connection aborts. Two things:

Yes, libX11 is going away. It's unfixably broken (not only is the implementation utterly horrendous, but the concept is exactly what toolkits don't want), and we can't change existing behaviours because libX11 is just one of those API/ABIs you cannot break.

Yes, the ability to recover from connection aborts is essential. D-BUS is broken in the exact same way, yet some people feel inclined to defend it (e.g. mandating reboots when either of the D-BUS daemon, or libdbus, are upgraded; advocating segfaults in client applications when the bus dies as the right thing to do?!?). I don't think either behaviour is in the least bit sensible, and it would be really keen if both could be fixed (by using XCB in toolkits for the former, by fixing libdbus to be less obnoxious for the latter).

Let the shiny begin.

Since all the cool kids are doing it:
daniels@ephemera:~/x/xorg/xserver% diff -urN xorg{,.xkb}/xkb | diffstat | tail -1
 27 files changed, 1437 insertions(+), 7439 deletions(-)

Hacking on XKB as recreation. Whoohoo.

(Oh yeah, and that removal of 6000 lines of code actually adds some really cool new features to the server, including some which make it significantly more complex -- XML parsing, i18n, you name it. How's that?)

PERHAPS BONG HITS WILL FIX MY KEYBOARD EXTENSION

A big word up to X11R7 being released. The benefits of modularisation are pretty well-documented: distributors can do security updates much more easily, as well as keep better track of upstream sources, users can build drivers easily if need be (and the drivers can get released promptly upon releases of new cards), etc, etc. But for me, the biggest win is that it's finally over: I've been working on it since Jan 2004, and the xlibs and xserver projects basically began in October 2003. I'm really glad that the release didn't, as suggested, get dragged into 2006.

People who deserve a great deal of thanks for this release include, but are absolutely not limited to, Kevin E. Martin, Adam Jackson and Alan Coopersmith as the release cabal, Søren Sandmann Pedersen as a modular partner in crime, Keith Packard and Jim Gettys who basically got modularisation moving, LinuxFund for funding Xizzle and Debrix (the genesis of the modularised X server), Jakub Stachowski and Kristian Høgsberg for work on Debrix when I got busy with other commitments (and krh for ongoing modularisation work). I'm sure there are others who I've forgotten here; if you feel you should be on this list, then sorry. The code contributions are too many to mention: Eric Anholt, Ben Herrenschmidt, Billy Biggs, Alan Hourihane, Zack Rusin, Dave Airlie, Aaron Platner, and a cast of thousands.

I've heard the other release parties are rocking along nicely; I plan to make Melbourne's pretty damn good. Cheers!

Dear Norbert,
glxgears is not a benchmark.
Love,
Daniel

The X.Org security list has a web form, linked off www.x.org, to submit security concerns. Predictably, it gets a lot of spam and weird stuff. However, I'm utterly at a loss to explain this one:

Date: Wed, 2 Nov 2005 10:12:04 GMT
Message-Id: <200511021012.KAA11645@xoneweb.opengroup.org>
To: xorg_security@x.org
From: Dave Custard <davecustard@custardcreams.com>
Subject: X.Org SECURITY CONCERN: Custard Creams

My concern is that the custard creams are going to escape and
kill us all with their sweet custardy filling. I'm scared.

(form_Security)

Michael says X needs stronger, hostname-independent, authentication.

xhost +SI:localuser:foo:

daniels@ephemera:~% xhost +SI:localuser:nobody
localuser:nobody being added to access control list
daniels@ephemera:~% sudo -u nobody xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: The X.Org Foundation
[...]

This was all part of the ServerInterpreted auth scheme, which I think Sun did the work on. So you're free to concoct arbitrary schemes involving SELinux, and just implement them in the server you're intersted in.

At the European X Developers' Conference last Sunday/Monday, I gave a talk on the modularisation effort; click through to slides if you're interested. The server now loads, runs, and works, and I'm committing it to CVS as soon as I can shepherd it through make distcheck. It does, of course, still have some rough edges, though.

Imitation is the best form of flattery. It's just a shame for the people who paid $us80 that it's much older (and much buggier) than the version in Hoary.

Or, you could go over to Linspire Five-O! and grab a fork of xorg_6.8.1-0.3, which was made back in early November 2004 (as opposed to Libranet's effort of February 2005). There have been a few tweaks and fixes (entirely imported from Red Hat and SuSE, which Ubuntu have already picked up, if they work), but really not much value add.

wtf dri

Erich Schubert asserts that X.Org is not ready for Sarge. Firstly, it was never proposed for Sarge (monolithic or modular), so that's kind of a moot point.

Secondly, he points to a bug opened today on Radeon, and declares that it is undoubtedly only one of a massive number of problems waiting under the surface. This bug only affected one very specific class of chips (rv100/rv200, aka Radeon 7000/7200; not r100 or r200, which are the same class), it was opened today with a patch from Dave Airlie, and as I read that blog entry, I had a test X.Org build running around my machine with that patch already included, as I'd seen the leadup to that bug on IRC, and had an X.Org upload planned anyway. So, I doubt a problem that only affected an infinitesmal percentage of users (Radeon 7500s are far more popular than 7000s in that class, and I'm not entirely convinced anyone actually owns a 7200), that was resolved as soon as it conclusively came up, can be a pointer to anything.

In fact, I think you will find the amount of hardware support in X.Org (out of the largest three vendors, all have new chipsets supported in X.Org that aren't supported in XFree86 4.3 -- ATI's r4xx series[0], nVidia's GeForce6 series of chips[1], and Intel's i9xx series[2], are totally unsupported) is so vastly improved that, even if the 'everything is broken and no-one noticed until now' allegation is true, the staggering weight of hardware supported under X.Org but not under XFree86 would be enough to counter this. Also, with Ubuntu, Fedora Core, Mandrake, SuSE, FreeBSD, Gentoo, and everyone else on the planet using X.Org at this stage, I think if it had massive problems, then it would be *very* well-documented.

I don't think extrapolating from one specific (and very quickly-fixed) problem to all of X.Org being totally unusable is valid, or fair.

PS: Ubuntu.
PPS: r100 is Radeon 7500, rv100 is Radeon 7000, and rv200 is Radeon 7200; neither of the latter two are very widely-used at all.

[0]: Not to mention massively improved display detection for every other chipset.
[1]: I believe Debian's XFree86 packages have some of this support backported, but not all.
[2]: And for i8xx chipsets also, widescreen/non-standard displays are detected and set up just fine without needing to use 855patch, 865resolution, or any of that class of monumental hacks.

Last night, a humble pub in Sydney (the James Squire Brewhouse, Darling Harbour) hosted the release of not one, not two, but three major components of a free desktop. GNOME 2.8, Ubuntu 4.10 (aka Warty), and X11R6.8.1 all got released, and all but the last throes of the Ubuntu release (it was closed by the time that was released) was done from the JSBH.

X11R6.8.1 initially went very smoothly, but then had some hitches, which involved the tarballs being removed with an allegation that some patches still needed to be applied (they didn't), and a duplicate announcement being sent. As a result of this, ftp.x.org isn't actually carrying 6.8.1 yet; the master source is on fd.o. But, to be absolutely clear, it is released for sure, and it is a security release, so you are advised to upgrade ASAP.

On to happier matters, Ubuntu was released yesterday, and I couldn't help but feel immensely proud of it -- like a doting parent. It's amazing how far it's come even from just a few weeks ago, and hopefully continues to rock as much.

XKB has an internal (I think) type called 'dooads'. This scares me.

So, I was doing some hacking on fd.o's X (importing some apps, strong deps), when it occurred to me that no-one hacks on it because it doesn't even bootstrap. So, a few hours, two run-outs of disk space, several bootstrap attempts, numerous tarballs, and a fair few revisions later, X is now bootstrapping fine. Starting from scratch on a machine that had never seen X libraries, I ran through xlibs and xserver-xorg, and it all worked.

So, if you want to hack on Xorg's modular stuff, use xlibs from CVS (the usual place), and grab my latest xserver-xorg tarball. Sorry for all the false starts, but latest xlibs plus that tarball is a goer.

Keith Packard, please seek professional help.

#!/bin/sh
for i in "$@"; do
        if grep -q '<config.h>' $i; then
                echo $i already has config.h
        else
                chmod +w $i
                ed $i << EOF
/^#/
i
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
.
w
q
EOF
        fi
done