last modified: Thursday 29 September 2016 (UTC)
author: Hales
markup: textile

Snow Notes


There are many quirks when using Linux on a Samsung series 2 Chromebook (aka "snow" or "XE303"). Much of the way the system is setup by default is inconvenient. This document lists several things I have done to make my experience better.

My setup

OS: Arch Linux ARM

State of my hardware: see this blog post

Init system: custom, home-made


I have written a collection of scripts and programs specifically for snow chromebooks:


These tools are covered in the sections that follow.


Backlight brightness

The backlight control file provided by the kernel has restrictive permisions by default. The ALARM installation instructions recommend fixing this using a tmpfiles.d entry, however I fix this instead with my own init scripts:

chgrp video $backlight
chmod g+rw  $backlight

For users of desktop environments (eg KDE, Xfce, LXDE) you may find a brightness applet or tray icon that works well for you. I'm not using such a system, so I threw together a tool I call snowbright to change backlight brightness (part of snowtools.tar.gz).

Usage:  snowbright [up|down|number in range 0-2800]

'up' doubles the current brightness value, 'down' halves it. The actual change in brightness vs the change in numerical value set by the kernel is non-linear, so this works out well. Run the tool without and arguments to get the current brightness value.

Minimum brightness is 0 (backlight off, sometimes usable) and maximum is 2800 (feeble candle mode).

Alsa and volume control

There are many toggles in alsamixer for routing the internal channels to different outputs. You will need to un-mute the following for sound to work as most people expect:

I recommend running 'alsactl store' after performing this so that you don't have to redo it. Systemd may or may not do this by default when you shutdown, I do not recall. In my init I specifically run 'alsactl -L restore' on boot.

Often I used to switch between using internal speakers and external headphones. In my window manager I have one key shortcut to increase the volume, one to decrease the volume and another to switch between the two outputs. This is all handled by the script rexvol in snowtools.tar.gz

Usage:  rexvol [up|down|switch]

The 'switching between outputs' doubles as a mute function if you do not have your headphones plugged in.

Handling 'debug' in the kernel command line

This is the reason that kernel messages constantly appear in your virtual terminals. This is extremely annoying.

The ALARM installation instructions (linux-snow era) used to get you to setup a copy of u-boot in a partition of its own. You could control this bootloader and change its settings, thus allowing you to remove the 'debug' kernel command line option and gain some semblance of sanity when working at virtual terminals.

The current instructions (linux-peach era) no longer get you to do this. I'm not sure if the command line arguments are compiled into the kernel or provided by the locked-up google bootloader. Luckily I have found a way of changing the kernel verbosity at runtime:

echo 1 > /proc/sus/kernel/printk

Systemd itself may still want to spew messages: it may have some configurables to fix this.

Stopping the laptop randomly waking up in your bag

The snow chromebook has a very flexible body. I found that it would turn itself on when being carried in my school bag.

By default any touchpad or keyboard event will wake the laptop out of suspend. To stop this:

# Touchpad
echo 'disabled' > '/sys/devices/12c70000.i2c/i2c-1/1-0067/power/wakeup'
# Keyboard (power button is considered separate)
echo 'disabled' > '/sys/devices/12ca0000.i2c/i2c-4/i2c-104/104-001e/power/wakeup'

If you are told that these directories do not exist, then your i2c addresses may be different to mine. Try 'find /sys/devices -name wakeup' to find them. Tell me if you have to do this so that I can edit these instructions.

Now the only ways to wake your computer from sleep are to raise the lid or press the power button. Making this change has completely nullified the problem of the laptop starting in my bag.

For systemd users: you should be able to add this to a tmpfiles.d file.

Touchpad customisation

There are different drivers for the touchpad available in Xorg. As recommended by the ALARM instructions I suggest changing the defaults. This config works well for me:

# /etc/X11/xorg.conf.d/50-touchpad.conf

Section "InputClass"
	Identifier "touchpad"
	Driver "synaptics"
	MatchIsTouchpad "on"
	Option "FingerLow" "5"
	Option "FingerHigh" "5"
	Option "SingleTapTimeout" "5"

This provides the following setup:

The last point is important: disabling this feature gets rid of the horrible artificial delay every time you single-tap (left-click equivalent) the touchpad. By default the laptop waits to see if you tap again during this period. Blargh.

I missed this feature, but it was worth it. Instead you can perform 'click and drag' functionality by clicking the physical left button under the touchpad with one hand and using your other hand to move the cursor.

I also add a 'HorizTwoFingerScroll' line to my conf file, but this does not suit everyone.

Reducing impact of the 'press space to wipe your chromebook' developer mode scare screen

Once your snow chromebook is in developer mode you will have to live with the horrible bootloader message tempting people to wipe your computer every time it boots.

I recommend changing the default language (using the arrow keys) so that would-be villains can't follow the prompts. Many users will blindly follow prompts.

For the more adventurous: you can modify some flags in the bootloader that reduce the display time of this message from 30 seconds down to about 2 seconds. This also neuters the annoying beep noises if you are too slow.

Full instructions can be found on various websites across the web, such as this one.

Important catches:

This modification has worked for me, however I'm not sure if it will work for you. Approach with caution.

Locking up and crashing during heavy disk I/O (eg updating)

I believe this is caused by the system running out of memory. Linux caches writes to disk, so if you suddenly want to write lots of data (eg you are pacman -Su'ing) then the kernel pretends the operation has finished by keeping the changes in RAM and continuing to write them over a longer period of time.

This problem did not initially exist on my snow chromebook: I suspect the flash memory has degraded and slowed down over time. Now writing several hundred meg of updates takes longer.

Symptoms of the problem: computer starts to freeze for short periods of time, then completely locks up.

Effects of the problem: leaves filesystem in inconsistent state. I had a whole bunch of system libraries zeroed out a couple of times because the device crashed during an update to them.

I'm not entirely sure but I think this fixed the problem: EDIT 2016-09-29: no it has not

# Tell the kernel to reserve 50M of space for handling OOM
echo 50000 > /proc/sys/vm/min_free_kbytes

If you are suffering this problem: immediately suspend the guilty process (by pressing Ctrl+Z on the terminal it is running in). Run the 'sync' command somewhere and wait for it to finish, then resume the process again.

Reading battery charge

For a long time the 'acpi' tool reported that it could detect zero power draw when my laptop was running on battery. I'm not sure if this has been fixed now, but it triggered me to write my own battery utility: snowbat

Usage: snowbat

Output information includes the current power draw (positive for charging, negative for on battery) and actual percentage capacity (not adjusted).

I'm sure the actual power draw readings are inaccurate but they are useful as relative measurements to observe the effects of CPU load and screen brightness. I had to guess the amount of decimal places in the result: something in the magnitude of 3W makes sense.

Normally battery capacities are adjusted so that 100% represents 'fully charged' even if the overall battery capacity has degraded. I have opted instead for a 'fixed' 100% reference point. New snow chromebooks may report charge levels above 100%: this is fine, it just means the battery is better than the firmware has specced it to be. My battery won't charge above about 75% at the moment (laptop is a bit over two years old).

Graphics drivers

I believe the Mali graphics drivers are closed source and difficult/impossible to get running. I've been using fbturbo. It's not perfect (everything is software rendered) but hey, it works.

If anyone has found a way to get better graphics drivers working, please do share :P

Interesting note: I have found that SDL2 'software' rendering is faster that 'hardware' rendering by several magnitudes. Whatever the draw methods are, the fastest way for programs to operate in this graphics environment is to do all of their drawing internally and throw only one draw to screen per frame.

Watching videos

'mpv' has support for an output method called 'X11'. I've found this to be the best way to watch videos on this platform (and it supports youtube URLs).

At one point the mpv devs removed support for this output method. Luckily for us this affected more than just our niche: other users needed it too. The changes were reverted however I am unsure if the performance is as good as it used to be (TODO: run some tests).

This is the configuration I use in my .config/mpv/mpv.conf file:


The 'drm' vo mode also works, but has some disadvantages:
* takes over your whole screen (cannot run windowed)
* does not display over HDMI

'sws-scaler' stands for 'software scaling' (ie resizing). Software (non-accelerated) scaling of video is computationally costly, especially when using the default algorithms. 'fast-bilinear' is fast enough to make scaling 720p youtube videos bearable, but you will still drop frames, so I highly suggest watching the videos without resising the mpv window.

There are some other scaling algorithms (try mpv --sws-scaler=help), but these are either perform very poorly or are extremely ugly (eg the 'point' scaler).

Adobe Flash

Chromium + pepper is your only option. I'm not sure if this is still around, I have not used it for a couple of years.

i3 window manager

(For those that use i3wm)

To match the markings on the keyboard and the scripts in snowtools.tar.gz:

# Functions across top of keyboard
bindsym control+F6  exec --no-startup-id "snowbright down"
bindsym control+F7  exec --no-startup-id "snowbright up"
bindsym control+F8  exec --no-startup-id "rexvol switch"
bindsym control+F9  exec --no-startup-id "rexvol down"
bindsym control+F10 exec --no-startup-id "rexvol up"

Showing only the non-muted volume outputs in i3status:

volume headphone {
	format = "Head: %volume"
	format_muted = ""
	mixer = "Headphone"

volume speaker {
	format = "Speaker: %volume"
	format_muted = ""
	mixer = "Speaker"

Ending notes

Have any of these tips worked for you? Do you have any others? Comment below. Especially if you need a hand or if I have made some mistakes.

No one has commented on this page yet.

Add your own comment:

Email (optional):
URL (optional):
Enter the word 'irrlicht' (antispam):
Do not enter anything into this box (antispam)

Comment (plaintext only):

If you provide an email address: it won't be made public. I'll only use it to contact you regarding your comment. No spam, mailing lists, etc.

If you provide a URL then your username will hyperlink to it.