I haven’t written much lately, which must have disappointed my thousands upon thousands of regular readers. For now I’ll neatly avoid the issue by linking to someone else’s content, with this rant about the OpenSSL library by Marco Peereboom.
My primary desktop machine has Intel’s G33 graphics chipset. It’s fairly low-end but it’s fine for my needs. For ages now I’ve been running on Xorg server 1.6.0,. Mesa 7.3rc2, and xf86-video-intel-2.6.3 and suffered only occasional X crashes, although I was certainly limited to run one X session at once (I used to like running two, essentially using it as an alternative to the desktop-switchers that are common now; it was something I could live with out, but it always bothered me that it didn’t work).
Just recently, a gcc 4.4.1 release candidate was tagged and so I decided to upgrade a few of these system components. Firstly, Xorg-sever 1.6.2, the latest stable release. I also updated my kernel to the latest 220.127.116.11. libdrm went to 2.4.12 (the latest). Mesa went to 7.4.4 (7.5 has been released as “stable” with a warning that “you might want to wait for 7.5.1, or stick with 7.4 series for now”). And, I built the xf86-video-intel driver version 2.8.0 (which supports only UXA style of acceleration, and “really likes” Kernel Mode Setting though is still meant to function without it).
Without KMS: Ok, but when I run a 3D app (Xscreensaver’s “antmaze”) I just get a blank screen. Running a second X server gives me a corrupted display and promptly crashes, forcing me to reboot via a remote log-in.
With KMS: Ok, but no 3D still. When I switch to a different VT I get an instant freeze, no chance to even start another X server (though I can still do a remote log-in).
Neither of these was really acceptable so I’ve gone back to the 2.7.1 xf86-video-intel driver. This driver supports the older “EXA” acceleration method, plus Intel’s own UXA method which they seem to think is the truth, the light, the way, but which has caused performance regressions and screen corruption in the past. (The even older “XAA” was ditched a while ago, I guess). I’m not even going to bother trying to use KMS again so I test between EXA and UXA:
With UXA: Despite the fact that Intel seem to think UXA is the way of the future, it gave me only problems. Specifically, running antmaze gave a window which flickered constantly between what antmaze should look like, and what appeared to be a copy of my desktop (resulting in one of those crazy infinite recursion effects). I managed to get a screen shot, below.
With EXA: Everything is Ok. Performance sucks a bit, but at least everything looks like it should and I don’t get crashes. Even better, it seems I am now able to run two X servers on the same machine and switch between them. I won’t be surprised if I still get the odd X crash, but that’s really just the status quo.
Frankly, it bothers me a lot that the 2.8.0 driver has seriously regressed from 2.7.1. For quite a while now it’s been touch-and-go with the intel drivers, I’ve seen quite a few serious problems in different releases.
Also, I’m totally unconvinced that UXA is the right solution for now. It may well have technical merits if done right but it really seems like it would be better to get EXA working properly – and fast – first, and worry about other improvements (like UXA) once the EXA driver is in a stable state, and is about as good performance-wise as it can be.
Hopefully now that EXA has been abandoned (even if it was too early) the focus on UXA will cause it to stabilise and improve.
Update 31/08/09: I’m now running Xorg server 1.6.3 and xf86-video-intel 2.8.1, which has been released since I originally wrote this blog entry. I’m pleased to say that the crashes (non-KMS) are fixed and I can run two Xservers side-by-side without problems. OpenGL was horribly slow and caused disk thrashing, until I also upgraded to Mesa 7.5. With KMS there are still problems; when I switch away from the X server to a text-mode terminal, no mode-change happens – I just keep seeing the X screen; if I switch back to it (CTRL+ALT+F7) I can continue working in X. Exiting X also fails to restore text mode.
Update 29/09/2009: xf86-video-intel 2.9.0 has the same problem as 2.8.1. Reported to the Xorg bug database. Let’s see what happens.
Update 1/10/2009: Ha, the old “not a bug” response. I thought about fighting this but didn’t want to devolve into a “open bug” / “close bug” ping-pong match; anyway, to summarise:
- Loading fbcon kind of solves the problem; I can switch away from the X session. However, it turns my text-mode virtual terminals into framebuffer VTs (which I don’t want).
- Technically it shouldn’t be impossible to have what I want – that is, to have KMS and still have text-mode terminals. But it’s probably a kernel-side issue rather than anything to do with the xf86-video-intel driver. (I may even look and see if I can fix it myself, at some point; I can’t explain why, I just really like text terminals).
- I personally think “NOTABUG” is the wrong resolution: there is a documentation bug. The fbcon requirement should be documented – either in the X driver man page, or the README that comes with the source bundle, or in the linux kernel documentation (the help text for the i915 driver). “NOTOURBUG” may have been appropriate.
- For now I’ll stick with non-KMS (can we call it “userspace mode-setting”? I like that). Although I’m worried that UMS will disappear from the driver at some point in the future, just like EXA and DRI1, murdered in the night.
Eclipse was the first “real” Java IDE I used and I’ve stuck with it for a while now. We migrated a project from CVS to Subversion a while back and, after a brief and highly unsuccessful fling with Subclipse (I’m sure it’s improved in the meantime, but I’ve never gotten around to trying it out again) I started using Subversive to provide Subversion support within Eclipse. Most of the basic things work but it has the following annoyances:
1. On my home machine, for some reason when I synchronize, it always asks for my username and password. Actually it doesn’t so much ask, seeing as the fields are already filled in and I just have to click “ok”, but it always presents the dialog.
2. On my work machine, on the other hand, it doesn’t do that. What it does instead is ask for the proxy password, despite the fact that I have entered the proxy password in the Eclipse preferences. Annoyingly, it asks for the password again from time to time as I do commits, synchronizes, whatever.
3. A whole lot of corner cases seem to be broken, especially with regards to tagging. For instance if I choose a folder under trunk and “New -> tag” (which incidentally is a really awkward menu choice, why can’t “tag” be one of the top-level options?) and then give it a new tag name, it creates the tag and puts the contents of the folder under the tag, but not the folder itself. If I create the folder under the tag first, and supply that combined tag name and folder name as the tag name (i.e. “TAG_NAME/folder_name”), it then DOES put the folder underneath the folder with the same name that I’ve already created (TAG_NAME/folder_name/folder_name)! WTF! To get it to work I have to create the tag without creating the folder and then specify “TAG_NAME/folder_name” as the tag. It’s borked.
4. Some tag operations don’t automatically refresh the tree in the SVN repository browsing view, even though they should. (I can’t remember exactly which ones, but I did spent a lot of time today creating and removing tags while trying to solve the problem in ).
5. What the hell is the “ROOT” folder? It just seems to contain a copy of the repository underneath it. What’s the point?
6. What does “Add revision link” (in the context menu on a folder in the SVN repository browsing view) actually do?
So when I try to build xorg-server-1.5.3, I get:
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus -I../hw/xfree86/common -I../hw/xfree86/dri -I../hw/xfree86/dri2 -I../mi -DHAVE_DIX_CONFIG_H -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/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/pixman-1 -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 -I/usr/X11R7/include -I/usr/X11R7/include -I/usr/include/drm -I/usr/X11R7/include/X11/dri -DXFree86Server -DGLX_USE_TLS -DPTHREADS -g -O2 -MT glxdriswrast.lo -MD -MP -MF .deps/glxdriswrast.Tpo -c -o glxdriswrast.lo glxdriswrast.c gcc -DHAVE_CONFIG_H -I. -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus -I../hw/xfree86/common -I../hw/xfree86/dri -I../hw/xfree86/dri2 -I../mi -DHAVE_DIX_CONFIG_H -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/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/pixman-1 -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 -I/usr/X11R7/include -I/usr/X11R7/include -I/usr/include/drm -I/usr/X11R7/include/X11/dri -DXFree86Server -DGLX_USE_TLS -DPTHREADS -g -O2 -MT glxdriswrast.lo -MD -MP -MF .deps/glxdriswrast.Tpo -c glxdriswrast.c -fPIC -DPIC -o .libs/glxdriswrast.o In file included from glxdriswrast.c:49: glxdricommon.h:32: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token glxdricommon.h:36: warning: type defaults to 'int' in declaration of '__DRIcoreExtension' glxdricommon.h:36: error: expected ';', ',' or ')' before '*' token glxdricommon.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'systemTimeExtension' glxdriswrast.c:67: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token
(and a bunch more).
It took me a while to figure this one out. There are conflicting “GL/internal/dri_interface.h” files – one comes from Mesa and the other one from the glproto package (version 1.4.9) which is part of the Xorg distribution. Deleting the latter (at /usr/X11R7/include/GL/internal/dri_interface.h) made the problem go away.
It is a bit strange, though; why does glproto include that header file if it’s not needed – if it is, in fact, problematic?
I get the following compiling dbus-1.2.10:
dbus-sysdeps-util-unix.c: In function '_dbus_init_system_log': dbus-sysdeps-util-unix.c:457: warning: implicit declaration of function 'openlog' dbus-sysdeps-util-unix.c:457: warning: nested extern declaration of 'openlog' dbus-sysdeps-util-unix.c:457: error: 'LOG_PID' undeclared (first use in this function) dbus-sysdeps-util-unix.c:457: error: (Each undeclared identifier is reported only once dbus-sysdeps-util-unix.c:457: error: for each function it appears in.) dbus-sysdeps-util-unix.c:457: error: 'LOG_DAEMON' undeclared (first use in this function)
(and so on).
The problem seems to be a missing “#include <syslog.h>” in the named file… if I add that in, it’s fine. How the how did this get missed? I mean, it DOESN”T COMPILE. How can you release a package which doesn’t compile?
I wonder if there’s something I’m missing, in particular, some situation (perhaps different ./configure options) which allow compilation without modifying the source.
Good ol’ ActiveRecord::Base has a bunch of “update” methods with arbitrary semantics in regards to object validation:
update(id, attributes) – performs validation
update_all(update, conditions, options) – doesn’t validate, and reverses the operand order (what attributes to change first, followed by the records to change as specified by “conditions”, rather than the other way around). Note also that despite its name it doesn’t (necessarily) update all records.
update_counters(id, counters) – doesn’t validate, reverts operand order
update_attribute(name, value) – doesn’t validate
update_attributes(attributes) – does validate
update_attributes!(attributes) – does validate
A bit of consistency wouldn’t have gone astray. The instance methods are particularly bad – by what rationale does update_attribute not validate while update_attributes does??
Check this out:
Can anyone, anywhere, tell me why “: order” would be needed if I am counting something? (Please note, space inserted so that wordpress doesn’t convert it into a smiley).
There are so many other holes and discrepancies in the Rails docs that I won’t try and list them, but this one takes the cake so far.