Date: Sun, 26 Nov 2000 20:59:15 -0800 From: Steve Reid <sreid@sea-to-sky.net> To: Vallo Kallaste <vallo@matti.ee> Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: XF86-4, Linux binaries, DRI? Message-ID: <20001126205915.A40068@grok> In-Reply-To: <20001125200845.A8256@myhakas.matti.ee>; from Vallo Kallaste on Sat, Nov 25, 2000 at 08:08:45PM %2B0200 References: <sreid@sea-to-sky.net> <200011230505.eAN553G15445@bloop.craftncomp.com> <20001124024742.A355@grok> <20001124042124.A367@grok> <20001124164516.A396@grok> <20001125200845.A8256@myhakas.matti.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 25, 2000 at 08:08:45PM +0200, Vallo Kallaste wrote: > Can we have a writeup? :-) I don't recall everything that I did (I should've written it down) but here's the important stuff. Feel free to send me questions. Install the XFree86-4 port and make sure it works (you may notice some graphics artifacts with some programs; don't worry too much about it). Then get DRI working with FreeBSD binaries such as the various OpenGL-based modules in xscreensaver (try running the module manually in a window if you get flicker). Instructions for DRI are here: http://wop21.wop.wtb.tue.nl/freebsd/hwaccel.html <g450-specific> With the G450 I needed to use the mga_drv.o from Matrox as the stock mga_drv.o that comes with XF86 4 doesn't do the G450. The Matrox one is a Linux version but it interfaces with XF86 using _exactly_ the same ABI as a FreeBSD version would use so it works fine. This file can be found on the www.matrox.com web site and should be saved into /usr/X11R6/lib/modules/drivers/. The G450 also has some headedness issues with X. When I boot, the BIOS and FreeBSD boot stuff is sent to the first output, as expected. But when X starts it then directs all signal to the _second_ output on the card, so I have to plug my monitor in to the second output. When I exit X or hit CTRL-ALT-F1 the output stays on the second output. If I want to see messages during a reboot I need to plug the monitor back in to the first output to watch the reboot and then move it again to the second output when X starts. However, if you have two monitors, one on each output, the boot messages will go to _both_ monitors until X starts and directs all signal to the second monitor. So right now I have a 14 inch monitor on the floor plugged in to the first output on the card, for the sole purpose of making boot messages visible on the second output where my real monitor is connected. Ugh. No luck with dual-headded X either although I've only made one attempt (X died on a signal 6). </g450-specific> To get Linux binaries working, you need to have a Linux XF86-4 install in /compat/linux. The Linux install needs to match, version-wise, your FreeBSD install as closely as possible. Specificly, you need a Linux libGL.so from XF86-4 that will do DRI. The linux_glx port will NOT install the correct libGL.so; the version it installs may be able to do Utah-GLX style direct rendering with XF86-3, but it definately will not do DRI (which is a specific architechture for direct rendering, BTW) and it probably won't work with XF86-4 at all. Also, linux_mesa will not work either, as it is not intended for direct rendering at all. I recommend you extract libGL.so from the XF86-4 binary distribution file (Xbin.tgz) for Linux, directly from ftp.xfree86.org or one of its mirrors. With XF86-4 the libGL.so, in order to do direct rendering, must load card-specific drivers at runtime. It looks for that driver in /usr/X11R6/lib/modules/dri/, and I think it needs the <card>_drv.o file in /usr/X11R6/lib/modules/drivers/ and I think also one or two files in /usr/X11R6/lib/modules/extensions/. When running a Linux binary you need the Linux versions of all of the above, and they should be installed under the /compat/linux heirarchy. These files can all be found in the XF86-4 modules distribution file (Xmod.tgz). Once you have those in place, do `export LIBGL_DEBUG=verbose` (I think this may be Matrox-specific) before starting your Linux OpenGL program. If it goes direct, great. If it goes indirect instead then scroll back and check for error messages. "libGL error: dlopen failed: ELF file OS ABI invalid" means you have a bad or missing file in the modules directory (if the file is missing, it may try to load the FreeBSD version from outside of the /compat/linux heirarchy, which will fail except maybe for <card>_drv.o, which probably _should_ be the same file). The message "libGL error: MGA DRI driver expected DRM driver version 2.0.x but got version 1.0.0" usually means that your /modules/<card>.ko kernel module does not match your modules/dri/<card>.so (you shouldn't get this if you use stock XF86 4.0.1 files; I saw it using an X distribution from Debian Linux). If you still get indirect rendering instead of direct, check the permissions on /dev/dri/card0. That should probably be mode 666. Incorrect permissions there would break FreeBSD direct rendering as well, but it appears that the permissions can get spontaneously whacked if your system crashes, so this is probably the first thing you should check any time you have problems. Also, if you are using 4.1-R (and probably other versions as well) you will see in dmesg (and at the console and in /var/log/messages) messages about an ioctl not being implemented, and indirect rendering will be the result. You need to update your /sys/i386/linux/linux_ioctl.* with the files Stephen Hocking posted, with paths modified for the FreeBSD 4.x kernel source layout, along with the *drm.h from the XF86-4 source distribution. For simplicity just grab my tarball of the relevant files from here: http://sea-to-sky.net/~sreid/fbsdlinux_dri.tar.gz With these changes you MUST now load your linux.ko very early in the boot process, so set linux_enable="NO" in /etc/rc.conf and add the line linux_load="YES" to your /boot/loader.conf. I must mention though, all is not well with my system in DRI-land. OpenGL screensavers don't work properly: major flicker, as if there is no double buffering. They work fine in a window though. I think I've seen and fixed this before with Utah-GLX (it was caused by xscreensaver grabbing the wrong visual). If left running the screensaver eventually hangs the machine. My main 3D program, Q3A, is having major problems. From least to worst: - The graphics config screen is rather schizophrenic. Some of the settings (like the texture detail slider) don't seem to have the changes saved at all. Also, after making a change I get indirect rendering until I completely exit and restart quake. - With the "normal" graphics setting, my new config (G450/DRI) is lots slower than my old config (G200/Utah). It's okay at other settings (vertex lighting & low geometric detail), but the graphics seem jerky even when the on-screen FPS counter (/cg_drawfps 1) shows over 80 fps. It looks almost as if the position of the verticies is calculated with really low-precision math. This is most noticable when looking at the corner of two walls and sidestepping back and forth. After another look, I think this is texture-related. On q3dm7 (single-play, no bots) standing where the quad spawns and looking at the wall with the fire, sidesteping back and forth across the whole width of the room, it looks like different parts of the textures are jittering back and forth independently of each other. - The mouse control is barely playable. If I move my trackball too fast I hardly turn at all; a quick 180 is completely impossible. The overall responsiveness varies a lot. I needed to crank the mouse sensitivity setting up to over 12 or so which makes the control very jittery, although the "smooth mouse" option helps that a bit. - Q3 forgets my cdkey immediately after I enter it. This makes on-line play impossible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001126205915.A40068>