Last night, Dave Airlie released libdrm 2.3.1, which set the stage for all the pieces of the X.Org 7.4 prereleases to actually work (with a couple mesa patches). If you’d like to test 7.4, here’s how. This assumes you’re already running an ~arch (testing) system–if you aren’t, you might want to hold off on testing hard-masked packages. This may not work with binary drivers–particularly ati-drivers. It looks like nvidia-drivers has preliminary support for xorg-server 1.5.
echo "
# xorg-server-1.5 prerelease
=x11-base/xorg-server-1.4.99*
=media-libs/mesa-7.1*
x11-proto/dri2proto
=x11-libs/libdrm-2.3.1*
" >> /etc/portage/package.unmask
emerge -va xorg-server
emerge -va1 $(qlist -I x11-drivers)
I’ve still got 16 more packages to bump before everything’s up to date, but the main parts are in place.
Striving for greatness 
Eagerly waiting for xorg in ~amd64
can you post a bit about new features in 7.4 and how/what’s good in it?
~S
That’ll be in the upstream release notes once 7.4 final comes out.
Does this give us DRI2 ?
Not yet. That required TTM (a new memory manager), which actually got dumped in favor of an even newer one called GEM.
I was looking over your ebuild for mesa and noticed a couple thing.
– TTM is default off, so you’d only need to –enable-ttm-api if that’s what you wanted.
– The Motif widgets in libGLw are actually not wired up yet. Look at the comment above GLW_SOURCES in configs/default. That logic needs to get into configure.ac, but I haven’t gotten around to it yet.
– For debug builds, you may want to use –enable-debug since it also adds -DDEBUG for some extra output and support for the MESA_DEBUG/MESA_VERBOSE environment variables.
– I added a feature test for posix_memalign that should be in 7.1, so you can drop the HAVE_POSIX_MEMALIGN editing when it gets released.
What’s the issue with makedepend? I’ve debugged a few of those issues, but I thought things were working now.
Dan, thanks for looking it over!
– TTM: Yep I know, it’s just a reminder of something to possibly change later.
– Thanks for the heads-up! I need them working for an app called PyMol, so I’ll have to do it at some point if you don’t.
– Sounds like a good plan.
– Yep, saw that commit. Looks nice.
– Not sure what you saw with makedepend … maybe some WIP trying to get 7.1_rc1 building against libdrm 2.3.1 before airlied fixed it yesterday.
The makedepend thing was at the bottom of this commit:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/mesa/mesa-7.1_rc1.ebuild?r1=1.3&r2=1.4
I’m not sure what that would do. Maybe something’s goofy in the tarball. Oh, I think the problem is that the depend files are shipped, but you have the TTM patch which removes the need for xf86mm.h. But still, the depend files should just get rebuilt since the timestamps have been updated with the patch. Or something like that.
For motif, do you guys use lesstif with the motif-config script? I’d rather gather the information instead of just doing AC_CHECK_LIB(Xm).
Old news. =) http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/mesa/mesa-7.1_rc1.ebuild?r1=1.4&r2=1.5 — It was actually a problem in the code with asserts that looked to me like a problem in the build.
For motif, we now only have openmotif available. motif-config is installed, though.
Cool, can’t wait to get home and break my system! =)
I’ve been waiting for a (serious) mouse pointer bug to get fixed in Xorg-server, and since there were some binary (or source) breaks connected to it they couldn’t fix it until 1.5. I hope it works now!
Hmm, would enabling ttm in mesa make my intel driver use it? If so, could you maybe add a USE flag or at least comment a line in the ebuild that would enable such magic?
motif-config was recently killed from the portage tree and shouldn’t exist anymore, other than on systems that haven’t gotten around to unmerging it
@Movi: released libdrm versions don’t support TTM and as far as technology goes, at this point it’s the living dead.
@Mart: Thx for the info. I don’t generally run emerge –depclean, so it’ll probably stick around for a while.
I suppose xorg 7.3, release almost a year ago, is just being skipped? Some things on gentoo confuse me very much.
@Andrew: xorg-server 1.4 was really broken. 1.4.2, which came out just a couple of weeks ago, finally fixed most of the problems.
Another driver than don’t work is the s3virge. And this is the second time that a xorg-upgrade broke the s3virge drive…
I completely forgot. I search the fredesktop bugzilla and gentoo bugzilla as well and there is nothing about my problem. May I fill a bug or wait until a new version of the driver arrive? In the x11 overlay don’t be an ebuild for xf86-video-s3virge
@cruzki: File a bug at bugs.freedesktop.org. Nobody’s really developing that driver, so they won’t come across it unless you file a bug. Honestly, even then, you may not get it fixed without contributing a patch yourself.
=x11-base/xorg-server-1.4.99* run fine since released in X11 overlay with some git ebuild: x11-drm, mesa, xf86-video-radeon and required dependency.
Only synaptics miss me !
good work
I just did my research, and it seems that this release is not hopeless as i thought – it seems once libdrm-2.4 and intel-2.4 hits release, intel users will have dri2 goodness. Is this correct?
@Movi: I think there’s some kernel work as well.
Thanks, it works just nice even on an otherwise x86 box.
For anyone lazy and adventurous, the package.keywords file wants to have the following entries:
x11-proto/renderproto ~x86
x11-proto/dri2proto ~x86
x11-libs/libdrm ~x86
x11-libs/xtrans ~x86
x11-libs/libXrender ~x86
x11-drivers/xf86-input-keyboard ~x86
media-libs/mesa ~x86
x11-base/xorg-server ~*
x11-libs/libpciaccess ~x86
x11-proto/xproto ~x86
x11-proto/inputproto ~x86
x11-apps/xauth ~x86
x11-proto/xextproto ~x86
x11-libs/libXext ~x86
x11-misc/xkeyboard-config ~x86
x11-apps/xinit ~x86
x11-apps/rgb ~x86
x11-libs/libXfont ~x86
x11-drivers/xf86-input-mouse ~x86
plus the grapics driver, of course.
@S: This might be of use – http://www.phoronix.com/scan.php?page=article&item=xorg_74&num=1
xorg-servel failed on my system with message saying about missing drm.h include.
@Mario: That should come from libdrm. Do you have 2.3.1 installed?
I use x11-base/xorg-server-1.4.99.905 on my gentoo-amd64 with nvidia-drivers-173.14.09 all worked fine for me.
Donnie Berkholz,
Since mesa-rc3 was released yesterday, I decided to try compile xorg once again. And unfortunately xserver-xorg compilation failed at the same point. Here is emerge output:
[ebuild R ] x11-libs/libdrm-2.3.1 USE=”-debug” 0 kB
[ebuild U ] x11-base/xorg-server-1.4.99.905 [1.4.2] USE=”hal minimal sdl xorg (-3dfx) -debug -dmx -dri -ipv6 -kdrive (-nptl) (-xprint%)” INPUT_DEVICES=”keyboard mouse -…”
VIDEO_CARDS=”nv nvidia -…” 0 kB
and error output:
In file included from glxdricommon.c:35:
/usr/include/GL/internal/dri_interface.h:43:17: error: drm.h: No such file or directory
In file included from glxdricommon.c:35:
/usr/include/GL/internal/dri_interface.h:278: error: expected declaration specifiers or ‘…’ before ‘drm_clip_rect_t’
My keywords are set to `~amd64′. Any suggestions please?
@Mario: Try reinstalling libdrm 2.3.1.
xserver-xorg compiled and installed successfully after I’ve changed include in /usr/include/GL/internal/dri_interface.h from #include to #include . Seems that problem was with my header files.
Thanks.
Hi!
It is possible, that some applications will not work with this version (I use the the radeon driver)? For example:
google earth (native)
hangs on splash screen – the trick with the libGL.so.1 will not work anymore
google earth (via wine)
there is no earth
sauerbraten
after initialisation I have a black screen and to kill the game
@Markus: Sure. First ensure that your direct rendering is working (glxinfo | grep render). If it is, that could be a Mesa bug. If you’ve tried mesa 7.1_rc3 and it’s broken, please report a bug at bugs.freedesktop.org in the mesa product.
I’m unable to build off this ebuild either. I’m hitting a wall once I start building glx/dri stuff. This is on Mesa 7.1_rc3 built w/ dri.
The first few lines of the errors are:
mv -f .deps/glxext.Tpo .deps/glxext.Plo
/bin/sh ../libtool –tag=CC –mode=compile x86_64-pc-linux-gnu-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 -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/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 -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server -D__GLX_ALIGN64 -march=athlon64 -O2 -pipe -ggdb -MT glxdricommon.lo -MD -MP -MF .deps/glxdricommon.Tpo -c -o glxdricommon.lo glxdricommon.c
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
glxdriswrast.c:67: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘*’ token
glxdriswrast.c: In function ‘__glXDRIdrawableDestroy’:
glxdriswrast.c:92: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
It looks like a missing include path or something? A bit stumped, but I want to try 7.4!
Sorry for my late response, but I do not have internet for a while.
I am using the latest mesa version (7.1_rc3) and the error still occurs.
I have reported that bug (I hope I have done it right).