DualHead setup with GLX

16 May 2014

Introduction

Not wanting to miss the cryptocurrency fad, I desired to mine a few of my own. Scrypt-based crypto-coins, like Litecoin are (currently) best mined with ~ATI~ AMD GPU. So I got myself a second-hand HD7950 and decided to use it only for mining, while relying on the HD4000 GPU ( integrated in my core-i7 processor ) for desktop and not-too-intensive gaming gaming.

This tutorial/rant won’t go into much detail about the mining part, and miner configuration. This is already well explained everywhere else on the internet.

Braindead customer (Windows user)

Setting it all up under Windows was pretty straigthforward:

Install catalyst drivers
Install intel drivers
Make the board believe there’s a monitor actually installed
Install the required accelerated parallel programming SDK
Install cgminer and point it to your favorite pool
(optional) Overclock the board with OverDrive
Get dem coins, while playing heartstone without issue

This was fine, but not very satisfying. On to the real men world.

Proprietary driver hell

The previous method was more of a proof of concept. I want the same setup to run under Debian/Sid so I can be all nice and cozy.

The install procedure still kinda works, except you have of course to download linux-64b versions of the driver installer. I used the 14.4 version, which seemed to support Sid’s kernel (not anymore: 3.13 only… sigh ).

I configure my desktop manager to run a “dual seat” configuration like so:

Seat0 corresponds to the integrated HD4000 and Seat1 the 7950.

You can see it starts two different Xorg processes with two different configuration files which are:
xorg.0.conf:

xorg.1.conf:

WARNING these config files were hacked from scavenging the internet. Therefore I can’t be sure they are optimized, make any sense, or aren’t the source of the issues I’ll discuss in the end of this post.

All is well with this configuration. I just had to specify the DISPLAY variable before running the mining scripts. ALAS , the issue with this is that AMD drivers have the urge to take a shit in your /usr/lib directory, moving around graphic libraries, and symlinking their own in weird places.

What this means is both Xorg instances have to run with AMD libraries, which is fine with the Seat1 configuration from above, but totally breaks GLX loading for the Seat0 (the one with a real monitor).

There is some hope though, AMD is nice enough to provide two scripts:

/usr/lib/fglrx/switchlibGL
/usr/lib/fglrx/switchlibglx

which are able to undo and restore the /usr/lib hell. The problem is, I still can’t have both versions of libGL.so and libglx.so for my two Xorg instances.

Renzotech my /usr/lib

I wasn’t sure that the previous two scripts were the only things the huge-ass driver installer was doing. The bulldozer approach I had was:

Take a LVM snapshot from a fresh Debian/sid, then install AMD’s drivers
Mount the snapshot, and make a quick diff to round up all the burps the AMD installer does in my /: diff -qr / /mnt/snap/

I was now sure that only /usr/lib̀ was impacted by all the fun the proprietary drivers have to offer.

I just had to keep two different directories:

one clean /usr/lib for my Seat0 X, with only Debian libs
one dirty /usr/lib for my Seat1 X, with AMD libs

My system being Debian Sid, it breaks all the time, and keeps having kernel updates and whatnots, so I may have to reinstall the AMD drivers every so often. Moreover, there is no chance in hell I was going to patch the +100Mb installer thing to make it behave in a dedicated /usr/lib tree. So in the end I decided to have two /usr/lib folders :

/usr/lib for Seat1, with AMD libs
/usr/lib-test for Seat0 without those libs

Of course, I want all the updates backported in /usr/lib-test, so after every upgrade, I just run the following script:

What it does is:

Checking your /usr/lib is dirty with proprietary drivers
(optional) Deleting /usr/lib-test
Creating /usr/lib-test as a “hollow” copy of /usr/lib, with only symlinks
Restoring the ̀libGL.so and libglx.so symlinks to link to the Debian ones (as would switchlibGL and ̀switchlibglx do)

WARNING !!!! The script doesn’t care about 32 bits libs. I’m not running any 32 bit program on the AMD card, so I don’t care about them. When I want to restore them in my “clean” /usr/lib-test (for example, after an update) I just run:

apt-get install --reinstall libgl1-mesa-dri:i386 \
    libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 \
    libglew1.10:i386 libxmu6:i386 libxt6:i386

before running the above script.

And voilà ! …. not really. Last but not least, We need to specify our Seat0’s X to load its libs from /usr/lib-test :

# cat > /usr/bin/X-0 <<EOF
export LD_LIBRARY_PATH="/usr/lib-test"
exec /usr/bin/X "$@"
EOF
# chmod a+x&nbsp;/usr/bin/X-0</span>

and change the path to that X in the lightdm.conf file (xserver-command directive).

When your input devices play dirty tricks

This is the last issue I had to assess. Don’t remove the lines concerning input devices from the previous xorg.(0|1).conf files. They prevent the Seat1 Xorg from using your mouse and keyboard.

You get VERY weird stuff happenning when you control two Xorg process with the same set of keyboard+mouse, including: