How To: Fix Black Screen with Nvidia drivers and Linux Kernel 3.10+

I’m running Arch Linux with a Nvidia graphics card, and after doing a system update back in March 2014 any kernel past 3.10.x would cause X / Xorg to fail to start; instead there’d be a black screen and the fans on the graphics card would spin up to full speed so my machine sounded like a hovercraft. I initially got around this by running the linux-lts (Long Term Support) kernel, until that too exhibited the exact same issue and I was forced to boot the system from USB, chroot into it and switch out the nvidia driver for nouveau (the open-open source, 2D accelerated nvidia driver).

However, as I happen to quite like accelerated 3D graphics and occasionally playing games, I’ve been digging around for a fix for this for ages – and it turns out that the fix (which is now added to the Arch Nvidia wiki page) is to add the following kernel parameter to your bootloader’s kernel line:

If you’re using GRUB, when menu shows up just move the selection to Arch or your Linux distro exhibiting the issue, then hit the e key to edit the line, and change the linux kernel loading line from, for example:

To include the rcutree kernel parameter, something like this:

At which point you can hit F10 (again, assuming you’re using GRUB) to boot using your newly added kernel parameters. Don’t worry if your kernel loading line identifies your partition by UUID value instead of plain ‘ol /dev/sdx – that’s fine and mine does too (I changed it to /dev/blah to make the line shorter) – just add the parameter and try your luck – hopefully your distro will now boot into X without issue, and you can stop swearing and cursing like a drunken sailor. Or perhaps that was just me.

Further reading about the issue on the nvidia development website:


P.S. If you need to chroot into your Arch system to change the drivers also, then here’s a quick run-down of the process. Make a bootable USB from the Arch ISO (I could only get this to work by using the dd command from another Linux distro – Rufus and UNetBootin would make a USB I couldn’t boot from – google or search this site for “dd iso usb” for instructions), then, when you’ve booted into the live USB/CD-ROM or what-not, run the following commands (the “<---- optional" lines are optional, don't actually enter that into your files, obviously!):

With any luck you'll have now transitioned the drivers successfully and have a fully working system - fingers crossed, good luck!

How To: Install the Leap Motion Driver & SDK outside of Ubuntu/Debian Linux

The Leap Motion Leap sensor forms part of some research I’m working on atm, but the drivers only come as .debs packaged for Ubuntu or other Debian-based distros. As I’m on Arch (and don’t really want to run dpkg alongside pacman), I wanted a way to pull out the files from the .deb bundle and stick them in the right place. Luckily, it’s pretty easy to do – here’s how…

Download and Extraction

So, let’s say you go to and get yourself a copy of the most recent Linux driver, which at the time of writing is: Leap_Packages_1.0.9+8411_Linux.tgz.

Extracting the archive will give you two files:
Leap-1.0.9+8411-x64.deb, and

If you look at either of those two files with Archive Manager you’ll see the file data.tar.gz within ’em. Pick your flavour (32-bit is x86, while 64-bit is x64) and extract it.

Inside the data folder you’ve just extracted you’ll find three directories:
lib, and

Scripted Install

In the folder with the above etc, lib and usr folders, create a file (call it anything you like, for example) and dump the following into it:

Now chmod +x the file so it’s executable and we’re almost ready to go. Unfortunately this doesn’t allow for that easy uninstallation, but you can just manually ‘nix it by throwing the following into another script:

Optional: Reload udev rules

Try skipping this section for now and come back to it if your device doesn’t register, ok?

Apparently udev uses the inotify mechanism so you don’t need this (source: but I did this anyway and it worked:

Start the daemon & visualiser

Now that’s all done, you should be able to start the Leap daemon with:

Then plug your leap sensor in and it should work when you run ‘Visualizer’ or such. Cheers!

Leap visualiser on Linux

Update – July 2016

Doing this again today, I needed to move the contents of the /usr/share/Leap folder (i.e. *.ldat) to the /usr/local/sbin folder for leapd to start without errors – also, as mentioned, be sure to run leapd as sudo or it’ll launch (with websocket errors) but it won’t work. Also, I moved the *.so files, “platform” folder and “Playground_Data” folders into /usr/local/bin, which has made that folder a bit of a dog’s breakfast, but it works… Probably a better idea to use “alien” to install the deb, or make a PKGBUILD on arch than this hacky way of cobbling it together.

How To: Enable High Quality Audio in Linux

My wife got me a FiiO E17 USB headphone amp (thanks, hon!) to go with my Sennheiser HD650’s the other day, and it can handle 96KHz 24-bit audio – but by default pulseaudio and alsa are configured for 44.1KHz 16-bit audio. At the 44.1/16-bit settings everything sounds great, but I figure if the quality can go higher and I’m not fussy about a bit of extra CPU usage then I may as well bump the quality settings up a bit to take full advantage. Here’s how to do it:

1 – Check current settings

To see what your current settings are, you can either run the following for the full details:

Or to cut to the sample rates directly use:

Depending on how many sound devices are connected you should see something like this (in my example I have an Intel HDA internal soundcard as the first sink, and HDMI audio out as the second sink):

You might want to play an mp3 at this point and then look at the pulseaudio cpu usage via the top command so you can compare the current and HQ CPU usage as it might be a factor for you (i.e. depending on the spec of your PC, you might not want to sacrifice 10% or more CPU usage for higher quality audio – but seeing as you’re here and reading this I’ll assume that you are!). As a baseline, with the default settings pulseaudio uses around 2-3% CPU to play an mp3 on my Intel i7.

2 – Modify for high quality

Pulseaudio’s global settings are stored in /etc/pulse/daemon.conf, so edit that with your editor of choice and look for the following lines (the ‘resample-method’ line is above the default-sample-* lines btw – that is, they’re not all together as below):

These are the defaults, and are currently commented out (you can use either ; or # to indicate a comment). Uncomment each line and modify it to the below (or even better – just add an uncommented line below each one so you can still see the default values), so you end up with:

The Arch Audiophile Playback wiki recommends medium quality for resampling, you might want to try src-sinc-best-quality if you’re going for broke. A description of the libsamplerate resampling methods can be found here if you’re interested:

I get about 10% CPU usage on the pulseaudio daemon with 96KHz @ 24-bit audio with medium quality resampling as above, whilst using src-sinc-best-quality results in a rather significant 24% CPU usage just to play an mp3! ( It’s like having a Pentium 100MHz all over again! ;-) ) The ‘s24le’ means 24-bit samples, little-endian order, btw.

3 – Restart pulseaudio and check the settings

Now that’s done we need to restart the pulseaudio daemon (don’t run these as sudo – pulseaudio runs per user so just execute as normal!):

Once that’s done, you should be able to check the settings have taken by issuing:

It’s jumped up to 32-bit samples in this case, but that’s fine. Check the audio still works, and maybe have a look at the CPU usage when playing an mp3 via top again if you want to see how much this is affecting the CPU usage on your machine.

FiiO E17 Amp Check

Now that we’ve set higher quality default settings, if you’ve got some suitable hardware for them like the above-mentioned amp, plug that bad-boy in, switch it on – and it should validate that it’s getting the higher sample-rate and sample-depth:

Fiio E17 at 96KHz 24-bit via pulseaudio
Fiio E17 at 96KHz 24-bit via pulseaudio via USB (i.e. it’s acting as a sound card). The ’40’ value is just the current volume setting.

Sound Quality Differences

So – does changing these audio setting make a definite, perceivable difference to the audio quality? The short answer is yes!

How much it changes the audio quality is going to depend on your hardware (amp, headphones etc.) as well as the actual audio file(s) you’re playing on it. I don’t have any 24-bit audio to try it out on, but I rip everything at the highest possible quality VBR mp3s using lame – so I’ve been testing on the first track of Alt-J’s album (intro) with some Sennheiser HD650’s – and my honest answer? I’d go as far as to say it’s a strong yes (html joke ;-)). The high-frequency elements in particular seem a little brighter with the 96KHz 24-bit sampling, at least when run through the FiiO E17. Now, this could be placebo – that is, you expect something to sound different/react in a particular way so you look for it and (internally, subconciously) try to convince yourself of it. But I’ve honestly swapped back and forth and listed to the same track a number of times during the writing of this article and I genuinely believe it’s sounding better with the HQ settings.

Unfortunately, the schoolboy error I’ve made here is that I’ve changed two (if not three!) things at once: I’ve enabled the higher sampling-rate and sample-size/depth, but I’ve also modified the resampling algorithm to one of higher quality at the same time – so figuring out what elements of the audio sound better because of the audio settings and which are from the resampling-method (because I’m not playing native 96KHz @ 24-bit audio files to test with) can’t really be done. To get any real results I’d need to strip back to default settings and modify each in turn, doing listening tests with notes as I go, which frankly isn’t all that high up there on my priority list of things to do because…


…I’m delighted with the audio quality after these changes! It really does sound great =D

Ideally, I’d prefer to have things set to 44.1KHz on each audio device EXCEPT the Fiio – that way, when I’m playing games there’s minimal CPU used on the audio side (which isn’t really going to benefit that much from upsampling and such, I’d imagine) and then have the HQ settings for the FiiO only so that when I plug it to listen to music I get the HQ audiophile kick. However, my understanding is that I’d need to go into the alsa side of things to configure device specific settings – and again, it’s not really a high priority at the moment.

I’d love to hear what difference (or lack thereof!) any of you find when changing over to HQ audio (asides from the bump in CPU usage) – and if you run or have played with different samplerate/re-sample settings for diff devices I’d be especially interested! Cheers!

How To: Mount a Google Nexus 7 Tablet in Linux

In Windows you can just plug it in and it’ll mount and recognise just fine, but in Linux you need to work a little bit harder. Not that much harder, though – it’s a 4-step….

1 – Get the right tools

2 – Set up a udev rule to do the right thing on connection

Add this text to the rule to specify the Vendor ID, Product ID and user who has access to the device (change YOUR-USERNAME-HERE to your username, obv):

3 – Restart udev and set up a mount point

4 – Hook it up

Plug in your Nexus 7 and select MTP device as the connection type.

Then enter:

At this point you should be able to read/write to your N7 via the /media/Nexus7 folder through any means you choose.

When you need to, just run either of the following for a clean dismount:


Source:, I just paraphrased it a little to simplify.

How to: Get Minecraft working in Linux

Minecraft Wallpaper

Attempt a quickfix?

If you’re trying to run Minecraft in Linux and it’s failing with errors like:


Then the chances are you can fix it up by performing the following actions:

  • Set your LD_LIBRARY_PATH variable with:
  • (if needs be) Get rid of OpenJDK and install the official Sun/Oracle Java binaries if required.

Know how do all that? Awesome – carry on! Not so sure? Read on! ;-D

Setting the correct JRE location

First up, check if you have Java installed by typing java -version, if it comes up with something like the below, then you’re got Java installed, now we just need to find out where:

If you didn’t get anything similar to the above you might want to install the official Oracle Java implementation, which I put together a brief step-by-step for here.

Assuming you have some variety of the Java Virtual Machine (JVM) install, check if your LD_LIBRARY_PATH environment variable is set with:

If it comes up empty, then we need to find out where Java’s installed and set it correctly. To get the correct path for where your particular Java install is located, you might be tempted to try running which java:

However, this is a little bit of a fib, as Java is part of the alternatives setup where we can have multiple versions installed at once – which means that /usr/bin/java is really a symbolic link to the true java location. To find where it’s really pointing we can either ask update-alternatives how it’s configured like so (and pick a version different version if we want to):

Or we can look closely at the /usr/bin/java symlink:

Which if we then look closely at /etc/alternatives/java then points at:

Same thing as what the alternatives config’s pointing at ;-)

Now that we have the correct path, we can set it in the following manner (remember to substitute your particular Java location into the below lines!):

For 64-bit Linux:

For 32-bit Linux:

With that done, you should be able to see that it’s set by running:

Which should give you something like:

Finally, we should be fit to launch Minecraft like this (assuming the minecraft.jar file is in your home folder):

Or, without setting the memory and classpath variables, like this:

Be aware that the LD_LIBRARY path will only be set for the current session of the current shell, so you’ll have to re-set it a lot. A quick and easy way to do this is to just knock together a quick launcher script as below (substituting your paths in) and throw it in /usr/local/bin:

Final Notes

Not being able to set a persistent LD_LIBRARY_PATH is a pain, because it won’t take if set in the ~/.profile or ~/.bash_profile or ~/.bash_rc config files (I’m not so sure about ~/.pam_environment) – which you can read about here:

There’s a fix which involves disabling ssh-agent in this bug report (see post #21 here), but really for the sake of a two line launcher script I think it’s best to just leave it be.

Happy mining and crafting! =D