X.Org 7.4 prereleases ready to test in Gentoo
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.
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
S
July 1, 2008 at 2:13 pm
That’ll be in the upstream release notes once 7.4 final comes out.
Donnie Berkholz
July 1, 2008 at 3:03 pm
Does this give us DRI2 ?
Movi
July 1, 2008 at 3:12 pm
Not yet. That required TTM (a new memory manager), which actually got dumped in favor of an even newer one called GEM.
Donnie Berkholz
July 1, 2008 at 3:20 pm
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 Nicholson
July 1, 2008 at 4:33 pm
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.
Donnie Berkholz
July 1, 2008 at 4:39 pm
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).
Dan Nicholson
July 1, 2008 at 4:54 pm
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.
Donnie Berkholz
July 1, 2008 at 5:20 pm
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!
AzP
July 2, 2008 at 12:20 am
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?
Movi
July 2, 2008 at 1:15 am
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
Mart Raudsepp
July 2, 2008 at 1:29 am
@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.
Donnie Berkholz
July 2, 2008 at 8:13 am
I suppose xorg 7.3, release almost a year ago, is just being skipped? Some things on gentoo confuse me very much.
Andrew
July 2, 2008 at 8:37 am
@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.
Donnie Berkholz
July 2, 2008 at 9:18 am
Another driver than don’t work is the s3virge. And this is the second time that a xorg-upgrade broke the s3virge drive…
cruzki
July 2, 2008 at 9:55 am
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
July 2, 2008 at 10:01 am
@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.
Donnie Berkholz
July 2, 2008 at 10:09 am
=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
rem5
July 2, 2008 at 10:31 am
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
July 3, 2008 at 7:00 am
@Movi: I think there’s some kernel work as well.
Donnie Berkholz
July 3, 2008 at 9:10 am
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.
Andre Müller
July 3, 2008 at 11:04 am
@S: This might be of use – http://www.phoronix.com/scan.php?page=article&item=xorg_74&num=1
Arun Raghavan
July 6, 2008 at 1:29 am
xorg-servel failed on my system with message saying about missing drm.h include.
Mario
July 7, 2008 at 11:38 am
@Mario: That should come from libdrm. Do you have 2.3.1 installed?
Donnie Berkholz
July 7, 2008 at 1:46 pm
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.
w3lly
July 8, 2008 at 2:25 am
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
July 8, 2008 at 11:50 pm
@Mario: Try reinstalling libdrm 2.3.1.
Donnie Berkholz
July 9, 2008 at 12:01 am
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.
Mario
July 9, 2008 at 12:05 am
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 Rathgeb
July 11, 2008 at 12:05 am
@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.
Donnie Berkholz
July 11, 2008 at 12:30 pm
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!
Nate Weibley
July 20, 2008 at 10:42 pm
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.
Markus Rathgeb
July 21, 2008 at 1:56 am
I have reported that bug (I hope I have done it right).
Markus Rathgeb
July 21, 2008 at 3:02 am