You are not logged in.
I wanted use my FreeBSD box with xdmcp and with GLX extension so Xephyr was the way to go.
However Xephyr whined about dlopen /usr/lib/xorg/modules/dri/swrast_dri.so file doesn't exist. That file is part of libgl package which happens to confilct with nvidia-utils. Nvidia utils provides OpenGL for my system. changin from nvidia to mesa and something else wasn't good idea.
My solution was to unpack libgl
cd libgl/usr/lib/xorg/modules/dri/
sudo mkdir /usr/lib/xorg/modules/dri/
sudo cp * /usr/lib/xorg/modules/dri/
Now glxinfo gives mesa as DRI and glxgears rotates 62fps from Intel D945GCLF2 system on my desktop. Full load on FreeBSD and network usage is 600Mb. And I'm happy. Still my desktop uses nVidia for OpenGL
However that solution is ugly. How should I do it in Arch way? And have I broke something seriously?
Offline
You haven't broken anything. I consider putting swrast_dri.so into the libgl package a packaging bug. It should get it's own package, like all the other dri drivers have. I'm too lazy to create an account and file a bug though .
But just to make sure, you realize swrast is a software renderer, do you? I'm just checking if that's what you really want. Xephyr used to support hardware acceleration a long time ago, now it doesn't anymore.
Offline
Nice to hear I didn't broke anything really. And yes.
I know it's software based. sw and rast gave a hint. However comparing slow performance with no performance of OpenGL programs the increase is infinity percent
EDIT: https://bugs.archlinux.org/task/28299
Last edited by vuokkosetae (2012-02-06 23:23:26)
Offline
Thanks for that. It's not just Xephyr that hits this issue, TigerVNC is affected too. TigerVNC's Xvnc can provide GLX with swrast. That's where I encountered this issue, and I did the same thing you did - unpacked the libgl package manually and copied the swrast files into /usr/lib/xorg/modules/dri/
Offline