Intel Xorg drivers in a state of chaos?

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 2.6.30.2. 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).

Results:

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.

Screen capture when using xf86-video-intel 2.7.1 with UXA acceleration
Screen capture when using xf86-video-intel 2.7.1 with UXA acceleration

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:

  1. 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).
  2. 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).
  3. 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.
  4. 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.
Advertisements

10 thoughts on “Intel Xorg drivers in a state of chaos?

    • Why the hell would I want to do that? You’re missing the point. I’m running “stable” versions of all the software, including Mesa. Things should work. With the older version of the intel driver, they do work. The newer intel driver breaks things. Did you even read the blog post?

  1. Newbie can you help? HP NC6220 I915GM 1G ram

    xf86-video-intel-2.8.1 ./configure

    checking for a BSD-compatible install… /usr/bin/install -c
    checking whether build environment is sane… yes
    checking for a thread-safe mkdir -p… /bin/mkdir -p
    checking for gawk… gawk
    checking whether make sets $(MAKE)… yes
    checking whether to enable maintainer-specific portions of Makefiles… no
    checking build system type… i686-pc-linux-gnu
    checking host system type… i686-pc-linux-gnu
    checking for style of include used by make… GNU
    checking for gcc… gcc
    checking for C compiler default output file name… a.out
    checking whether the C compiler works… yes
    checking whether we are cross compiling… no
    checking for suffix of executables…
    checking for suffix of object files… o
    checking whether we are using the GNU C compiler… yes
    checking whether gcc accepts -g… yes
    checking for gcc option to accept ISO C89… none needed
    checking dependency style of gcc… gcc3
    checking for a sed that does not truncate output… /bin/sed
    checking for grep that handles long lines and -e… /bin/grep
    checking for egrep… /bin/grep -E
    checking for fgrep… /bin/grep -F
    checking for ld used by gcc… /usr/bin/ld
    checking if the linker (/usr/bin/ld) is GNU ld… yes
    checking for BSD- or MS-compatible name lister (nm)… /usr/bin/nm -B
    checking the name lister (/usr/bin/nm -B) interface… BSD nm
    checking whether ln -s works… yes
    checking the maximum length of command line arguments… 1966080
    checking whether the shell understands some XSI constructs… yes
    checking whether the shell understands “+=”… yes
    checking for /usr/bin/ld option to reload object files… -r
    checking for objdump… objdump
    checking how to recognize dependent libraries… pass_all
    checking for ar… ar
    checking for strip… strip
    checking for ranlib… ranlib
    checking command to parse /usr/bin/nm -B output from gcc object… ok
    checking how to run the C preprocessor… gcc -E
    checking for ANSI C header files… yes
    checking for sys/types.h… yes
    checking for sys/stat.h… yes
    checking for stdlib.h… yes
    checking for string.h… yes
    checking for memory.h… yes
    checking for strings.h… yes
    checking for inttypes.h… yes
    checking for stdint.h… yes
    checking for unistd.h… yes
    checking for dlfcn.h… yes
    checking for objdir… .libs
    checking if gcc supports -fno-rtti -fno-exceptions… no
    checking for gcc option to produce PIC… -fPIC -DPIC
    checking if gcc PIC flag -fPIC -DPIC works… yes
    checking if gcc static flag -static works… no
    checking if gcc supports -c -o file.o… yes
    checking if gcc supports -c -o file.o… (cached) yes
    checking whether the gcc linker (/usr/bin/ld) supports shared libraries… yes
    checking whether -lc should be explicitly linked in… no
    checking dynamic linker characteristics… GNU/Linux ld.so
    checking how to hardcode library paths into programs… immediate
    checking whether stripping libraries is possible… yes
    checking if libtool supports shared libraries… yes
    checking whether to build shared libraries… yes
    checking whether to build static libraries… no
    checking for bash… /bin/bash
    checking if dolt supports this host… yes, replacing libtool
    checking for gcc… (cached) gcc
    checking whether we are using the GNU C compiler… (cached) yes
    checking whether gcc accepts -g… (cached) yes
    checking for gcc option to accept ISO C89… (cached) none needed
    checking dependency style of gcc… (cached) gcc3
    checking whether gcc and cc understand -c and -o together… yes
    checking for intel-gen4asm… no
    checking sys/mman.h usability… yes
    checking sys/mman.h presence… yes
    checking for sys/mman.h… yes
    checking for mprotect… yes
    checking if XINERAMA is defined… no
    checking if RANDR is defined… no
    checking if RENDER is defined… no
    checking if XF86DRI is defined… no
    checking if DPMSExtension is defined… no
    checking for pkg-config… /usr/bin/pkg-config
    checking pkg-config is at least version 0.9.0… yes
    checking for XORG… configure: error: Package requirements (xorg-server >= 1.6 xproto fontsproto ) were not met:

    No package ‘xorg-server’ found

    Consider adjusting the PKG_CONFIG_PATH environment variable if you
    installed software in a non-standard prefix.

    Alternatively, you may set the environment variables XORG_CFLAGS
    and XORG_LIBS to avoid the need to call pkg-config.
    See the pkg-config man page for more details.

    • David, the output from “configure” is pretty self-explanatory; configure uses a program called “pkg-config” to check for the existing of dependencies which are necessary to compile xf86-video-intel, these dependencies include xorg-server (the X server) version 1.6 or later.

      It may be that you have xorg-server installed from your distribution, but you don’t have the development package installed. You need the development package before you can compile drivers etc which need xorg-server. It depends on the distribution but it’s probably called something like “xorg-server-devel”.

      Or, you can compile xorg-server from source, that way you get the program and the development headers. Honestly though, don’t bother; you’ll end up having to compile a whole bunch of stuff.

      Davin

  2. Yes I read the blog post.
    At the time you were blogging about problems with the latest intel graphics offerings.

    August’s version of Mesa GIT was 7.5.1 in essence.
    So I was recommending you install that to solve most of your problems.

    By the way, there is no such thing as stable with anything xorg-video-intel 2.8.x, Kernel 2.6.31+.

    Too many changes to the system.

    Stable would be your old 1.6.3 driver on kernel 2.6.24/26..

    later

    • Yeah, I was blogging about problems with the latest intel graphics offerings.

      But the post was written in July, not August.

      I was probably a bit harsh with my response to your comment and I’m sorry about that. I guess you were trying to help me resolve the 3D issues (the “recursive desktop” thing). I think you didn’t understand that 3D is really the least of my worries. Sentences like:

      “Running a second X server gives me a corrupted display and promptly crashes, forcing me to reboot via a remote log-in.”

      … were meant to be the giveaway. I don’t like it when X crashes. However even that is not the heart of the matter. If the software isn’t stable, it shouldn’t be released. That’s particularly true if the software is *less* stable/functional than previous releases. Some funky new architecture “under the hood” makes no difference to the end user if it just doesn’t work properly. This is my key gripe. Check out my concluding statements (before the 31/8 update).

      (What do you mean “there is no such thing as stable with xorg-video-intel 2.8.x”?? Who says? Will 2.9 be stable? What about 2.10? When and how do I know? I think you’re wrong – 2.8.x *is* supposed to be stable; at least, it shouldn’t have had the glaringly obvious problems that it did).

  3. Compiled, on to finding how to use the compiled intel 2.8.X driver, thanks davmac, for me the cl was not pointing to missing devl but to no xorg server that’s how you helped.:)

  4. To be able to see the text-mode screen after the X you need:
    – to have vesafb compiled into your kernel
    – change the boot parameter to vga=ask or vga=3840 or vga=0xf00 (you need to check which one is working for you, more info: linux/Documentation/svga.txt)
    – if you set vga=ask you need to choose vga mode during boot and you should type f00
    Regards
    PS If you need more details write me

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s