Home | Rules and About | Atom feed
Admin | Edit
published: Saturday 27 February 2016
modified: Monday 1 April 2019
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'

Note: The paths above are probably different on your machine, due to different kernel versions and/or possible variations in i2c addresses. To find yours try running:

find /sys/devices -name wakeup

EDIT 2019: Thankyou sphygmus for reporting how your paths are different. If any other readers come across variations then please post them, I'll add them to the list

/sys/devices/12c70000.i2c/i2c-1/1-0067/power/wakeup              (Hales    2016)
/sys/devices/platform/soc/12c70000.i2c/i2c-1/1-0067/power/wakeup (sphygmus 2019)

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.

sphygmus - website - Sunday 31 March 2019

Hey Hales!

Just wanted to say thank you so much for posting all of this; multiple bits and pieces of it were useful for me as I went through the process of installing Arch on my Samsung XE303C12.

You did say to mention if we had a different i2c device -- I was able to find mine with the instructions you posted, and it's:


My backlight files were also in a different place, so I wrote my own script to handle that, based on your own.

(Also your blog is awesome :D)

Hales - (site author) - Monday 1 April 2019

Hello sphygmus,

> thank you so much for posting all of this
> (Also your blog is awesome :D)

Your gratitude has been noted on your permanent record. You now have -298 Citizen Point(s). At +0 Citizen Point(s) you will be permitted lucidity and allowed to leave the library.

Society appreciates the contributions you are making whilst unconscious.


Thanks for the i2c address info, I'll update this page. I really miss my snow and wish I could still be using it, even for something simple like a low-power server that'd give it some respect. Alas the dead BGA flash is a beyond my comfortable repair envelope. Right now I'm on an 11.6" dell x86 laptop that (surprisingly) has almost as any issues as my snow did, and it weighs more doing it.

I also need to fix a few other things on this site. URL links in people's comments, for example, are broken and taking people to a cleverly named parked domain. Unfortunately my webhost has completely locked me out of the backend, and I'm multiple messages deep into a support ticket where it looks like they have no clue how to fix it :(

> * install hales' tools:
> ** `curl -O http://halestrom.net/darksleep/snow/snowtools.tar.gz`
> ** `tar -xf snowtools.tar.gz`
> ** `mv snowtools/rexvol ~/.local/bin/rexvol`
> ** `mv snowtools/snowbat ~/.local/bin/snowbat`

Muahaha, now I can swap that archive out for something filled with demons >:)

On a more serious note: please don't trust other people to store data that you care about. Put a local copy of that archive on your website, even if it's just to provide an alternative link to. I care about my site and want to keep it online for as long as I can, and I'm allergic to the notion of breaking any URLs like many sites do on a regular basis, but I'm still fallible and if I disappear then your site/guide will suffer.

On the topic of websites: yours is the first tiddlywiki instance I've seen up on the web. It's an interesting concept -- I presume you edit it offline and then simply upload the single file to update your whole site? Or is there some interactive component with your webserver so you do it differently? Is it convenient and/or fun to use; or a nightmare of problems?

If you want some website feedback:

(1) Printing your website is really hard. I can't reveal more than one thing at a time, which really seems silly given that you site is literally "everything on a single page" behind the scenes. I think this is a missed opportunity here.

Disabling CSS somewhat works, but it reveals a non-marked up version of the site. I'm hazarding a guess that the javascript does all of the work turning the tiddly-markup into HTML.

(2) Your site is slow :D

Surprisingly it doesn't seem to be the main 5.7MiB page that does it, that part only takes ~850ms for me to download in Australia. Fetching the favicon however seems to take almost 4 seconds. I'm not sure what's going on here, maybe it's a red herring in the performance data caused by other things happening concurrently.

This is the second time I've written this comment. The first time I accidentally hit 'back' in Firefox and (for the first time in a long time) Firefox didn't save the form contents. Let's hope things work better this time.

Regards, Hales

sphygmus - Thursday 11 April 2019

Hi Hales!

Library of Babel is a rabbithole - it would be fascinating to find a full page of text in there, but I don't have the time to click on that many pages...

I'm sorry to hear that your snow died! I'm SO extremely pleased with mine now that I've got Arch on it; it's gone from "laggy youtube machine" to "learning how to program-ish" machine -- plus it feels much snappier. and I hope you get things figured out with your webhost - that sounds like a pain in the arse.

Thanks for the reminder about backing up the archive myself! I need to get on that for sure. If I were being the proper amount of paranoid, I would make sure there were wayback machine crawls for every page I linked to, too. Arg!

> It's an interesting concept -- I presume you edit it offline and then simply upload the single file to update your whole site? Or is there some interactive component with your webserver so you do it differently? Is it convenient and/or fun to use; or a nightmare of problems?

Oh, you are in for a treat. I actually started my wiki after encountering h0p3's tiddlywiki at https://philosopher.life -- if you thought my wiki took a long time to load, be warned that his will take even longer. It's definitely worth the load time and bandwidth at least once, though. There's a tiny group of about 5 others who also have tiddlywikis up on the web, all pretty recent, and generally inspired by h0p3/each other.

Re: implementation, I'm not using the single-file version; there's a node.js version that I've got on a DigitalOcean droplet behind an nginx proxy & some authentication. I can log in and edit it from anywhere, which was my main goal. Being able to edit anywhere makes it much more convenient to use; I'm often referencing it on my phone or other computers from various places. I've been slacking on journaling in it, but it's worth the while for me even when I'm just putting project documentation in it.

Publishing it publicly is slightly more of a nightmare than convenient. Right now I symlink the "public" files from my main wiki to another node.js instance, which then gets built into a single file, slightly sanitized, then rsynced to my sphygm.us server nightly. Symlinking-to-make-public is increasingly annoying, so I may change that at some point.

Thanks for the feedback!! I really never expected anyone other than a couple people to see my wiki when I made it, but it's been a good experience connecting with people through it.

I'm really not sure how printing a tiddlywiki even works - I haven't actually tried. You can reveal more than one tiddler at a time in the story river, just by clicking multiple links, but I'm not sure that's what you meant? Personally I don't care about the advantages of single file tiddlywiki and if I could serve my tiddlers as a static site with generally the same functionality & navigation etc, I would. There's not really any good resources for converting the .tid files (really just plain text) to a static site and preserving the organization/display/etc ... but given the amount of static site generators & the possibilities of writing my own, it's another thing on the someday-to-do list.

yeeeuuup the slowness is the biggest annoyance with tiddlywiki. If I were serving it off my node.js server, rather than the single-file, it would probably be snappier - at least then I could implement the lazy-loaded tiddler feature they've got build in, and that would help a bit.


ANYWAY I was going to post a brief comment but then decided to reply to the whole thing rather than procrastinate on it for another day -- although now I feel like I've written a full-length letter in your comment section.

BASICALLY I've been setting up i3pystatus on my snow and their wattage consumption calculation doesn't handle negative values from CURRENT_NOW in uevent, while your snowbat tool //does//. I'm an electricity n00b though and was hoping you could provide some clarification on what the values mean. My current guesses are:

- negative watts reported from snowbat means that much power is being drawn from the battery at that moment
- positive watts reported from snowbat means that much power is being put into the battery at that moment ??? <- where I'm confused

thanks so much - cheers! sphygmus

Hales - Saturday 13 April 2019

Hello sphygmus,

Current and voltage measurements are implementation specific. My current laptop, for example, always reports a positive current regardless of what it's doing. The measurements are typically supposed to be taken "at the battery" rather than at the jack or at "the load", but I'm sure even that varies in some laptops.

* Positive current and power means energy is flowing out of your battery (discharge)
* Negative current and power means energy is flowing into your battery (charge)

(I might have it backwards. You say it's the other way and it has been a while since I used my snow.)

When you have a charger plugged in your laptop your battery is no longer providing current to run things. Instead the charger's current is both charging your battery and powering your laptop's rails directly. I'll hedge this with "in most designs", I'm sure there are designs where if you remove the battery the laptop won't run, but for the vast majority of laptops the battery is optional.

To explain in a different way: there are three vague main components of a laptop's internal power system:
* Jack input
* Battery
* Load
All three of these things can get power from each other (in even weirder ways too if you have USB C for a jack input/output). There are an infinite number of places to measure voltage and current, and an infinite number of conventions they can then follow regarding + and - signs.

> You can reveal more than one tiddler at a time in the story river, just by clicking multiple links, but I'm not sure that's what you meant?

Aha, you're right. I thought it was collapsing/hiding old tiddlers when I did this, but it actually keeps them.

> https://philosopher.life

What rabbit hole are you ensnaring me in now? Stop this at once! I have chores to do.

Whilst we're sharing links: http://www.autofish.net/ has given me a lot over the years. I wish my website was more like Autofish, with little bits of raster art everywhere.

> *site implementation details*

Hmm, sounds a little complicated for what's supposed to be a 'tiddly' wiki :P. If what you have works and you like it, then keep it and don't listen to anyone who says otherwise.

When I tried out a whole bunch of site backends/engines I was really disappointed by how many of the 'tiny' backends were not. One in particular required _hundreds_ of megabytes of perl dependencies. That was eye-opening.

I don't know if you've read some of my earlier meta-articles on this site talking about how it's implemented and why I did it, but to summarise:

Selling points:
* Pages are statically generated
* Dependencies: only bash and a webserver that supports CGI (lighttpd, apache, hiawatha, etc) + _optional_ external markup generators (textile, markdown, wikitext, bbcode, etc)
* Whole site fits in one folder + some permanent, external symlinks
* Each page has a field to specify markup format
* One markup format is "script", which means "run this page as a program and save its output as the .html"
* (Next version, to be released): All security/auth done via HTTP_AUTH
* (Next version, to be released): Optional self-integrated WYSIWYG editor with drag+drop image support so you don't have to manually upload images. <100 lines of JS integrated, no external deps.

This means:
* All interactivity (including comments) can be disabled intentionally or break unintentionally and the site still stays up.
* Load speeds beat the pants of all fancy modern frameworks.
* I can use any language or slow method to generate the pages I want.
* Moving the site to other hosts is dead easy. Everything except for a few permanent symlinks is self-contained.
* I don't have to update any critical/security components on a regular basis, there's no big farm of dependencies to attack.
* Easter eggs
* Custom auto-generated pages (like the front index of this site) are pages with markup=script set. Instead of writing a page I write a shell script that does the work for me. The 'markup' process is running that script instead of running an external markup program.

> If I were serving it off my node.js server, rather than the single-file, it would probably be snappier

*sees the word "snappy" and "js" in the same sentence* :D

If you plan to modify or replace your site backend then my biggest thoughts would be to how you conceptualise pages. At the moment your tiddlers are more of headings than pages, so you probably wouldn't want to turn each one into its own page. Instead you'd probably want to keep the "everything" or "most things" on one page model, with lots of #navigation. Hiding and revealing things with javascript could be kept if desired, to avoid scaring people away from massive pages.

Apologies if I've missed things, I'm a bit under the weather at the moment.

Add your own comment:

Email (optional):
URL (optional):
Enter the word 'irrlicht' (antispam):
Leave this box blank (antispam):

Comment (plaintext only):

If you provide an email address: it will only be used for the site admin to contact you, it will not be made public.

If you provide a URL: your name will hyperlink to it.