Thursday, January 30, 2014

Adventures in Arch: Part 3 - What the GNOME?

A Choice

In my previous Adventures in Arch post, I mentioned that I was using XFCE. Because XFCE is cool. However, XFCE got its fame for being a ‘lightweight’ distro, and I had originally chosen it to reduce my CPU load. After noticing, however, that my CPU temperature was roughly the same on XFCE and on Ubuntu, I decided to take Gnome 3 for a spin.

First Impressions

First impressions of Gnome 3 were rather good. It certainly was not lacking in the eye-candy department, and, in terms of appearance, was probably the least Windows-looking DE/OS out there. That's a good thing, by the way – if interface design went the way of GNOME 3, I certainly wouldn't have any problems with that.

But Then, Problems

After using GNOME 3 for a few hours, however, the real problems started becoming evident.

The first major problem I encountered was with Evolution, the GNOME mail client. (While not being an integral part of GNOME, I'll cover it here anyway as part of the ‘GNOME experience’.) I'd intended to switch from my existing email client, Mozilla Thunderbird, to Evolution, as web searches revealed that Evolution had support for calendars, while Thunderbird did not, natively. (I later discovered that Thunderbird actually did have calendar functionality, through the use of extensions)

The inital setup experience was comparatively simple. I add my 2 accounts without any problems at all. But then I went to set up my school email account, also hosted on Google's servers, but using a different email address. I added one of my spare GMail accounts, and changed the username to point to my school email.

When the dialog popped up to enter my password. I typed it in. And it didn't work, complaining that the password was incorrect and asking again. I typed it in again. It didn't work. I thought that, perhaps, I'd got my password wrong, and wanted to check by logging into GMail in Chrome. The password input dialog, however, locked out all other programs, so I had to click ‘cancel’ to go into Chrome. Unsurprisingly, logging in with the same password in Chrome worked perfectly fine.

So I went back into Evolution and clicked ‘Get Mail’. Nothing happened. Clicked again. Nothing happened. ‘Fetching mail for (cancelled)’ appeared in the status bar for a moment, but nothing happened. Thus, following conventional technological troubleshooting methods, I quit and reopened Evolution. The password dialog popped up, I typed my password in, and as if by magic, everything worked! All my emails began syncing.

Now it was time for my Google Calendar, also on my school email. I followed all the steps, and it asked for the password. I typed the password in. Incorrect password. *facedesk*

Successive restarts were unable to resolve the problem, so I eventually just uninstalled Evolution, reinstalled Thunderbird and got the Google Calendar add-in. Surprise, surprise, it worked perfectly.


Having gotten Thunderbird working, the next step was to get it to minimize to the system tray. (I don't want to see it in my Activities menu!) This functionality was already set up and worked perfectly in XFCE. GNOME 3, however, by default possessed no system tray. I enabled TopIcons in Gnome Tweak Tool, and also got a sensors extension to monitor my CPU temperature.

The problem now, however, was that the system tray and the CPU temperature were in the wrong order on the panel, so I tried to move them. Click and drag, surely that would work? Left click, right click, middle click, all did nothing. {alt,super,fn,control,shift}+{left,middle,right}click, nothing worked.

After a bit of Googling, I discovered that the only solution to this simple problem was to manually load the extensions in a certain order. Every time.

Power Management and Settings

The next step in attempting to configure GNOME was to get it to blank the screen after 5 minutes, lock screen after a further minute, and suspend to RAM (and lock screen) when the lid of the laptop is closed. In XFCE, this would be simple: everything would be in Settings. But not in GNOME!

The settings for XScreenSaver and/or gnome-screensaver were non-existent. I had to configure XScreenSaver by running the obscure console command xscreensaver-demo. A Settings option for adding it to the startup list was also nowhere to be found other than the also obscure console command gnome-session-preferences. Even using this, locking and suspending was glitchy and horrible.

Power settings for when the laptop lid is closed also did not exist, even in Gnome Tweak Tools, where there was a heading ‘When Laptop Lid is Closed’, but no items under said heading. I simply had to work around this by manually suspending the system before closing the lid.

Smells Like…

Now, there may well be an extension or a magic button to fix all of my issues, but I couldn't find it. And coming from XFCE, where I found everything to ‘just work’, a Desktop Environment where everything ‘just doesn't work’ is simply not acceptable, especially for a product from the likes of GNOME.

Attempting tasks I would have used the XFCE Settings for required Googling, command line hackery and trawling through dconf-editor, and even then still didn't work as well as XFCE.

You know what that reminds me of? A kind of even-worse-than-Vista Windows. Being unable to do anything while a password prompt was active? That's just UAC… Moving system tray/panel icons? Even Windows can do that. And using dconf-editor was basically just like editing the registry.

GNOME 2 used to be the shit! Ubuntu 8.04, those were the times! But now? GNOME 3 is just shit. Oh, how the mighty have fallen…

It's back to XFCE for me. It's smaller, more lightweight, and actually works.

Labels: , , , , , , ,

Sunday, January 5, 2014

GUIDE: Easier League of Legends Installation Using PlayOnLinux


PlayOnLinux is a brilliant wrapper for WINE, allowing for the easy installation of innumerable Windows programs on Linux. Of these, my most recent install was League of Legends, which, of course, does not have a native Linux release. PlayOnLinux installs and runs it perfectly, however the default install method is ridiculous, in that it requires the download of an outdated 3GB install (from PlayOnLinux's agonizingly slow servers, nonetheless), followed by a 3GB patch to make the install up-to-date. This guide will allow you to skip the first download, halving the download size and allowing you to download straight from LoL's servers.


You need to have PlayOnLinux installed to follow this guide. Google it.


  1. Download the correct League of Legends single file setup (not the installer found on the main website!) from the links below. If your region is not listed, download any one of them and select the correct region when patching.
    1. North America:
    2. Europe West:
    3. Europe Nordic and East:
  2. Start PlayOnLinux and click the Install button.
  3. Click the checkbox next to Include Testing.
  4. Type League of Legends into the search bar, select League of Legends from the list and click Install.
  5. When asked to ‘choose an installation method’, select Use a setup file in my computer.
  6. Select the setup file you downloaded earlier.
  7. Click through the rest of the installation process as you normally would.
That's it! You have now installed League of Legends on PlayOnLinux without having to download a massive useless 3GB tarball from the PoL website!

Labels: , , , , ,

Thursday, January 2, 2014

Adventures in Arch: Part 2 - Is It Working Yet?

Let's Get Some Hybrid Graphics Up In Here!

if [ ! -f /etc/X11/xorg.conf ]; then
        sudo cp /etc/X11/xorg.conf.fglrx /etc/X11/xorg.conf
startx /usr/bin/openbox-session -- :1
How simple was that? And my script for starting X on my integrated card is about the same (only using XFCE, because XFCE is cool).


Everything finally works! I can play games on my discrete card, and I can browse the internet on my integrated card without the temperature going up to 90°! Only that's the problem – I can't. Even when working on my integrated card, the system often goes up to 89°-ish. The worst time was when my computer was idle, and then suddenly crashed because of a ‘Thermal Shutdown’. A bit of Googling later, I found the reason was that the discrete card was still running even though it wasn't running… The solution? Use acpi_call-git and turn the card off! And get this – it actually works! Ish.

I found that switching the AMD card on or off when the computer had just booted up worked successfully. However, if I switched the card off, worked on the integrated card for a while, and attempted to switch the card on, the whole system would semi-crash. All keyboard input and mouse clicking would be unresponsive, however moving the mouse around still moved the cursor. If I did this from a tty, I would get a beautiful wall of text about dereferencing NULL pointers or something.

Eventually, after searching in the most unexpected place – information for Nvidia cards that I stumbled upon for a completely unrelated reason – I found the issue: if the card is disabled when suspending to RAM, it stops working. This also appeared to be the case when locking the screen or turning off the display.

Because turning off all the problem-causing things seemed to be a little too much work, I gave up and just left the card running. My workaround was to shove a book underneath the laptop. Ventilation, you know!


After testing out bumblebee-amd-hacks on GitHub, and discovering that it did not work at all for me, I discovered the pxp_switch_catalyst command, bundled with AMD Catalyst for Arch Linux. By making the necessary modifications to my switching scripts, I was now able to use hardware acceleration on my integrated card.

My Switching Scripts

$ cat /usr/local/bin/fglrxoff
if [ -f /etc/X11/xorg.conf ]; then
    sudo rm /etc/X11/xorg.conf
    echo Using Intel driver
    echo Already using Intel driver

LIB_LINK="`readlink /usr/lib/catalystpxp/ 2>/dev/null`"
if [[ "${LIB_LINK}" = "/usr/lib/" ||  "${LIB_LINK}" = "/usr/lib/" || "${LIB_LINK}" = "/usr/lib/" ]]; then
    echo Already using Intel OpenGL
    sudo /usr/lib/fglrx/switchlibGL intel >/dev/null
    sudo /usr/lib/fglrx/switchlibglx intel >/dev/null
    echo Switched to Intel OpenGL

startx -- :0 vt7
$ cat /usr/local/bin/fglrxoff
if [ -f /etc/X11/xorg.conf ]; then
    echo Already using AMD driver
    sudo cp /etc/X11/xorg.conf.fglrx /etc/X11/xorg.conf
    echo Switched to AMD driver

LIB_LINK="`readlink /usr/lib/catalystpxp/ 2>/dev/null`"
if [[ "${LIB_LINK}" = "/usr/lib/" ||  "${LIB_LINK}" = "/usr/lib/" || "${LIB_LINK}" = "/usr/lib/" ]]; then
    #Using Intel
    #sudo pxp_switch_catalyst amd
    sudo /usr/lib/fglrx/switchlibGL amd
    sudo /usr/lib/fglrx/switchlibglx amd
    echo Switched to AMD OpenGL
    #Using AMD
    echo Already using AMD OpenGL

startx /usr/bin/openbox-session -- :1 vt8
/etc/X11/xorg.conf.fglrx is the xorg.conf file generated by aticonfig --initial.

Postscript: Oh Steam…

So, after all this work, I finally had a set-up I was happy with! ‘Shirt off, pants off, time to Dotes!’

Labels: , , , , , , , ,

FIX: Crash when using acpi_call with AMD discrete graphics card

Issue Description

Using acpi_call to disable and enable AMD discrete graphics card sometimes causes system to crash. Problem does not occur with a simple ‘disable card, enable card, run X’ test, but does sometimes occur if a period of time (in which the computer is used normally) is left before disabling and enabling the card.

Error Message

Upon running the X server, the computer crashes with a large wall of text, the first line of which being ‘Unable to handle NULL pointer dereference at 0000…034’ and many references to fglrx.

Cause of Issue

The cause of this issue is that before enabling the graphics card and running X, the computer has been suspended and un-suspended at least once while the discrete graphics card was disabled.


The solution to the issue is to ensure that the AMD graphics card is enabled before suspending. The card can then be disabled again after resuming and toggled normally.