'Can you get cp to give a progress bar like wget?'

I'm glad to see that Sam 'When All Else Fails, Call 'Em Racists' Varghese has admitted that he's definitely not a part of the open source community. Which is good, because I'd be pretty upset if he was. (Though his claim to be a professional journalist is no doubt fairly upsetting and phenomenally insulting to actual journalists.)

'I give permission for IBM, its customers, partners, and minions, to use JSLint for evil.'

As ajax quite elegantly summed up, due to a series of catastrophic power failures at PSU, where fd.o is hosted, we were down for a good chunk of yesterday. Despite the machines having redundant power supplies, being connected to separate power rails in the rack, which were hooked up to independent, UPS-backed, power supplies, we still (like a good chunk of Portland, and certainly everyone in the PSU machine room) lost our power.

As far as we can tell, when annarchy.fd.o (websites, people.fd.o, cgit, anongit, et al) came back up, power was again interrupted while the ext3 journal was being replayed. When it came up the n'th time, fsck dumped almost the entire filesystem in lost+found, then started saying increasingly unhappy things about the state of the filesystem on its second pass. In the end, we just went with mkfs, and now we have a brand new and shiny filesystem.

It's worth pointing out that even if this was another filesystem, such as /srv, which hosts all project data, we would've been fine, as they're all backed up. But, unfortunately for some, we made a decision a while ago to not back /home up, and didn't advertise that as widely as we should have. So, if you had stuff in annarchy:/home, it's now gone, and I hope you have backups.

Sorry about that. On the upside, I got to see PSU's new and really very nice machine room this morning, thanks to XDC being about 250m away from the PSU machine room, and fd.o is otherwise running fine. We've been talking this week about replacing our ageing hardware, which would also allow for more redundancy as well as better performance from those machines. But we still have no plans to back up /home, so if you put stuff there, please, please keep your own backups (or make sure the Wayback Machine knows about it).

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

Today's the Day:

If Collabora has seemed quiet recently, it's because we've been slaving away on various parts of a really awesome project, which we can finally start talking about. Maemo 5 is coming! \o\ \o/ /o/

In other news, xserver 1.7 status update next week.

The Call for Papers for LCA 2010 is closing this Friday, the 24th of July. I can't speak for the rest of the committee, of course, but there seems to be a bit of a trend towards more left-field talks this year, which is great. Remember to get your talk in by Friday, and see you in January!

Boycott Novell seem to be the open source (inasmuch as anyone who's never contributed anything beyond a blog can be called part of the open source community) equivalent of people on the street shouting at the sky about the government.

(Waiting for my inbox to fill up with accusations of being a Microsoft and Novell shill and/or Lefty sockpuppet due to using 'open source' instead of 'free software'. Whatever.)

If you're bored to tears, you might want to read some gutter journalism, to the extent a four-page bullying of a college student (plus some bonus guilt by association) can be called 'journalism'. Pretty sad to see that this is apparently the standard of debate these days.

Off to GCDS to join the rest of the happy Collabora massive, hurrah. :)

Received in an SMS from a friend: 'I just walked past a bloke with pasty white skin and a ponytail wearing a t-shirt that said 'I do it with Ubuntu'.'

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.

Unfortunately, Matthew is correct, and it seems that Ryan Farmer is the idiot that signed a few of us up to about 200 mailing lists this morning. Not only do I trust Matthew's analysis (and was watching him go through the various steps on IRC as it happened), but then there were two other bits.

Ryan refused to approve two of my comments I made on his latest blog entry (more than happy to screenshot this). He claimed he too had been spammed, and had to abandon his email address of a few years. Even if you ignore the length of the text blanked out in the title bar not even remotely matching the length of his personal email address, there were only 131 messages in the inbox, of which 127 were unread, and no others but spam visible. He claimed they were archived; I offered to publicly apologise if he'd do a quick screencast showing him logging into that account and showing some messages from the archive to prove the point. Unfortunately he didn't bother approving these comments. (Incidentally, if you had to 'abandon' an email address due to an avalance of newsletters, et al, which took an hour or two to fully unsubscribe from, would you still bother blacking out the address everywhere?)

As per his standard 'insult everyone with random images from the internet and YouTube videos, then wildly claim conspiracies against him' policy, he went on to claim Matthew was conspiring against him, but given the choice between Matthew conspiring and severely irritating a few of his friends in the process, and some scorned 16-year old continuing his track record of acting like an irrational, immature idiot, I know which one I'd pick.

It takes some skill to be banned from all the Ubuntu IRC channels and the Ubuntu forums both, but I guess this morning showed that was completely justified. Apologies to everyone waiting on the announcement of sponsorship for XDS, as well as hotels, but unfortunately some people just can't conceive of having better things to do than acting like chavs. Hopefully IzanbardPrince/TheAlmightyCthulu/etc goes back to impersonating Kevin Carmony, flaming the bejesus out of companies using BIOSes which trip Linux bugs, and other, equally productive, uses of his time.

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

I agree pretty much with what ajax said, but Alberto's post struck me as pretty weird. Given that git's internal format has been unbelievably stable (indeed, far more stable than bzr: a few times, I've just given up trying to get code because doing so would require me to compile a new bzr -- barrier to entry like what), I don't see what's stopping anyone from developing alternate git clients that are all Windows-friendly (or OS X-friendly, or Eclipse-friendly, or whatever).

A quick FAQ: the reason all DSA keys have been removed from fd.o and we aren't accepting any new ones is that they are vulnerable to man-in-the-middle attacks if they have ever been used (not just generated) on a system with a predictable RNG: see Steinar's summary of the maths. We're going with precedent of debian.org rejecting DSA keys, and a general desire to be safe rather than sorry. RSA keys are the default in OpenSSH anyway, so I'm not really sure why you'd want to generate DSA.

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

Every time I see a post about changelogs (sorry Behdad, nothing personal), I die a little bit inside.

There are three problems here:

• In any merge, you always collide horribly on the ChangeLog, and it just makes working with more than one person and/or branch nigh on impossible, so you lose all the benefits of an RCS that actually supports merging.
• git gives you a system with very lightweight microcommits: in your local tree, you can easily amend, rebase, modify, and walk back, before you push. So, instead of queuing up ten million things such that you need a complicated changelog, do lots of little, relatively self-explanatory commits.
• Even when you have complicated commits that require explanation (e.g.), just make the commit log sufficiently verbose, so that git blame, gitweb, and any other tool, can offer people the full context, rather than making them dive into an unrelated file and remember the exact date, etc. In X, we just generate ChangeLog from git log, and we're really happy with that so far.

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.

6124 daniels 15 0 2109m 1.5g 18m R 1 75.4 426:30.01 firefox-bin
3000000 1486 74 1 5808 962 1427069K 60K 1427129K 6124 Django | Model reference | Django Documentation - Mozilla

I honestly don't understand how Firefox could consume 1.5GB of RAM, as well as 1.4GB of pixmap storage in the X server. This is a new record. (And the pixmap storage rose to 1.7GB before I killed it.)

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!

I'd always had the ludicrously useful Google Search Keys extension installed, but now Google's Beta Search Keys complement this incredibly well (complete with vi mode!). Can't imagine life without the extension, let alone without the new Google one ...

(Via Adam Rosi-Kessel.)

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.

The linux.conf.au 2008 Call for PapersPresentations is now open. We're accepting submissions from now until July 20th, 2007; you'll be notified in early September of the paper committee's decision.

Go check out the announcement, and start thinking of cool talk ideas. Once you've got to that stage, be sure to read mbp's How to get a conference abstract accepted, and Mary's Getting a talk into linux.conf.au (not just because she's a co-chair of the paper committee).

This year, we've introduced one optional step: a video submission. If you think that you're a great speaker, and if only we could see you, we'd say yes instantly, then grab a camera, and convince us. :)

Also, if you're interested in running a mini-conf before the main conference, we're also taking proposals for mini-confs.

See you in Melbourne!

It's just not our week, I guess. For the past couple of days, gabe.freedesktop.org (www.fd.o, ns1.fd.o, lists.fd.o) has been playing up: it will just mysteriously die with no explanation. It appears to still be alive, but we can't access it at all. Bringing it back up yields nothing suspicious before it dies, so we're suspecting some bad hardware. This wouldn't be too major a problem, bar the loss of the above-named services and dri.fd.o, openclipart.org, and a few other services, if it weren't for other things conspiring against us.

All revision control services (git/CVS/SVN committing and checkout, web access to same), Bugzilla, xorg.fd.o, people.fd.o and planet.fd.o, are on separate machines which are unaffected by this failure. But, unfortunately, we got less than 24 hours notice that our secondary DNS server at MIT was being moved, and would be offline for a while. Two DNS servers gone. Our third DNS server, hosted in the UK, is still servicing requests just fine, but apparently our registrar never noticed the update. So the third DNS server according to the glue records is home.keithp.com, which is also off the air right now for some reason.

So, ns0.bluelinux.co.uk is still serving names, and you can still access some services if you use that, but we're not sure how long until normal DNS is back up, let alone how long it will take us to get gabe fully fixed.

Sorry for the outage, please bear with us. If you think it's frustrating not being able to check www.fd.o, try checking the remote console and watching /proc/meminfo hopelessly spew into the serial console as you are unable to log in ...

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!

(Please note, I didn't write this: I just fixed a couple of bugs and put it in a patch. All credit to the original author, Tommie Gannert.)

Tired of the sucktitude of automake command lines? Find it incredible that people could seriously claim to prefer command output so verbose that you actually miss all the warnings?

if /bin/bash ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../GL/mesa/swrast -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I/home/daniels/x/mesa/Mesa/include -I../X -I../array_cache -I../glapi -I../main -I../math -I../shader -I../shader/slang -I../shader/slang -I../swrast -I../swrast_setup -I../tnl -I.. -I../../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -DXFree86Server -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../../../include -I../../../include -I../../../../Xext -I../../../../composite -I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi -I../../../../miext/shadow -I../../../../miext/damage -I../../../../render -I../../../../randr -I../../../../fb -g -O2 -MT s_masking.lo -MD -MP -MF ".deps/s_masking.Tpo" -c -o s_masking.lo s_masking.c; \
then mv -f ".deps/s_masking.Tpo" ".deps/s_masking.Plo"; else rm -f ".deps/s_masking.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I../../../../GL/mesa/swrast -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I/home/daniels/x/mesa/Mesa/include -I../X -I../array_cache -I../glapi -I../main -I../math -I../shader -I../shader/slang -I../shader/slang -I../swrast -I../swrast_setup -I../tnl -I.. -I../../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -DXFree86Server -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../../../include -I../../../include -I../../../../Xext -I../../../../composite -I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi -I../../../../miext/shadow -I../../../../miext/damage -I../../../../render -I../../../../randr -I../../../../fb -g -O2 -MT s_masking.lo -MD -MP -MF .deps/s_masking.Tpo -c s_masking.c -fPIC -DPIC -o .libs/s_masking.o

Prettify Automake finally fixes this. I've put up a deb that at least works on Edgy (but has some pretty shady changes; getting it to build was, um, interesting) here; re-autoreconf with that, then run configure with --enable-pretty-cmds to get much more sensible output:

  [C ] fbbits.c
  [C ] fbblt.c
  [C ] fbbltone.c
../../fb/fbbltone.c: In function "fbBltOne":
../../fb/fbbltone.c:354: warning: left-hand operand of comma expression has no effect
  [C ] fbbstore.c

Warnings! Visible! Amazing!

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.