So X servers run as root, and this isn't good, for many many reason, and it wasn't always this way on other UNIXes.

So as part of my quick hacks work I got an accelerated X server on intel hw that ran as a user today.

The hacked up patches were around 300 lines total, one bit in the xserver, lots of non-root ioctl hacks to the drm and the intel driver had to register it wasn't a hw driver with X, and then fix up its buffer allocations to be non-evicted.

Surprisingly it mostly seems to work, I can start the server + gnome-session + DRI2 + compiz + glxgears on a cube, granted it oopses soon afterwards but it does show we are very close to realising the dream.

The xserver patch is in master, the drm patches are in modesetting-101 and the intel hacks are in the intel-kernelmode branch of my personal repo, as they are very hacky.

Lots of things need to be fixed so this can be done properly but it nice to just see what it looked like e.g. the frontbuffer isn't pinned properly or the cursors etc.

I have to log in on the console on vt2 and then run the following.

/opt/xorg/bin/Xorg -logfile ~/xorglog -sharevts -novtswitch vt02

Granted I'm not sure how reproducible this is, it was afternoon hacks to get over the F9 bugfixing :)

So if you have a DRI enabled ATI rs4xx/rs6xx integrated chipset and have been cursing my name because compiz doesn't work without foobar'ed textures, you can stop the cursing and start the praisin...

I've found the bug in the r300 swtcl path that caused this, the 3D driver uses the fragment shader to do rectangular textures, and this involves feeding the texture dimensions into the fragment shaders in constants. However the code to update those constants for new textures wasn't always getting called at the correct time in the swtcl path.

So http://cgit.freedesktop.org/mesa/mesa/diff/?id=a7016949f27f7612ffba7a4d0c5e6280cb3e66ba

is the fix and is now in mesa master, I'll pull it into mesa 7.0.x branch and I'll probably release F8 and F9 mesa packages with fixes. This probably won't make F9 GA but the 0-day mesa update will contain the fix.

This bug has been annoying me since July 2007 so woot!!

Well I've had a badly aligned septum for a few years so I'm going in tomorrow to have it fixed. I'll be doing very little for the next couple of days and I have to stay at home for a couple of weeks!!

So F9 will be released in a few weeks so I thought I'd mention a neat semi-hidden feature preview.

F9 will contain a preview of the future kernel based modesetting architecture for users of Intel 915 and above.

To use and test this, add i915.modeset=1 to your kernel command line and watch the future unfold :)

So far it just enters graphics mode when udev hits, and the X server should use the new modesetting architecture from then on. In theory it should give nearly flicker free startup from udev until login and X should start much faster.

Post F9 I'll hopefully merge in proper support for fast-user-switching which I've mostly working locally, just need to write a proper protocol for it.

Well working on Fedora 9, trying to fix any and all bugs in X drivers, its an uphill struggle considering i've had the flu for the past three days and it's leaving me not so inclined to do much other than sit still.

However I'm hoping its gone away by tomorrow as I'm going on hols with Gia for 4 days to Hamilton Island, no computers will be used during this time... I think I need to think about longer no-computer holidays :)

So after spending the morning doing a crap load of driver package work for Fedora, I decided to play with the r300 driver on r500 hardware.

And after I played around a bit and wrote some filler code I managed to produce a working glxgears. I checked 4 times to make sure I wasn't sw rendering.

I'm really quite surprised how little actual time this took, texturing and actual frag prog stuff will take a bit more time, but if someone is interested (and a few people are) having a working base point makes things a lot easier.

So

on my drm branch:
http://cgit.freedesktop.org/~airlied/drm/log/?h=r500-fp

amd my mesa branch
http://cgit.freedesktop.org/~airlied/mesa/log/?h=r500test

all running on a Lenovo/IBM T60P with M56 FireGL in it.

I'd add a screenshot but you all know what a working gears looks like :)

So we moved to a new office this week, and this was on my desk the second morning ... sweet 30" of goodness..

In other news on the smaller monitors, I got multi-master drm working a while back so I can run two X servers both with access to the DRM so that they can both run compiz at the same time. I fixed it up to run on top of my modesetting work, and now using gdm, I can smoothly user switch under Linux, I've two users logged in and can jump between them without flicking modes..

this actually really rocks.. hopefully I can debug the crashing out of it now...

So I had a simple task today,

take a option on the kernel command line ala i915.modeset=1

and have modprobe take this option and pass it to the i915 module when loading it.

Firstly I thought this might just work, but no.

So my first attempt added a file in /etc/modprobe.d/i915modeset

install i915 {if [ `grep -c "i915.modest=1" /proc/cmdline` = 1 ] then; modprobe --ignore-install i915 modeset=1 ; else modprobe --ignore-install i915 ] }

or something like that (you get the idea if not syntax...)

So when I ran modprobe i915 from a login post boot it all worked beautifully, but when the hybrid black/shithole that is udev started it never ever worked. I spent most of the morning playing with various scriptlets all failing to run at early boot.

So I eventually got pissed off with all of it and booted init=/bin/sh and started tracing things, apparently something is dropping permission or capabilities when spawning modprobe so that when my script runs it can't access /dev/null and grep fails on trying to write to the pipe to shell that spawned it.. Christ people what are you doing in there?

I also noticed we start_udev passes the syslog option to modprobe before syslogd is running.. winners all....

So I went a bit nuts today and went on a pciaccess convert-a-thon on the remaining x.org drivers with some major caveats.

1. I have none of this hardware.
2. Building is more important than correctness, tinderbox green light is measure of success.
3. No pci probe function implemented if I didn't have to. so chips got one nobody else.

So I fixed up to this level

chips, i128, neomagic, rendition, tdfx, tga, tseng and voodoo.

Some of these needed only a configure.ac fixup to enable the pciaccess support they already had, one needed deansification and one needed devprivates fixups.

Outstanding are amd, which has maintainers I hope will move their asses, and glint which is special in every way.

But at least the tinderbox is a lot greener now..

So I finally figured out the model for the vertex-processor less cards (rs480/rs690), thanks to a line in the new docs about how the vertex data is routed in TCL_BYPASS mode.

So after I actually worked out what the line meant, I managed to get rs690 rotate and textured video up and running..

So I'm stopping now, I think I've an idea how to fix compiz for rs690 with this info, but that'll have to wait...

I've just pushed the r500 rotate and textured video support into the radeon driver.

Alex added the r100-r300 textured video support earlier today, and I'd already started some of the r500 rotate work a couple of weeks ago just from random revenge dumps (I was just playing about on a Friday afternoon..)

Rotate seems to have a clipping problem with the bottom of my screen, I need to play some more with it, and textured video has just played 20 secs of a Doctor Who episode.

So AMD released r500 3D programming information today, the most interesting piece being the r500 fragment shader programming guide which allows us to maybe get r300 into some kind of shape for r500 use.

So along with the intel 965 docs, we now have 2 fairly well documented chips. So an excuse I've always heard from people turning up on irc channels is OMG I can't hack on GPU drivers there are no docs!!!. So now that we have these docs I'm expecting a large amount of developers to be able to bootstrap themselves on modern hardware. I wonder how disappointed I'm going to be.

updated: http://www.x.org/docs/AMD/ is the docs location, the newest pdf is the r500 3D engine manual.

Keith Packard just announced 965 documentation release without NDA terms..

http://intellinuxgraphics.com/

http://www.x.org/docs/intel

Thanks to some great work by Maciej Cencora we have initial support for 3D on the RS690 chipset. The level of support is the same as the current rs4xx chipsets, i.e. glxgears works, some other 3D apps should work, compiz doesn't work.

The changes are in the drm and Mesa master trees now and require the latest xf86-video-ati radeon DDX. I'll be getting a real rs690 post-LCA and my first task is to try and fix the r300 3D driver bugs that are stopping compiz from working, and hopefully fix a few bugs with some other 3D applications.

The RS690 is a hybrid chip with the r5xx era modesetting core combined with an r4xx 3D core with no vertex-shader/tcl support.

Next week I'll be attending LCA for the week, I'm co-organising the Kernel miniconf on Tuesday, and giving a talk on open source graphics drivers on Friday morning at 10:30 am..


Bringing kittens back to life - continuing story of open source graphics drivers

This will cover the latest news on the AMD open source project, Intel open drivers and the nouveau project. Hopefully with a demo of something cool.

Another year down, 32 today and the hangover to prove it, going to Wet 'n' Wild Water park for the day though so that should sort it all out...

Myself and Gia went for Teppanyaki last night in Brisbane which was great fun, really nice food but it was hot so I chugged a few Sapporos.... followed up with a few whiskeys at home and et voila hangover.

So we have a problem with fast-user-switching and the DRM at the moment, the drm has a concept of a master process which controls a number of aspects of it, it can only handle one of these processes existing however at the moment.

So the second X server never gets access to the DRM and so you can't run compiz or even gears on a fast-user-switched desktop. This is the suck.

So I spent this afternoon just hacking around the problem to see if I can get some of the basics to work... and I have now gotten two servers with glxgears in each vt-switching between them on a 945G.

The drm patches are at
http://cgit.freedesktop.org/~airlied/drm/log/?h=multi-master

the intel driver hack up is at:
http://cgit.freedesktop.org/~airlied/xf86-video-intel/log/?h=multi-master

It still has problems, the major one being if you kill a master who isn't the current master, its very like cats and dogs living together. I'm hoping when we get more state into the kernel side drm drivers we can handle this a lot more gracefully.

I've spent the afternoon playing around with the atombios support for tv-out on my r500 card.

It now brings up X on my S-video output on my Dell monitor by using the atombios tables correctly.

Please be testing and report in #radeon any issues or regressions this might cause :)

So myself and Gia bought a house about 6km outside Brisbane and we hopefully settle today and get the keys.

So I'll be disconnected from the Internet from tomorrow morning sometime until at least the 2nd of January when I get into the office again.

We have to move tomorrow as getting movers in the Xmas<->new years gap wasn't proving possible. I might be able to "leverage" some net access with a pringles can but we'll have to see how it works out.