Rescuing Chromebooks from Google with Void Linux

Just some more notes from my experiments with Void Linux, particularly on a converted Chromebook.

I have to first shout out as always the incredible work done by MrChromebox, as installing custom firmware onto your Chromebook to install Linux is the ultimate improvement you can make to your severely restricted device. In order do install it, you will have to disable the write protect on your device.

On modern Chromebooks, this is usually as easy as opening the device and disconnecting the battery, then connecting wall power and running the script in Developer Mode. As always, check compatibility with your device before trying to install the firmware.

Installing Void Linux is about as easy on a ‘liberated’ Chromebook as it is on a normal x86-64 device, but here are some additional notes for things you will have to likely install for everything to feel as good as possible:

[Also, for those already asking yourself ‘Why not Arch?’, in this case, the Chromebook I installed on actually did not recognize the MMC block device that the laptop uses for storage out of the box. I am always happy to get more experience using Void Linux when possible and have Arch on other boxes. Void really feels like an unique and kind of an underdog distro, whereas Arch gets all the adulation.]

Fixing Audio

Yes! Previously this was a real PIA to get working, but is actually relatively straightforward nowadays, using the WeirdTreeThing scripts. Just download and run ./setup-audio – you’ll need python installed, but it probably will already be installed by default.

As a note, these scripts seem to work best on rolling distributions like Void and Arch, because they assume the newest packages and paths for the audio drivers.

Ectool for keyboard backlight

This was a little more difficult on Void, but can be done. The ectool program is an adaptation of the ChromeOS tools, and requires a few steps to get setup (bug me if I left something out here):

sudo xbps-install cmake libusb-devel libftdi1-devel pkg-config
cmake -DCMAKE_POLICY_VERSION_MINIMUM=3.5
make

Then copy src/ectool somewhere useful like /usr/local/bin and you’re ready to use it. I made the following silly little scripts I called kbup and kbdown, Ill put them here for you to look over if you’d rather set them up differently:
(Content warning: lazy bash scripting)

#!/bin/bash
ECTOOL=/usr/local/bin/ectool
PCT=$(${ECTOOL} pwmgetkblight | awk 'END { print $NF }')

if [ ${PCT} -ge 100 ]; then
  echo "Already at max..."
  exit 0
fi
let PCT=${PCT}+20
$ECTOOL pwmsetkblight ${PCT}

and kbdown:

#!/bin/bash
ECTOOL=/usr/local/bin/ectool
PCT=$(${ECTOOL} pwmgetkblight | awk 'END { print $NF }')

if [ ${PCT} -le 0 ]; then
  echo "Already at min..."
  exit 0
fi
let PCT=${PCT}-20
$ECTOOL pwmsetkblight ${PCT}

Could this just be one program? Yes! Doing this is left an an exercise to the reader.

From here it’s just a matter of assigning kbup and kbdown to your preferred keystrokes. In XFCE this is under Settings > Keyboard and click on Application Settings menu to add the entries. Since the brightness up and down keys seem not to be bind-able, I just set mine to be bound to Alt+9 and Alt+0, but do what feels good to you.

For certain devices, disabling Synaptics touchpad config in X11 is necessary

On my Galaxy Chromebook 2 at least, I had to actually disable the Synaptics drive, as it rendered the touchpad mostly insensitive to light taps and clicks. This is as easy as:

cd /usr/share/X11/xorg.conf.d/
rm 70-synaptics.conf
ln -sf /dev/null 70-synaptics.conf

and restarting. You may then need to turn up the touchpad sensitivity to get a good experience, but at least the touchpad is not putting its fingers in its ears when you’re trying to move the mouse pointer.

That’s all for now!