Hmm, I just noticed something that does seem suspicious: a big size difference between the openchrome driver and the other Unichrome drivers. xf86-video-unichrome and xf86-video-via are both 0.9 MB, but openchrome is only 0.2 MB. Could there be files missing from the openchrome package?

DRI drivers are missing from the openchrome package. Some other things I noticed:
- why is the package in multimedia? it should belong in x11 (extra) or x11-drivers (current).
- DRI modules aren't included, mesa 6.5 drivers should be included
- Shouldn't the package be named xf86-video-openchrome?
- There's a conflicts on the via driver, but the unichrome driver is conflicting also
- autogen.sh is changed to run ./configure --prefix=/usr, this option can get passed to autogen aswell, it will pass all options to ./configure.

I think we've had them all now.

Good comments, y'all.

For starters, it *appears* that DRI IS working for me, so I have to figure out why. I wonder if I've compiled it against the wrong kernel. I'm using kernel26 2.6.17.6-1:

***

(II) VIA(0): [drm] Detected AGP vendor 0x1106, device 0x259
(II) VIA(0): [drm] Found AGP v3 compatible device. Trying AGP 8X mode.
(II) VIA(0): [drm] Trying to enable AGP fast writes.
(II) VIA(0): [drm] drmAgpEnabled succeeded
(II) VIA(0): [drm] agpAddr = 0xe0000000
(II) VIA(0): [drm] agpBase = (nil)
(II) VIA(0): [drm] agpAddr = 0xe0000000
(II) VIA(0): [drm] agpSize = 0x01e00000
(II) VIA(0): [drm] agp physical addr = 0x00000000
(II) VIA(0): [dri] use agp.
(II) VIA(0): [drm] Using 61307232 bytes for DRM memory heap.
(II) VIA(0): [dri] frame buffer initialized.
(II) VIA(0): X context handle = 0x1
(II) VIA(0): [drm] installed DRM signal handler
(II) VIA(0): [DRI] installation complete
(II) VIA(0): [dri] kernel data initialized.
(II) VIA(0): [drm] Irq handler installed, using IRQ 10.
(II) VIA(0): [drm] Initialized AGP ring-buffer, size 0x200000 at AGP offset 0x1e
00000.
(II) VIA(0): direct rendering enabled
Fulfilled via DRI at 5532480
(II) VIA(0): Benchmarking video copy. Less is better.
(--) VIA(0): Timed libc YUV420 copy... 3657166. Throughput: 129.8 MiB/s.
(--) VIA(0): Timed kernel YUV420 copy... 3642220. Throughput: 130.3 MiB/s.
(--) VIA(0): Timed SSE YUV420 copy... 2309334. Throughput: 205.6 MiB/s.
(--) VIA(0): Timed MMX YUV420 copy... 3713665. Throughput: 127.8 MiB/s.
(--) VIA(0): Ditch 3DNow! YUV420 copy... Not supported by CPU.
(--) VIA(0): Timed MMX2 YUV420 copy... 2361538. Throughput: 201.0 MiB/s.
Freed 5532480 (pool 2)
(--) VIA(0): Using SSE YUV42X copy for video.
(II) VIA(0): [XvMC] Registering viaXvMCPro.
(II) VIA(0): [XvMC] Initialized XvMC extension.
(II) VIA(0): - Done

***

To the other points:

1) Multimedia? It is related to multimedia. It's also related to x11. I don't have a strong preference; I'll move it to x11 if everyone would like.

2) I guess I need to learn more about mesa and DRI modules. Can someone explain why it's working for me? I thought via DRI was in the kernel and that openchrome used the same hooks.

3) I would assert that the package should definitely NOT be called xf86-video-openchrome. To me, that would suggest it's a standard part of the X driver set of packages, which it isn't. Again, happy to hear arguments to the contrary.

4) I will add a conflict with unichrome.

5) I will take the autogen suggestion. Hadn't spotted that shortcut.

1) It's an xorg driver, so it should be in x11-drivers or x11. Since extra doesn't have x11-drivers, it should go where ati and nvidia are.
2) I guess you have the DRI driver files from unichrome or via installed, those are the same
2a) You can take over the DRI build stuff from unichrome which is or was in testing, that should have mesa 6.5 drivers.
3) ok, nvidia and ati aren't named xf86-video-fglrx and xf86-video-nvidia.

1) Makes sense.
2) I will check into this some more. Maybe I'm not running DRI and it just looks that way. I clearly need to look at all this some more, and once I have, I'll do something with the unichrome DRI stuff or discuss some more in this thread.

Two more things:
- I guess a (make)depends should be added on xorg-server, as the driver compiles stuff from xorg in it (mainly things like ABI versions, nothing special furthermore)
- You're running autogen, so add a makedepends on xorg-util-macros, as xorg-alike packages require these macros to autogenerate.

Sure thing. Thanks for the good comments. I am NOT expert on the new Xorg yet, but my guess is that maintaining this driver will get me on the path to becoming so. ;)

I'm maintaining this package in unsuported (aur): http://aur.archlinux.org/packages.php?do_Details=1&ID=4132&O=0&L=0&C=0&K=openchrome&SB=&SO=&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd

Although outdated, It builds working DRI stuff. Here DRI (with that PKGBUILD) works like a charm. Maybe It could serve as reference to fix the openchrome in extra. As I'm not the author of the PKGBUILD, I don't fully understand why (or how) it works. I'll figure out and come back to say.

I think I've addressed all the issues in the -2 version. Please let me know if I missed any.

-2 only adds the DRI drivers and breaks with AMD64.
I changed the package to have all the issues fixed and updated to mesa 6.5. The driver has been committed to testing because of the mesa change.

Thanks, Jan, for the additional cleanup.

Can anyone tell me if the -2 DRI is working better for them?