Broken Gnome 3.10 on Arch Linux (grey screen with working cursor)

I recently had some trouble upgrading to Gnome 3.10 on Arch Linux.  After running # pacman -Syu and rebooting, Gnome booted to a grey screen with a functioning cursor but nothing else. This grey screen happened when starting GDM and also when using startx to run Gnome manually. I was fairly perplexed and switched to Slim+Xfce4 for a few days until I had a chance to figure it out.

Attempting to debug, I looked at the systemd status for trying to start GDM like so:

$ systemctl status gdm

The status showed an error with some text “failed to give slave programs access to the display”.

After digging around in the logs in /var/log, I found some locale-related errors during the startup of both GDM and Gnome shell. I had previously had locale issues on my system, which I think originally stemmed from using the en_GB.UTF-8 locale for installation and later moving to en_US.UTF-8 (likely screwing something up along the way). In /etc/locale.gen, I found that I had the following uncommented:

en_US.UTF-8 UTF-8
en_US ISO-8859-1

Commenting out the ISO line, running # locale-gen and rebooting apparently fixed the locale issue with Gnome 3.10, allowing me to boot into GDM and Gnome shell. However, without the ISO line, I found that I started getting the following warning at the beginning of every terminal login:

bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory

This had other effects, such making the Gnome terminal think that the current locale was “ANSIX3.4-1968″ (which subsequently breaks UTF-8 characters in the terminal). In /var/log/user.log, I found the following:

user.log:Oct 20 00:06:07 localhost gnome-session[642]: Using the fallback 'C' locale.
user.log:Oct 20 00:06:10 localhost gnome-session[642]: /bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US)

So, something was trying to set LC_ALL=en_US, which is not a full locale specification as far as I can tell. I checked the standard places, including /etc/locale.gen, /etc/locale.conf, ~/.bashrc, and everything in /etc/profile.d/ for possible bad settings. Everything looked normal, so I had to do more digging.

At some point, I came across a references to file /etc/environment, which is something I have no recollection of ever touching. Yet, inside was a single uncommented line:


And there we have it. This file, which is apparently parsed by the pam_env module, sets up some initial environment variables. It appears that this variable being set was making it impossible for correct, existing locales to be found on the system, and was causing gnome-session to go to the fallback locale since “en_US” was not valid.

Commenting out the offending line in /etc/environment appears to have fixed my problems, and Gnome 3.10 now works beautifully.

Greyed Serial Port Menu in Arduino IDE on Arch Linux

Related to my Lucid Dreaming Mask project, I needed to install the Arduino IDE on my home desktop.  I haven’t used my Arduino since switching to GNU/Linux, so I had not yet bothered installing the IDE.  The easiest way to get Arduino running on Arch Linux is through AUR, with the following command (assuming you already have yaourt installed):

$ yaourt -S arduino

I followed through the routine and it appeared to install correctly. I then added my user to the uucp group to give my user serial USB access. Upon launching the Arduino IDE, I found that the Tools > Serial Port menu was greyed out and I was therefore unable to select a port through which to communicate. This is clearly a permissions problem, since the Serial Port menu worked fine if I ran the IDE as root.

It turns out that the problem is with permissions on the /run/lock directory, which is owned by root:root with 755 permissions. That is, only root has permission to write to the directory, whereas the Arduino IDE requires that for whichever user is running the IDE. The quickest fix would be:

# chmod 777 /run/lock

That’s fine, but it also leaves the directory open to any user. In case there’s a good reason for having permissions locked up, here’s what I actually did:

# chown root:wheel /run/lock
# chmod 775 /run/lock

The first line changes the group to which the directory belongs, so that users which are in the wheel group can access it. The second line changes the group permissions to allow users from the wheel group to have full privileges in /run/lock. Everything seems to run perfectly now.

Construction of a Lucid Dreaming Mask [part 1]

Inspired by the Remee post on Kickstarter but not inclined to wait until July (the estimated ship date) to get one, I’ve decided to construct my own. This is the first in a series of posts detailing my effort. I put together a simple design and ordered the parts for it yesterday, so this post will be an outline of what parts I chose, how I intend to layout the electronics, and more. Note that the Remee folks have pledged to make a DIY tutorial available, like this one, which I’m sure will be more accurate, cost-efficient, and all-around a better product. This is a simple implementation with only core functionality in mind.

I don’t have much of a history with lucid dreaming, so this is very much an experiment on my part. I have lucid dreamed probably only a handful of times in my life, and all experiences were incredible. I don’t have any real control over making them happen, though I also haven’t made any serious attempt to gain control. I hope that this mask makes things easier for me.

To keep things easy, I’ve decided to use a LilyPad Arduino and stick to LilyPad components that have been designed for use with clothing and other textiles. The plan is to use the LilyPad with an ATmega328 chips as the controller for a set of five red LEDs, sewn into a generic sleeping mask. The ATmega328 is obviously overkill here, but so is pretty much any other chip you can buy. Its power draw is quite low nonetheless, and the form factor of the LilyPad is attractive.

Besides that, there will be a slide on/off switch built into the mask, powered by a 20mm coin cell battery. Conductive thread will be used to connect the components into a circuit. I also have a USB to serial IC converter, which will allow me to easily connect the LilyPad to my computer for easy programming.

I’ve ordered all of my parts from SparkFun Electronics, with links to the parts below:

My total came to $68.50 USD, plus an entirely reasonable shipping and handling of $6.05 USD to my home in Fredericton, Canada.

Below is a simple diagram for how I plan on connecting the components in the mask. Note that the LEDs are connected to pins that support pulse-width modulation (PWM), which will allow for finer control over the brightness of the LEDs. That is, it should be possible to make the LEDs turn on and off slowly and smoothly, which I figure may be important to avoid waking me up.

With respect to the mask itself, I would like it to have a zipper or some sort of snap that allows easy access to the electronics, such that it’s a piece of cake to replace the battery or connect the FTDI for software modifications. So I’ll probably have to put together my own mask too.  I plan on sewing the LEDs to be over only one eye, while the other eye contains all the rest of the electronics.

SparkFun estimates it will take 2-3 weeks for me to get my parts, so the next post probably won’t come until then.

Installing the Motion Control API on Windows XP

I wrote a document about how to do this before I started this blog, so I’m posting a PDF version of it here. The document abstract is as follows:

This document explains how to configure a Windows XP computer to use PMC Corporation’s Motion Control API in order to write custom software to communicate with PMC controllers. The steps described in this document are not necessarily the only way to do this.

Here’s the document itself: mcapi-windows

Installing the Motion Control API on Ubuntu 10.04

While Precision MicroControl Corp. (PMC) claims to fully support Linux with its Motion Control API (MCAPI), I had trouble installing the MCAPI under Ubuntu 10.04 (presumably your version of Ubuntu or flavour of Linux shouldn’t make a difference, but I don’t know and I haven’t tested anything else). Following the standard ./configure and make to configure and build the MCAPI from source, the make process invariably failed part-way through. This problem occurred using version 4.1.2 of the MCAPI, which (as of this posting) is the most current version. Here’s what the error looked like:

/home/bwood/Downloads/mcapi-4.1.2/src/drivers/linux/mcapi_dcx.c: In function
error: implicit declaration of function 'schedule'
make[6]: ***
[/home/bwood/Downloads/mcapi-4.1.2/src/drivers/linux/mcapi_dcx.o] Error
make[5]: ***
[_module_/home/bwood/Downloads/mcapi-4.1.2/src/drivers/linux] Error 2
make[4]: *** [default] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

After spending some scouring the web and asking around on IRC, a bright fellow in ##programming on Freenode helped solve the problem. It turns out that two of the source files mcapi_dcx.c and mcapi_int.c were missing an important #include statement in their headers. The problem is fixed by adding the following to the header of each file:


I’d also like to note that the support team at PMC did eventually respond to my email and recommended the same fix. The source code available in the download from PMC’s website hasn’t yet been updated.