Samsung ARM Chromebook (XE303C) Linux user experience

Asus C201 ARM Chromebook Linux user experience

April 23, 2017
GL, finally
April 7, 2017
Hinges again!
December 9, 2016
My god, this laptop isn't perfect
August 6, 2016
Hinges: the gift that keep on giving
March 22, 2016
Toddler strikes again
February 5, 2016
Progress report
July 28, 2015
A few notes...
June 10, 2015
Asus C201 Review
June 6, 2015
To crouton, or not to crouton?
June 3, 2015
May 7, 2015
February 27, 2015
The bell tolls for hinges
November 9, 2014
Thus passes keyboard
July 28, 2014
Sic transit keyboard
February 5, 2014
Staying power
June 4, 2013
Illustration of systematic development fail
April 5, 2013
Still not perfect
March 21, 2013
A couple more struggles
March 7, 2013
GLES fail
March 4, 2013
armsoc vs. fbdev, kernel build
March 2, 2013
Keyboard fix
March 1, 2013
February 28, 2013
February 27, 2013
Debian config
February 26, 2013
First impressions
February 26, 2013
First impressions

My iBook G4 lasted for 5 years. It fell to a combination of becoming too slow and unsupported for modern web browsing, accumulated hardware damage, and acute disk failure. My Lenovo IdeaPad U150 lasted for 3 years. In fact, it is still going strong -- it is certainly fast enough and up-to-date, and its battery is still good for more than 3 hours, and the software config is "perfect". I have only two complaints about it: its keyboard is "mushy", and it gets ludicrously hot despite making a ton of fan noise. Oh, and it kind of is stupidly shaped because it has a huge off-center battery in the back. It never sits well on anything.

So, I happened across a reviewer calling the Lenovo's keyboard "mushy", and I realized, he doesn't use the word "mushy" to describe every single keyboard he reviews. In fact, words like "joy" make their way into reviews of the Chromebook's keyboard. The Chromebook has ARM processor and so should be cool (it doesn't even have a fan!). And its sleek shape should rest on anything. So I clicked "buy."

It is very thin. When you first pick it up, you can't tell it's a thin plastic box around mostly empty space. But if you try to flex it, it bends a lot. Its LCD is about a quarter inch not-as-wide as the Lenovo's, which is vexing because they have the same specs on paper. The keyboard has a very nice crisp feel, but it is much lower profile than I'm used to, so it will take a little while to get used to it.

It has few LEDs: a stupid LED under the power button in the keyboard, an apparent activity LED by the webcam, and a hidden charging indicator by the power jack. One stupid surplus LED, but only one. That is a big deal to me. Apple laptops have a minimum of LEDs and display them tastefully. My Lenovo, by contrast, has 9 garish LEDs that don't tell me anything of value. 3 are always on, 4 are always off, 1 flashes when it's sleeping, and 1 flashes when it's thinking.

Speaking of Apple-esque innovations, here is something even Apple hasn't caught onto yet: lower-case letters on the keycaps! Neat!

The LCD seems to be the weak point, with apparently awful viewing angles and contrast (even worse than the Lenovo's, which I'd thought of as bad). But I'm not entirely certain I've convinced the chrome OS to display "black" on the screen yet, so we'll see if it grows on me.

The trackpad is probably great, but it basically sucks because it has an acceleration setting that I find unusable, and have not figured out how to change. It is certainly very flimsy-feeling, if that matters.

The big question for me is whether to hack things in on top of ChromeOS (it's X11, right?), or to install Debian on it. Luckily, my Lenovo is not dead yet so I can spend some months figuring that question out.

If I use ChromeOS, at a minimum I want to get NFS, and a decent shell, screen, mplayer, a decent window manager, openvpn, stellarium, etc. Which might not be too hard, really, if ChromeOS doesn't fight me on window management. I hope to be able to simply unpack binaries from Debian for most simple applications, so long as the library dependencies don't become too onerous.

If I use Debian, I have to struggle to track down all the little laptop details like power management (sleeping), trackpad, wifi, audio, GPU (GPU especially worries me -- I'd like for mplayer to be usably fast), and flashplayer (there is no linux-arm flashplayer plugin for firefox, just the proprietary chrome one that comes stock). Plus I abandon whatever neatoness is to be had in ChromeOS.

Anyways, the first impression has me leaning strongly towards Debian! "crosh" (control-alt-T) is an awful shell within a browser tab, which has a truly awful ssh client. There is nothing in ChromeOS that jumps out at me as useful or slick (just "app" versions of all the google goodies you're used to using under Firefox). That's in contrast to Android, which I am absolutely in love with. The trackpad config sucks (though that'd probably be the easiest thing to work around). Oh and did I mention that crosh sucks? Plus the taskbar is just crappy, it is hard to predict what will happen from the various ways to launch an application.

But one thing about the first impression that completely knocked my socks off is keyboard configuration. There is a serious shortage of configurable options on this device, which is to be expected. But out of the box, it let me use Dvorak, and it let me remap the stupid "search" button to "control"!!! That's very important to me, and something the iBook never really achieved.

But then they made up for it by intercepting control-O before it gets to ssh...

But I think the biggest thing is that in a laptop I really know exactly what kind of environment I want. I haven't seriously changed my expectations, UI-wise, from a laptop since about 2003. So the constant-upgrade scenario that Google promises with Chrome OS sounds pretty undesirable to me. At best, it will inadvertently wipe out my customizations. At worst, it will break everything constantly.

Oh and a detail that often goes unremarked is aspect ratio of the bezel stuff. The Lenovo has basically an 0.75" bezel around the whole screen, and that then forms the outer boundary of the laptop. Combined with how the hinge works, it puts the bottom of the screen barely 0.5" above the keyboard. But the Chromebook has a little more bezel below the screen, and the hinge holds it more raised. So the screen is more like 1.5" above the keyboard. It is hard for me to explain what a big difference this makes in the perception of the device. I'm not sure which is ergonomically preferable, but I'm betting it'll turn out to be the higher screen.

Installing Debian

Okay, installing Debian on it. Here are the steps I am following, roughly.

Entered developer mode. Three finger salute (ESC+F3+POWER) brings us to the recovery bootloader, which has a magic control-D to enable development mode.

chrome://imageburner did not work for me, it probably did not like the SD I had. Which is lame, because I had just bought that SD for that sole purpose. But it turns out, you can download a recovery image from a normal computer, and unless you bypass some hard read-only wall, it will always be possible to unbrick your chromebook with one of those. But I did take a backup (tar --one-file-system -cvzf /media/removable/UNTITLED/chromeos-root.tar.gz), so I can harvest proprietary DLLs and so on from it.

I grabbed the debian unstable installer-armhf mx5 netboot uInitrd. It can be extracted as easily as:

$ dd if=uInitrd of=initrd.cpio.gz bs=1 skip=64
$ zcat initrd.cpio.gz | cpio -i

I extracted that into an ext4 partition on an SD card that I configured according to the directions from Andrew Wafaa. Note that I copied over the kernel exactly as he described there. One thing that was not entirely clear to me: the cgpt and vbutil_kernel programs he is suggesting you run are part of Chrome OS, run them on the chromebook (I bothered to build them for my PC from the git repository before I figured this out). I also copied lib/firmware, lib/modules, and boot from Chrome OS. I also downloaded debian armhf packages for net-tools, libc6 (for libm), libiw30, and wireless-tools, and manually unpacked them into that partition. That was so that I could run iwconfig manually.

debinstroot.tar.gz - here is a tarball of the root image I used to install debian. Hopefully that's all kosher to redistribute, despite its frankenstein pedigree.

I ran crossystem dev_boot_usb=1 to enable control-U at the boot screen to boot off of SD. A note about the boot screen. The 3-finger salute here (ESC+F3+POWER) brings up the recovery screen. Recovery screen is basically good for nothing except recovery and enabling developer mode, and telling you that nothing is working. From there, POWER will turn off the thing. Then POWER again will enter the normal bootloader, which gives you a 30-second delay if you're in developer mode, during which control-D will boot from the internal MMC and control-U from the external USB or SD.

I booted the debian installer. It would not detect my wireless. Then it would, but it wouldn't do dhcp. Then I iwconfiged it manually, and then used the debian installer's UI to provide a static IP address. And then it worked. *shrug* So long as you have the /lib/modules and /lib/firmware from Chrome OS, you should eventually be able to get it to say hello to "mlan0".

It is a normal debian install from there on, except that it will constantly remind you that it cannot install the kernel or modules properly, because you are using Chrome's. Also, note that I installed it on the SD card mmcblk1p3 (overwriting my installer image). It is absurdly slow to download and install, I think because SD is slow. Note that I would not expect a Debian tasksel of GUI crap to work. I am going to install Xorg piecemeal at a later date.

After Debian was done installing and wanted to reboot, I had to re-run the cgpt commands -- apparently the Debian partition manager overwrote the kernel's success and priority flags. Also, I had to copy over /lib/modules, /lib/firmware, and /boot from Chrome OS again. I went ahead and put the whole Chrome OS root in /chromeos, so I would have it handy for harvesting binaries.

Then I booted into Debian, and ensured that wi-fi works, which is enough that I should not be stranded if I overwrite Chrome OS. Now I run this variation on Andrew's script to package a kernel for booting from internal MMC (you may want to /chromeos/usr/bin/cgpt show /dev/mmcblk0 to make sure KERN-A is partition 2):

echo "console=tty1 debug verbose root=/dev/mmcblk0p1 rootwait rw" > /tmp/config
/chromeos/usr/bin/vbutil_kernel --pack /tmp/newkern \
--keyblock /chromeos/usr/share/vboot/devkeys/kernel.keyblock --version 1 \
--signprivate /chromeos/usr/share/vboot/devkeys/kernel_data_key.vbprivk \
--config=/tmp/config --vmlinuz /boot/vmlinuz-3.4.0 --arch arm
dd if=/tmp/newkern of=/dev/mmcblk0p2
dd if=/tmp/newkern of=/dev/mmcblk0p4

Note that I am using /dev/mmcblk0p1 for root. It is about 11GB on my system, and used to hold the modifiable state information in Chrome OS. p3 and p5 are each about 2GB and were used to hold redundant copies of Chrome OS read-only root partition, and I am going to leave those partitions there unused, and accept the waste of 4GB to avoid the hassle of figuring out how easy it is to spook u-boot.

Then set up the new root on internal SD:

mkfs -t ext4 /dev/mmcblk0p1
mount /dev/mmcblk0p1 /mnt
cp -ax / /mnt

At this point, my root image is about 1.5GB, so that copy takes a while, but not forever....

I'm not sure it's important, but I went ahead and changed the UUID in /mnt/etc/fstab to match the one in /dev/disk/by-uuid for mmcblk0p1.

Then umount /mnt and reboot. Control-D this time. "Look ma, no SD!"

February 27, 2013
Debian config

Okay, now I'm bringing things up one-by-one in Debian. First, audio. I copied /usr/share/alsa/ucm from Chrome OS, and installed alsa-utils. It still doesn't make noise. I eventually ran alsaucm set _verb HiFi, which seemed to do it. Now it makes noise, and the amixer set Speaker 0-100 command works. I haven't tried headphones or mic yet.

I installed xserver-xorg-video-fbdev. It didn't seem to work very well, but I just wanted a framework in which to copy in binaries from Chrome OS. So I copied over /usr/lib/xorg/modules/drivers/ X11 works now, but I think it is just using fbdev. I got my xmodmap configured, and it is a magical victory. The trackpad is truly fubared (it only works with my thumb!), but I don't hardly use the mouse anyways. It is my laptop now! to configure xorg.conf

Okay, I can't use the binaries from Chrome OS because they are built against glibc 2.15 while debian is still on 2.13, and since ANSI C changed so fucking much in the last month, they found it very important to break the ABI. And while I was tracking this down, I discovered a whole host of infuriating issues:

I was about ready to set it down in disgust, but on impulse I let Debian install mplayer. It works great out of the box, even with xserver-fbdev. Of course, I don't believe in HD, so that shouldn't be so surprising. But I can tell victory is not too far off, so I'm gonna keep on working on the basics...

Okay, sleeping is important to me. It seems to put proper lid open/close events on /dev/input/by-path/platform-gpio-keys.8-event, which do wind up in acpid's /etc/acpi/actions/ with "$3" = "close". (because I installed acpid and laptop-mode). I have a fancy custom script for this, but you just need to make sure echo mem > /sys/power/state happens, and you'll have suspend on lid. I use xautolock to suspend on time-out, personally.

And the massive inappropriate use of UTF-8 can be corrected with export LANG=C.

To provide page up/down and home/end, I changed .xmodmap to map the left control button to Mode_switch (I had already mapped the search button to Control_L), and then I set Prior/Next/Home/End as the third choice for Up/Down/Left/Right. It is not perfect.

Essentials which Debian has failed to package for armhf, like xlockmore and x3270, seem to be compiling well from source. Debian is doing a good job of providing most of the libfoo-dev packages that I require.

I found Ubuntu Firefox 19.0 builds, but even Precise requires glibc 2.15. So I am going to bite the bullet and install Debian experimental libc6 (glibc 2.17). I added this to /etc/apt/sources.list:

deb experimental main

And then apt-get update and apt-get -t experimental install libc6.

Crossing the epic fingers.

Pfew! I have Firefox 19. It is palpably slow.

Now I am following directions from debian's installation tips. Now to start grabbing the X11 binaries:


And I added this to /etc/X11/xorg.conf:

Section "Device"
        Identifier "card0"
        Driver "armsoc"
#       Driver "fbdev"
        Screen 0
        Option          "fbdev"                 "/dev/fb0"
        Option          "Fimg2DExa"             "false"
        Option          "DRI2"                  "true"
        Option          "DRI2_PAGE_FLIP"        "false"
        Option          "DRI2_WAIT_VSYNC"       "true"
#       Option          "Fimg2DExaSolid"        "false"
#       Option          "Fimg2DExaCopy"         "false"
#       Option          "Fimg2DExaComposite"    "false"
        Option          "SWcursorLCD"           "false"

Section "InputClass"
    Identifier      "touchpad"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Driver          "cmt"
    Option          "AccelerationProfile" "-1"
    Option          "Pressure Calibration Offset" "-1.73338827637399"
    Option          "Pressure Calibration Slope" "2.06326787767144"
    # Disable some causes of delay on daisy
    Option          "IIR b0" "1"
    Option          "IIR b1" "0"
    Option          "IIR b2" "0"
    Option          "IIR b3" "0"
    Option          "IIR a1" "0"
    Option          "IIR a2" "0"
    Option          "IIR Distance Threshold" "1000"
    Option          "Input Queue Delay" "0"
    # Extra filters for Daisy
    Option          "Box Width" "1.0"
    Option          "Sensor Jump Filter Enable" "1"
    Option          "Sensor Jump Min Dist Non-Move" "0.3"
    Option          "Sensor Jump Min Dist Move" "0.9"
    Option          "Sensor Jump Similar Multiplier Move" "1.5"
    Option          "Split Merge Max Movement" "6.5"
    Option          "Merge Max Ratio" "0.5"
    Option          "Max Allowed Pressure Change Per Sec" "4000"
    Option          "Max Hysteresis Pressure Per Sec" "4000"
    Option          "Tap Drag Lock Enable" "1"
    Option          "Three Finger Click Enable" "1"

The touchpad got much better, though now it has the same obnoxious acceleration behavior as under Chrome OS. For a while it even had two finger scrolling. But then it stopped. *sigh*

I'm not sure what all those options do, I got them mostly from /chromeos/etc/X11/xorg.conf.d/50-touchpad-cmt-daisy.conf, and they did make the tapping more responsive. The final two are pretty neat. Tap drag lock is basically if you triple-click and then move your finger, then it acts as if you are dragging. Three finger click is for the middle mouse button (paste).

I think I'm just gonna get used to the acceleration, because no amount of messing with the xinput settings seems to make it actually more linear.

Okay, I also tried xserver-xorg-input-mtrack. It has very good clicking behavior, and its acceleration control is much more sensible. However, it seems to be kind of noisy as you lift your finger off of the touchpad, and its palm rejection seems to be completely broken. xserver-xorg-input-multitouch has basically no config options and doesn't default to palm rejection, so it is right out.

I have investigated what the raw /dev/input/event1 output is (using evtest), and it seems to me that halfway-decent palm rejection should be easy as pie. Okay, it disables its palm rejection for "pressure"-based touchpads. I made a patch to fix that, but its palm rejection still kind of sucks because it doesn't reject inputs that originate at the very edge of the trackpad (only the "bottom" of it).

February 28, 2013

Sleeping seems to work. Overnight (8 hours), the battery went from 98% to 95%. That's acceptable to me, it should be able to sleep for a few days at any rate. My Lenovo is not totally reliable about sleeping through the weekend, so it is "good enough" for me.

I further hacked the mtrack driver to change BottomEdge to EdgeSize, and now it rejects palm inputs with authority. Having source code is awesome, being able to re-build X11 drivers without re-building all of X11 is awesome, and mtrack is awesome. Anyways, here is my new config:

Section "InputClass"
        Identifier      "touchpad"
        MatchIsTouchpad "on"
        Driver          "mtrack"
        Option          "AccelerationProfile" "-1"
        Option          "IgnorePalm" "1"
        Option          "DisableOnPalm" "1"
        Option          "PalmSize" "20"
        Option          "FingerHigh" "5"
        Option          "FingerLow" "5"
        Option          "Sensitivity" "1.35"
        Option          "ScrollDistance" "20"
        Option          "EdgeSize" "20"

And here is my custom

And here are my patches, which I will try to get accepted upstream in some form:

Web browsing is still pathetically slow, especially scrolling and first drawing the web browser when you switch from another program. And it is oddly jumpy, if you request a scroll then it doesn't do anything for a moment and then suddenly it's awake. My theory is that the CPU frequency governor is taking a full tenth of a second or so to wake the CPU to full 1.7GHz. I installed cpufrequtils, and set the frequency to a hard 1.7GHz (cpufreq-set --min 1700000), and it got subjectively more responsive in the web browser. The battery usage monitor did not increase too much, either. Much like the Intel processor, the CPU frequency setting is not nearly as important as actual usage -- if it is set to 1.7GHz but executing HALT, it is nearly as efficient as executing HALT at 200MHz. The "interactive" governor is designed to address this exact problem (cpufreq-set -g interactive), and seems to work well.

March 1, 2013

This is now my laptop. Even though my old one still works great and is roughly twice as fast at CPU and many many times faster at GPU.

Remember the original netbooks? If you closed one and sat it on the table, it took up real vertical space. From top to bottom: screen, keyboard, compact computer. By comparison the proto-ultrabook Lenovo is a miracle, its computer part is impressively compact, though it still has a bulky and heavy battery. But the Chromebook has a totally different profile when closed. Top to bottom: screen, keyboard. Physically, there's no computer, compact or not. It makes my ultrabook-wannabe look and feel like a monster, maybe a good bludgeon. Now that I have experienced what a laptop *should* be, I am not eager to compromise on the form factor. I will learn to love slow firefox, and perhaps use the old laptop or the Nexus 7 for Stellarium.

Anyways, I'm not going to go on about any of the outstanding problems until I've had a go at fixing them. That's another thing I love about this laptop -- I have easy access to source for 90% of everything, and a surprisingly large number of things can be easily fixed, and need to be. :)

Oh, and a rave about the speakers. At about 60% volume, they are fantastic. Louder than the Lenovo's, super super crisp in the highs, and totally discernable lows. A nice touch! The sound is so good that it is actually sad when it is muffled by a stray leg or blanket.

I was surprised the speakers review so poorly elsewhere, but I think people are just responding to the fact that the sound breaks up if you turn the volume to the max. But they are plenty loud at 60%! Also, reviewers are probably spoiled by the sort of speakers that come with a 15 inch 6 pound laptop. But personally, looking at the Dell 15" for comparison, first it is unusably bulky, but second, the speakers are "high-fidelity JBL(tm) speakers with Waves MaxxAudio(tm) 3". Personally, I don't care what it sounds like, I don't want speakers that are so intensely branded that they needed TWO trademarks. Especially since "(tm)" usually means "unconscionable and uncorrectable bass boost." Google says my Chromebook has "Stereo internal speaker." Much better.

Oh, and I'm not afraid of frying them anymore. The sound driver (through alsamixer) provides access to a *huge* variety of routing switches, and you can obviously wreak some havoc with them. But I just use the Chrome OS UCM settings as suggested to set the switches. I only use the ALSA mixer controls to set volume on the Speaker channel. Stay away from the switches and you'll be fine.

And I got a real 5 hours (with 6% remaining) of usage out of it yesterday, which is pretty sweet.

Alright! I started having major problems with suspend (crashing X instead of suspending, waking to a crashed X, etc) once I actually started using the chromebook regularly, which in hindsight was the first real use of timeout-based suspend. Now, I'm not 100% certain this is the problem, but some rather cryptic allusions in forums complaining about this suggested that it is due to X trying to power down the display separately. And I checked, X was configured to start screensaving just before the laptop was supposed to suspend. So I added this to my .xinitrc:

xset s off
xset -dpms

So far so good!

March 2, 2013
Keyboard fix

I found my .xmodmap approach dissatisfying. I had remapped search to Control, and had mapped the left control key to Mode_Switch, and had used Mode_Switch+arrows to generate page up/down/home/end. However, it is kind of limited. When I would hit control+up, it would generate the keysym for page-up (Prior), but it would generate the keycode still of Up. Firefox checks the keysym, but mplayer and anything based on SDL would look at the keycode, instead, so it just straight-up did not work.

I was hitting a brick wall with deciphering xkb until I met Doug Palmer's excellent and not-entirely-reliable Unreliable Guide to XKB Configuration. It's not Doug's fault it's unreliable, any light bright enough to reach into all of xkb's crevices would surely burn xkb to a crisp. Anyways, he oriented me and here's what I came up with.

I created two new files. First, /usr/share/X11/xkb/types/greg:

partial default xkb_types "superl" {
    type "SUPERL" {
        modifiers = Mod2;
        map[Mod2] = Level2;
        level_name[Level1] = "Base";
        level_name[Level2] = "Mod2";

What that does is make a new "SUPERL" (I named it that because the default mapping of LWIN is Super_L, *shrug*) type of key which is one that has two "levels" (modifier states): Base and Mod2. This key type will be used for the arrow keys. Here is the other file, /usr/share/X11/xkb/symbols/greg:

default partial modifier_keys
xkb_symbols "searchcontrol" {
        key <LWIN> {
                type = "ONE_LEVEL",
                symbols [Group1] = [ Control_L ],
                actions [Group1] = [ SetMods(modifiers=Control) ]
        key <LCTL> {
                type = "ONE_LEVEL",
                symbols [Group1] = [ Control_L ],
                actions [Group1] = [ SetMods(modifiers=Control+Mod2) ]
        key <UP> {
                type = "SUPERL",
                actions [ Group1 ] = [ NoAction(),RedirectKey(keycode=<PGUP>) ]
        key <DOWN> {
                type = "SUPERL",
                actions [ Group1 ] = [ NoAction(),RedirectKey(keycode=<PGDN>) ]
        key <LEFT> {
                type = "SUPERL",
                actions [ Group1 ] = [ NoAction(),RedirectKey(keycode=<HOME>) ]
        key <RGHT> {
                type = "SUPERL",
                actions [ Group1 ] = [ NoAction(),RedirectKey(keycode=<END>) ]
	key <POWR> {
		type = "SUPERL",
		symbols [Group1] = [ Delete, Insert ]

First, I remap the search key (LWIN) to be a normal control key that sets the Control modifier. Then I remap the left control key (LCTL) to be a special control key that also sets the Mod2 modifier. Mod2 is typically NumLock, which is pretty irrelevant because there are no keypad (KP_*) keys on this keyboard, so for most keys that will act just like control. Then I provided these four up/down/left/right actions. NoAction() for the first action means that the Base behavior (no modifiers) is unchanged (i.e., default). The second action is applied if Mod2 (left control) is pressed, and RedirectKey generates the keycode of another key, so for everything downstream of xkb it looks as if a fictitious separate PGUP key was actually pressed.

And because it happened to be where my old laptop put it, I mapped the power key to delete. Note that you have to disable power-down in acpid, or it will not be advantageous.There is one other detail. Supposedly you can configure xkb manually in /etc/X11/xorg.conf, I found numerous documents suggesting that approach. But it just did not work for me (it still used the default rules-based configuration, as if the "evdev" driver is somehow stupid, or there is an xorg.conf.d somewhere that I could not find), so I put this setxkbmap invocation in my .xinitrc instead:

setxkbmap -compat 'complete' -keycodes 'evdev' -types 'complete+greg' \
-symbols 'pc+us(dvorak)+inet(evdev)+terminate(ctrl_alt_bksp)+greg' \
-geometry 'pc(pc104)'

But you probably don't want Dvorak, so:

setxkbmap -compat 'complete' -keycodes 'evdev' -types 'complete+greg' \
-symbols 'pc+us+inet(evdev)+terminate(ctrl_alt_bksp)+greg' \
-geometry 'pc(pc104)'

Victory! I guess I could imagine an appropriate formulation for contributing it upstream, but that just doesn't strike me as good times.

March 4, 2013
armsoc vs. fbdev, kernel build

When I "upgraded" from fbdev to armsoc, I noticed it didn't get faster. But it did start up a lot quicker, which seemed like a good sign. Anyways, after trying this test which is explained in this video, I realized armsoc is a huge fail for normal usage. Apparently ChromeOS uses some limited subset of armsoc's functionality that is not slow, while general X stuff fails preposterously on it. Or in other words, I get around 3fps with normal firefox on armsoc, 13fps with gfx.xrender.enabled=false on armsoc, or 22fps with normal firefox on fbdev! So that's nice to solve that question, what I have to do to enable decent X performance is to not install the fancy ChromeOS armsoc video driver. 2D programs (Firefox, SDL, etc.) are now much faster, but anything that uses GL is about the same (Stellarium is still too slow). *sigh*

The only reason fbdev seemed slow before is the cpufreq scheduler set to ondemand.

So on the list of issues: one down, a zillion to go. "Suspend doesn't work reliably" is the highest priority, but hardest to get traction on of course... I keep hoping it will "just start working" after one of these random changes.

Oh, and I think it was laptop-mode that kept on re-enabling DPMS on me, which also might be another suspend-breaker.

And I built a kernel! I used the directions from Olof Johansson, and they got the job done. I used the GOOGLE_RELEASE value from /chromeos/etc/lsb-release to determine that I needed to checkout branch release-R23-2913.B. I copied in the config file from /boot/config-3.4.0 (provided by Chrome OS), and added NFS support. My new kernel works for me just like the provided one (plus NFS).

I noticed the git repository had release-R26-3701.B, but the kernel I built with that did not work. For some reason wifi didn't come up automatically, and then it didn't accept keyboard input either and appeared hard-frozen, or at least completely I/O-immune. So I used prepareconfig, to catch a few settings that had changed from R23 to R26, and at least the keyboard worked, but I was getting a bizarre "Operation not permitted" error from modprobe, and I found out it is caused by some new crazy security feature added at R24. It can be disabled by adding lsm.module_locking=0 on the kernel command line.

And I have been setting my backlight by writing to /sys/devices/platform/s3c24xx-pwm.0/pwm-backlight.0/backlight/pwm-backlight.0/brightness, and now the range is 0-2800 instead of 0-255, so I just multiplied my brightness setting by 10.

So now time will tell if suspend/resume has been fixed (either by R26 kernel, or by fbdev video driver). strace has definitely been fixed. An "unbalanced irq enable" error message in dmesg has also been fixed, which may be related to suspend difficulty. Those are my 3 big outstanding issues. Nice job, Googlers!

Minor nit: irq/426-cyapa still takes mad crazy CPU time to do nearly nothing. Not sure if that is a simple flaw, complicated flaw, or inexorable result of massive interrupt volume.

It is certainly nice to have access to the active git repository, with things being fixed without me hardly lifting a finger!

Oh, and I am building my kernels on the Chromebook, not using some crazy cross-environment. It isn't even slow. make bzImage -j 8 takes 10m4s (yeah, I know, -j 8 is overkill with flash storage). The kernel source eats 1.3GB, but I still have more than half of the 11GB partition free.

March 7, 2013
GLES fail

I want Stellarium to be fast (it is around 1fps). So I downloaded the Mali GLES SDK (for Windows cross building or something, but whatever), and I symlinked the .h files into /usr/include, and I downloaded Qt4 source, and I built Qt4 with ./configure -opengl es2 -nomake tests -nomake examples -opensource, and I built Stellarium with cmake -D OPENGL_MODE:STRING=ES2 -D BUILD_STATIC_PLUGINS=0 ../, and I ran Stellarium, and it said:

QEgl::display(): Cannot initialize EGL display: "Not initialized (0x3001)"
QEglContext::chooseConfig(): Could not find a suitable EGL configuration
Requested: "type=es2 rgba=0,0,0,0 surface-type=window"
QGLContext::makeCurrent(): Cannot make invalid context current
QGLShader: could not create shader

Even with the armsoc video driver. I guess I'm not quite there.

On the bright side, suspend has suddenly become rock solid (knock on wood), after the changes on the 4th. So it was either fixing laptop-mode to stop enabling DPMS, upgrading the kernel, or switching to fbdev.

I whipped out the stopwatch and it takes 2.0 seconds to wake up to X11, and 5.0 additional seconds to bring up my wifi. That is very fast.

And I don't imagine this will ever see upstream light of day, but I noticed that this keyboard seems prone to bouncing. I monitored my typing for a day, and I monitored the time between the last key-up event for a given key, and a new key-down event. That is as short as 23ms for intentional repeated letters, but faster than that it was only a few instances of 11ms or 12ms, and those were all errors. So I hacked evdev input driver to ignore any key repeated less than 15ms after its last key-up event. So far so good.

And if you want to build ltrace for the Chromebook, make sure to find the git source and check out the pmachata/arm branch!

March 21, 2013
A couple more struggles

I had to reboot, the computer just got slower until it crashed. But I didn't really try too hard to figure it out, it could just have been that wi-fi trouble caused an NFS stall in an unfortunate process. Knock on wood.

I have had an ongoing battle with youtube. When I first installed the Debian edition of the gnash plugin, youtube worked. Then I got a bunch of bizarre intermittent behavior, and then youtube stopped working. I think this may be partly because youtube has many different encodings and player styles embedded within it, depending on which video you are viewing and what it decides your client is capable of. Anyways, I purged the debian package and re-built gnash from source (relatively painless), and that worked fine for a couple weeks.

Then today I start getting some MediaHandlerGst::createAudioDecoder: Couldn't find a plugin for audio type audio/mpeg! -- MediaHandler::createFlashAudioDecoder: no available FLASH decoders for codec 2 (MP3) popups, in lieu of audio. I went through some fails, but eventually determined that it was only happening for some videos. Eventually out of desperation I installed Debian's gstreamer0.10-plugins-ugly package, and that *seems* to have fixed the issue for all videos. It does seem like plugins-ugly includes libmad support, so that seems pretty essential. Presumably on x86 hardware I would have access to some sort of pretty codec, and not need this ugly one.

Oh, and the de-bouncer has really made me much more appreciative of its keyboard.

Oh, and this laptop gets insanely great battery life. I had just gotten used to forced re-charging every 3 hours, so going 4 or 5 hours without even getting to "low" is a miracle.

April 5, 2013
Still not perfect

I just cannot break more than about a week uptime.

It hasn't crashed on me again, so I think that problem really was just mplayer grabbing the display+keyboard and then hanging on NFS. But it's got a new and totally unexpected failure mode.

Whenever I shove the chromebook into the diaper bag, it hard resets. The lid is closed, and it should be sleeping (though it may not be, because flexing the case clicks the trackpad button and wakes it up). But when I got to the park and opened it, it was showing me the bootloader screen. And lest I write that off as a fluke, on the way home it did the same thing.

My old laptop would do things like this because its battery-retention tabs were falling apart, but this one has a hard-wired battery so I don't see what the cause could be. I've sat here with it on and open and dropped it and smashed it and so on, and it won't turn off for me. Must be something particular about how it is smashed when it is closed in a bag. Lame to the max. I'd love to know if this is a manufacturing defect of some sort, or what.

And it is increasingly frustrating that it flexes so much. On the one hand, a flexible computer takes less damage (it has fallen lots of times already), it is a good match to its light weight. But on the other hand, if I hold it with one hand, I cannot type on it with the other because the trackpad button is flex-triggering madly. There are a few tweaks I want to make to the mtrack input driver, and when those are done I think I will disable the trackpad button entirely.

On the other hand, even in Debian, it boots pretty darn quick. So it is not really a serious disadvantage that it resets on occasion. Just lame, and hard to diagnose or treat.

Oh and a real bonus is that once it is at the park, I can throw it in the grass. It has no fan so it doesn't ingest debris. And the only holes in the bottom are for the speakers, so barring an actual puddle it should be fine. It remains to be seen how the keyboard is going to fare, though.

The only other real continuing frustration is that GLES is still undefinably broken. I don't really need to play any video games, but it would be nice to run regular stellarium spiffy-fast. I've done a few hacks to disable visual features and now it gets around 3fps, which is "totally usable", but I'm at the point where, to make it go any faster, I have to optimize the drawing of great circles, which is mad stubborn slow. I'm not sure why Mesa is slow at it (maybe something is inadvertently triggering a worst-case), but I am sure that I would rather have GLES "just work" than get to the bottom of that particular conundrum.

And it runs commander keen (under dosbox), and sdlquake (41fps at 1366x768!), and prboom just fine. Those are all the games I really care about...

And I have totally gotten used to how slow it is. It doesn't bother me at all. Compiles are fast. Web browsing is plenty fast. Anymore, websites tend to either be just fine or unusably slow (buggy/crappy), with very little in between. That was true on my fast-hot laptop, and equally true on the Chromebook. And I've resigned myself to being unable to use flash, I really don't miss it. At least YouTube works.

It is actually a benefit, I have decided to think of it as a thin-ish client, so a lot of things are actually a lot faster because I run them on my big PC now. But it is still plenty powerful enough that I can copy my work codebase onto it, and work on it while I am out and about.

And I can't say enough good things about the battery life. I think I must get about 6 hours of real use out of it, compared to about 3 hours with my old laptop. It is a huge difference. I have only plugged it in "because it is low" a couple times. My daily schedule has a couple hours in the morning and a couple hours in the afternoon where it is plugged in about 50% of the time (depending on coincidences), and that is always enough that I never even have to think about the battery. At all. I changed my status display to show red text if the battery is less than 20%, and I've only seen it once!

June 4, 2013
Illustration of systematic development fail

I happened to run across an example that serves to illustrate a systematic failure in the Google Chromebook development process.

I believe when I installed Debian on my Chromebook, it previously had ChromeOS R23 on it. When I built my own kernel, I used the kernel branch for R26. OpenGLES2 doesn't work, so I was eager to try something new. So I built an R28 kernel.

The R28 kernel would not boot, it could not read the MMC at all, and failed to find the root partition.

It is the result of this bug.

It seems that kernels for R27 and above depend on firmware 2695.117.0 or above, and specifically is known not to work with 2695.104.0. To their credit, they verified that ChromeOS's default upgrade path would guarantee no one would use the R27 kernel with the older firmware.

But for anyone maintaining or supporting another distribution, this is a nightmare. The firmware, kernel, and userland should be separate projects with broad compatibility across multiple versions. Especially bundling firmware updates with kernel updates is something distributors are not used to dealing with.

I think this is probably representative of the story that has broken OpenGLES2. Everything from firmware version, kernel version, libraries and Xorg modules, all may have undocumented interdependencies. What works perfectly for one user will not work for another, and they will not have the resources necessary to determine which component has an incompatible version.

It reminds me too much of the flaws I experience using Google's cloud services. In pursuit of fastest advancement, Google has sacrificed much that users and developers would like to count on. Standardized interfaces are dead, even the interface to the BIOS is subject to constant pointless reinterpretation.

It is clearly the future. But I've got complaints about it.

I installed Debian Woody on my PC in May 2003, about 10 years ago. Since then, I switched to debian-unstable, and have just periodically apt-get update and then apt-get install whateverpackageineed. It has always figured out all of the interdependencies automatically for me, almost never giving me trouble. In that decade, there was one instance where a kernel upgrade and userland upgrade were forced to coincide. It was more difficult than it should have been, so I sent a suggestion to a Debian package maintainer to make it easier, and they eventually implemented it.

In all of those 10 years, I never once had any experience where anything was tied to a BIOS update.

By comparison, in the 3 months I've had my Chromebook, they've already tied a kernel update to a BIOS update, and presumably several userland updates as well. And without any documentation.

It is fair for to say that I am not using the Chromebook as Google intended. However, this haphazard development model seems to be the norm for *all* ARM hardware, for *all* Google-influenced hardware, and for decently-portable hardware in general.


But to make lemonade, I need to find a resource to download new ChromeOS images. Here is a script to install the newest ChromeOS over a current Chromium (though it seems to be for x86 Chromebooks, or something). It uses this link:, which points to the current ChromeOS. It uses crazy stuff like: mount -ro loop,offset=$((`cgpt show -i 12 -n -b -q $image_file`*512)) $image_file $WORKDIR/chrome_efi_mount to mount the filesystems within the image. Yeah, the image has a GPT (GUID Partition Table) inside of it.

Unfortunately it is currently ChromeOS 3701, which I think is R26. So I will have to wait a while for a complete official R28...

February 5, 2014
Staying power

I have young children, which is bad for my laptop. One of my favorite things about the Chromebook is that it is so light and plasticy that it can be dropped with minimal damage, so I don't have to be so paranoid about it. It has fallen about 2 feet at least 20 times in the past year. When it falls, its flimsy plastic clips pop apart -- just snap them back together and it's good as new. Once, the charging connector bent (but still works *shrug*).

But last night's fall finally broke the screen instead of popping the plastic clips. *sigh*

So I am writing this post to tell you: oh my god my old PC luggable (Lenovo Ideapad) is *SO* crappy! Its "skinny" parts are huge, and even so they are smaller than its gigantic battery in the back that is heavier than the whole Chromebook. It takes its huge battery about 3 hours to charge, which is barely faster than it discharges -- I'm going to be tethered all day. It is so heavy there is no illusion it will survive getting thrown to the floor so I'm going to have to carefully babysit it to make sure my kid doesn't get ahold of it. Its keyboard *SUCKS*. It's already hot! Its fan is so loud, I can hear it across the room. It's not any faster than the Chromebook unless you run GLES, and then the fan really kicks on!

Punchline: It is absolutely worth the $50 to get a new screen for the Chromebook.

July 28, 2014
Sic transit keyboard

A couple months ago, my down arrow key popped off. I'm an experienced keyboard surgeon but I could not discern the cause of failure. I managed to snap it back on, but if you hit it wrong it will still pop off every now and then. *shrug*

Now the 'a' key and control key have both popped off, and since they are bigger keys I had an easier time diagnosing it. The key is built out of a cap, a flimsy plastic scissor jack, and then some metal clips built into the laptop. The cap snaps to the scissor jack, and the scissor jack snaps to the clips. On other keyboards, I have had the scissor jack fail, but that does not seem to be the problem here.

Basically, the interface between the metal clips and the scissor jack has a tiny overlap. On these keys that are popping off, the overlap is only sufficient to hold together if the scissor jack is extended. If it is fully compressed (such as when you hit the key) then for a brief instant, the key is free to leave the keyboard. The little metal part is actually what deforms -- it seems to be a soft metal, and apparently it can only take ~200,000 key presses before failure.

Obviously, firefox killed down arrow (which is extra flimsy because it's small), and screen killed control-a. But other keys are obviously beginning to fail in the same way, so it is time for a new keyboard. I haven't ever had a laptop keyboard last more than a year without damage, though this is perhaps the most incapacitating damage I've seen yet.

So, new keybord time! $20 on ebay for the whole top half of the bottom half of this laptop (keyboard+trackpad+plastic cover).

But now that the new keyboard has arrived, I am bold enough to aggressively bend the little metal tabs to where I think they belong, and maybe I have fixed all of my problems??? To be continued...

November 9, 2014
Thus passes keyboard

Since I had the new keyboard, I was confident enough to do forceful surgery on the old one and that actually worked fairly well. But a few days ago I had a scare -- pulseaudio screwed the pooch such that I thought the built-in audio chip was actually broken, and I briefly considered buying a new laptop before I figured it out. I settled on the Asus C200 even though it has a Celeron in it!

I realized I might never get to use the new keyboard, with its (much needed) new speakers. So I acted decisively.

Taking apart the Chromebook was pure joy. A big relief since I am hardly a laptop surgeon. The bottom half only has three types of screws in it and they're easy to tell apart. The display hinge comes apart fairly easily. There is so much extra space and so few cables that there is no moment of "how??" to contend with.

Inspecting my old speakers revealed the problem: they had attracted a variety of scraps of metal that were pinching the membrane to the permanent magnet. Since I use the laptop at my workbench, that is not very surprising. For the new speakers, I covered the ports up with tape. The tape muffles the sound a little bit, but is not nearly as bad as the iron filings were.

The new keyboard has a slightly different -- and overall probably not as preferable -- feel than the old one. And there is some sort of structural difference now too. I can pick up the laptop by one of the corners and wave it about in the air, and it doesn't flex enough to trigger the physical trackpad button. Way cool!

And an anecdote about how fantastic this laptop is. I was dangling it, open, by the corner of the LCD as I walked about the house. I wanted to pick up something off the shelf that needed two hands, so I did that. While I was picking up the thing, I was not holding the laptop. Accordingly, gravity acted on the laptop and the laptop fell 2 feet to the floor. Once my hand was free again, I stooped down and picked up the laptop. This is not an unusual moment of thoughtlessness, it's just how I treat 2.5lb laptops.

My old Lenovo is a damn brick by comparison, even though it manages to come in under 4 pounds. It is a bad idea to carry it around by the LCD, and unthinkable to drop it.

February 27, 2015
The bell tolls for hinges

A couple months ago, my 1 year old put his knees on the keyboard, then he put both hands on the screen and put his weight on it, like chest compressions in CPR. He hyper-extended the hinge nearly all the way to flat open. The hinges have long flimsy metal bars that extend all the way to the top of the display because the plastic around the display is not rigid enough to really support it with just one small hinge anchor point -- the bars spread the stress out. One of those arms snapped.

So the screen was super floppy on one side, and the plastic was getting flexed like crazy. So I ordered a new hinge. It eventually got here, and I installed it, and now my laptop is good as new again (except for a cosmetic crack from the plastic being devastated).

Each time something crazy like this happens to my poor laptop, I think, maybe this is the end. In all honesty, the Asus C200 probably would work better for me anyways because it has slightly better battery life. But then I perform the repair, and each time I am blown away by how great the laptop is after I repair it.

New screen, keyboard, and hinges...the only stock parts left: battery, motherboard, and 3/4ths of the plastic.

May 7, 2015

My Samsung Chromebook XE303C has barely lasted two years, but my disloyal eyes are already wandering.

My Lenovo Ideapad U150 still gets about 2 hours of battery life, which is pretty good for its age (only a little worse than when it was new). But it takes it about 2 hours to charge so I am tethered at least 50% of the day. Which sucks. Especially because kids eat tethers.

My Chromebook has about 5.5 hours of battery, which is also nearly as good as when it was new. And it charges in about an hour, so I'm tethered at most 25% of the time, and many days I am not tethered at all because I charge it during lunch. One charge during lunch lasts me the whole workday, though it's cutting it pretty close. Not bad.

But the new Asus C201! It uses a Rockchip ARM, which is apparently even further down the relative performance scale today than the Exynos was two years ago. It has a 10-12 hour battery! I might go the whole workday without recharging, and perhaps as few as 10 minutes on the charger during lunch would give it a comfortable margin.

And it's only $170! The only thing stopping me from buying it is that I don't really want to go through the hassle of configuring a new laptop from scratch right now. The Chromebook I have is really perfect as it is. I just have this idea that if the improvement from 2 hours to 5 hours was fantastic then maybe the improvement from 5 hours to 10 hours will blow my mind.

So, is confessing my crush an alternative to acting on it? Or is it just another step towards infidelity? Time will tell.

June 3, 2015

One of my children spilled a bunch of water directly in the keyboard. To its credit, it was constrained to the keyboard. But a little must have gotten into the membrane because a few keys are a little flakey now.

I pulled out the Lenovo "loaner notebook" while the Chromebook was drying, and that thing is awful. So hot and loud and slow at charging and fast at discharging.

So I ordered an Asus C201. And a replacement keyboard.


June 6, 2015
To crouton, or not to crouton?

Okay, new chromebook time! The Asus C201 is just like my old one, basically.

Crouton (Debian in chroot under chromeos) appears to be more of a path-well-travelled now, so I'm going to try it first. I see a few big upsides:

And some downsides:

I'm especially afraid of learning about ChromeOS. If I can tell it's there, it's probably not worth it. OTOH, it would be nice to have real flash player when I need it??? I don't think so...

The fact of the matter is, I don't want it. But I've made it this far, so I'm gonna see if I can resolve those questions. Though I must point out that chrome is using 300MB just showing these two terminal sessions. But 300MB doesn't matter. I guess.

Building some kernel modules using the sources at git clone I checked out branch release-R43-6946.B-chromeos-3.14 (because that's what my chromeos is). I ran ./chromeos/scripts/prepareconfig chromiumos-rockchip, then make menuconfig to enable NFS.

I have come to the dreaded Chromium OS LSM: init_module denied while trying to install NFS modules into the ChromeOS kernel. Down with Chrome OS!

I built the full kernel under the crouton environment. I got a debian initrd from I extracted it with zcat initrd.gz | cpio -i on a microsd card that I configured, again according to the directions from Andrew Wafaa. I had to remember to run cgpt add -i 1 -S 1 -P 10 -T 5 /dev/mmcblk1 when done installing the kernel in /dev/mmcblk1p1.

Building the kernel was a little more work than I remember, and I'm not precisely following Olof's directions anymore... I ran make bzImage, and make modules, then make dtbs. Then I used this kernel.its:


/ {
    description = "Chrome OS kernel image with one or more FDT blobs";
    #address-cells = <1>;
    images {
            description = "kernel";
            data = /incbin/("arch/arm/boot/zImage");
            type = "kernel_noload";
            arch = "arm";
            os = "linux";
            compression = "none";
            load = <0>;
            entry = <0>;
            description = "rk3288-speedy.dtb";
            data = /incbin/("arch/arm/boot/dts/rk3288-speedy.dtb");
            type = "flat_dt";
            arch = "arm";
            compression = "none";
                algo = "sha1";
    configurations {
        default = "conf@1";
            kernel = "kernel@1";
            fdt = "fdt@1";

Then I ran:

mkimage -f kernel.its kernel.itb
echo "console=tty1 debug root=/dev/mmcblk1p3 rw rootwait" > config.txt
vbutil_kernel --pack kernel.signed \
      --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
      --version 1 \
      --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
      --config config.txt --vmlinuz kernel.itb --arch arm

That's kind of tedious but still pretty straightforward. Then I booted on the microsd, knock on wood.

Apparently I have to edit Debian's /sbin/init. Change the tmpfs size to 200MB:

if mount -t tmpfs -o size=200M tmpfs /mnt ; then

And, yuck, before running make modules bzImage, I apparently have to run export WIFIVERSION=-3.8 (the native 3.14 brcmfmac driver doesn't seem to be maintained as actively as the one in wireless-3.8.

And thankfully, after all that, the debian installer doesn't really give any trouble. I don't have to manually configure the wifi or anything like that. I did the same process as last time of installing on the SD card, verifying that wlan works, and then copying to the internal storage. This time I was a little bolder and re-partitioned to use ROOT-A, ROOT-B, and STATE as one big partition (14.5GB). I did preserve all of the other partitions because I don't actually know (or care) how vboot works.

So....I did get utility out of the crouton install, it let me rebuild my kernel without futzing with cross compilers. The laptop is "very slow", but that means it took 15 minutes to build kernel+modules. When I was a kid, it took 30 minutes just to build a tiny 1.2.13 kernel. So not bad.

I copied over the UCM files (/usr/share/alsa/ucm), and I initialized sound with alsaucm -c ROCKCHIP-I2S set _verb HiFi. Then the amixer set Speaker control works.

The wifi driver (brcmfmac) isn't super reliable, and never comes back after suspend. And the webcam (/dev/video2) always reports itself as busy. And mplayer installed a crap AVI codec. But alsa, X11, firefox, nfs, vpn all work just fine. I'm most of the way there. But the wifi problems are going to reduce my productivity...


Okay, this is pretty much all I've done all day, but I figured out why brcmfmac wasn't suspending reliably. Long story short, you need to copy over /etc/modprobe.d/blacklist-btsdio.conf from ChromeOS. It contains:

blacklist btsdio

If I were Google or Asus, I would have just not shipped btsdio with the kernel config for this laptop. But anyways, if btsdio (the generic bluetooth-over-SDIO) driver gets loaded, then it attaches to the same internal MMC slot as the wifi (both are in one chip), and the generic driver doesn't support power management so it removes it instead of suspending it, and then it never adds it back! I feel like the amount of effort to figure this out is a failure in Linux's MMC layer. *sigh*

To that end, here's a patch I submitted to LKML that would have made a useful error message here and saved me about 6 hours. Of course, if you're reading this you already know the punchline (blacklist btsdio).

If you actually want bluetooth, there's a fairly straightforward process to get a brcm firmware loader for the bluetooth, which does seem to work...but I'll never actually use it.

The webcam seems to not wake up until it is opened, which is why it always says it is busy. It seems to simply work to start it twice. It's worth noting it seems to show up as /dev/video2 due to some bogus v4l devices that are created for hardware codecs??

So I just have to figure out the mplayer codec problem and I'm in business!

And mplayer seems to be just pickier about a few marginal videos. So that's that -- it's my new laptop now. That wasn't so bad, was it?

June 10, 2015
Asus C201 Review

I've had it for a few days as my daily driver and here are some observations.

The battery life is everything you could hope for. I have had a hard time getting it below 50% charge! I decided to skip the lunchtime charging I'm used to -- so, 9 hours -- and was down to 47%! When it's idle, it draws about 0.27A. That's even lower than the Samsung Chromebook! I have no doubt this thing could do 12 hours, and then some. That's insane! My old Chromebook had about an hour left after the end of the afternoon shift, while this one has probably 3-5 hours left after a whole workday!

It is *slightly* smaller than the Samsung Chromebook. It is much more rigid. I have never had the trackpad click when I didn't want it to. It also has no interface cover plates which will fall apart.

The speakers are pretty alright. They don't seem to get hot, which is a step up from the Samsung. Also, I predict their grills will do a better job of preventing random scrap metal from collecting on them.

The charging port is kind of stupid. It has something that looks kind of like a micro-USB connector, but isn't. It's invertible. I said to Sarah, "look the power plug is invertible!" and she said, "your old one was a cylinder and didn't care about the angle at all." : |

You know how when you plug in a full-sized USB connector, it doesn't go in, so you turn it upside down and it still doesn't go in? Well, this connector is like that except it has the one advantage that you know turning it over won't solve your problem. It basically sucks. But I never have to charge so whatever.

The SD card slot only takes microSD, but the card doesn't stick out when it's installed so that's a step up from the Samsung (not that I need more storage).

It is incredibly similar to the Samsung Chromebook. The keyboard feels about the same (which is good). The trackpad is only marginally better. The screen is glossy instead of matte, but it doesn't bother me much. Otherwise, the screens are about equally crappy. The weight is very similar. They have the same LEDs.

The Samsung's keyboard had a few subtle flaws -- poor de-bouncing of keys (I solved it in software) and sometimes it would register an enter press for no reason (probably cross-talk/capacitance?!). The Asus does not seem to have these flaws.

And the new configuration does HTML5 video in Firefox acceptably -- I don't know if that's the Firefox upgrade (version 38.0), or the new driver/library stack. Pretty cool, though.

We'll see how it weathers, but I'm super optimistic.

July 28, 2015
A few notes...

Now that I've had it for a while, I think I've run into all of the surprises...

Did I mention it is just like the Samsung Chromebook in every way? Except with perfect battery life.

I've now dropped it a few times, and it seems to be just as durable as the old one...

I noticed it took a long time to restore wifi after waking from sleep, and it turned out to be dhclient. DHCP has a stupid overdesigned system so that if you have a hundred PCs that all power on at the same time and broadcast on an unswitched network, they will not tend to collide with eachother when they all cry out for an IP address. Practically speaking, it means that if the first DCHP request is lost (which it always is), then it waits a real duration before retrying. I added two lines to the end of /etc/dhcp/dhclient.conf:

initial-interval 1;
backoff-cutoff 1;

Now it reliably takes 5 seconds from opening the lid to being fully resumed, which is about as good as I've ever seen on a laptop.

And one more thing I had to do battle with -- headphones. On the Samsung, I just set the volume independently on the Speaker and Headphone channels, and that worked. But on the Asus I also have to tell UCM to enable the headphones (which disables the speaker). So here is a complete list of idioms (which I have wrapped up in shell scripts, naturally):

# enable the speaker at bootup:
alsaucm -c ROCKCHIP-I2S set _verb HiFi
# set speaker to half loudness:
amixer set Speaker 50%
# enable headphones (disable speaker):
alsaucm -c ROCKCHIP-I2S set _verb HiFi set _enadev Headphone
# set headphones to half loudness:
amixer set Headphone 50%
# disable headphones (enable speaker):
alsaucm -c ROCKCHIP-I2S set _verb HiFi set _disdev Headphone

I have no idea if those will be useful to anyone -- surely Gnome/KDE take seamless advantage of UCM. But I found UCM to be totally overdesigned, undocumented, and underdesigned all at once. Anyways, there is another _enadev and _disdev target called Mic that I think enables a microphone on the headphone port (otherwise, it uses the internal mic?). Anyways, I have not attempted any recording so YMMV.

February 5, 2016
Progress report

I've had this laptop for a while, and I have something to say:

[greg@rat] ~$ uptime
 09:16:04 up 216 days,  1:07,  7 users,  load average: 0.13, 0.14, 0.22

I've owned this laptop for 245 days, so....basically, once I got it set up, it is stable. I don't really mind that the older Samsung Chromebook would hard-reset from a hardware fault when subject to mechanical shocks. I would not go to heroic lengths to save my Asus C201 from a reboot. Even so, this laptop hasn't rebooted since I first set it up! Pretty cool!

That beats my PC (137 days since a power outage), my linode (68 days since a reboot for hypervisor security fix), and basically everything else in my life except for a pair of obsolete palmtops that have been sitting idle on chargers since 2010. Pretty cool!

And this is my most-used daily driver, subject to NFS-over-wifi stalls, toddlers ("SOMEBODY touched the laptop," my oldest tells me), physical shocks and drops, Firefox DOSing my X server, 12-hour stints off the charger, and so on. Pretty cool!

About those physical shocks, it is holding up fine, and it has fallen quite a few times. It is much more rigid than the Samsung Chromebook was, but it does not seem to be more brittle for it. The plastic is slightly warped at a couple corners from drops, but not as bad as the Samsung was.

About those marathon laptop sessions, the battery is still good for 12 hours. I have rarely run it below 10% (the "red zone" on my status display), but even so, I have never had to adjust my habits because of the battery. Every previous laptop, I had set up the charger so I could reach it from a seat, but this one is tied off so it can only be used when the laptop is out of reach. I have never regretted that. It is not so much that I'm impressed with my Asus (in fact, I take it for granted). Really, I'm shocked that anyone ever accepted less.

I still think it's fast. When it's slow, it's due to obvious failure modes in Firefox. Firefox sucks. The modern web sucks. I run things like compilers and GIMP locally, and never feel anything is slow except Firefox.

About that keyboard... I generally feel good about it, but for indefinite reasons I think it is not as good as the Samsung Chromebook's keyboard, but the difference is pretty subtle. I have not had to clean it. I did get a bad feeling about the "c" key, and when I took it apart, a piece of plastic broke off. I think the plastic actually broke and caused trouble before I took it apart. It went back together without complaint and I've been using it for a month since. I anticipate going another 6 months before replacing the keyboard. Knock on wood.

The keyboard has a very soft touch, and I actually have long liked typing lightly. But I think it may have finally jumped the shark -- lately, I've noticed I often don't bother to press the keys hard enough to make contact.

March 22, 2016
Toddler strikes again

I sat the laptop on the back of a chair for about 30 seconds, and when I came back, it was (apparently still) there and two kids were hovering around it. Fred said, "Rufus touched a laptop." It turns out, in addition to sending some cryptic punctuation to my boss, SOMEBODY broke the hinge and display.

It was still on my local network, but the screen was blank (though not obviously damaged). I gave it a hard reset (power+F3) to see if the screen would come back, and it did not. Uptime was:

12:52:51 up 262 days,  3:45,  6 users,  load average: 0.43, 0.33, 0.29

It did not reboot once between when I installed the OS and when the kids broke it!

I used the Samsung Chromebook to finish off the afternoon. It was pretty much exactly as I remember it -- and barely different from the Asus C201. Pfew! Just a little heavier and not nearly as battery-ish. Maybe slightly slower -- specifically, at accessing the builtin flash storage.

Easy to take apart. Remove the six obvious screws on the bottom -- no need to get the screws under the rubber feet. Unsnap the two parts of the lower half with a pocket knife. The keyboard side is only hanging on by the flat ribbons for the keyboard and trackpad. Unfortunately, the battery connector is hidden behind a metal shield that may very well be a heatsink, so I left it powered on the whole time!

The plastic parts holding the screws that connect to the left hinge had separated from the case, and the hinge took the LCD cable off the motherboard as well.

The holes in the metal of the hinge were about 2.5mm in diameter, so I drilled 3/32" holes in the case directly under where the screw-receivers used to be, using a drill press. Then I put the metal plate of the hinge back in position and slid short (8mm?) M2.5 screws through it. They slid in easily up to the holes I drilled, then I used a screwdriver to thread them roughly into the plastic case. They stuck out the bottom just enough for the appropriate nut.

Then I injected hot melt glue under the hinge plate as well as I could, so it wouldn't tend to wiggle too much. Mostly because it was no longer resting on flat plastic. And I used a little hot melt glue on the outside to discourage the nuts from vibrating loose, and to avoid scratching the furniture.

I reattached the connectors for the screen, keyboard, and trackpad, and put the whole thing back together -- it works! The LCD connector was just a press-fit with no kind of locking bar or anything. The flexible part of the connector interfered with one of the screws I put in -- its head wasn't quite as low-profile as the original had been. But the original would have intrefered too -- lame. I hope the connector doesn't loosen up over time. Jinx! Knock on wood. Etc.

Eventually I will want to replace the keyboard, and it bums me out that there are not any C201 keyboards on ebay etc. I don't know if it just takes time for things to percolate through these channels (maybe new production is cornering the market on the keyboards). I do notice you can get C200MA keyboards easily enough (13NB05M1A-PR), and they look very similar. But the keyboard is very integrated with the case (plastic rivets), so if there is a different screw layout or ribbon position, that will not be very feasible to make work. And I have no guarantee that they use the same mechanism so it may not even be a good supply of spare key parts.

The backside of the keyboard has the code 13NB0912AP0401 / 3B0Q1TCJN30 on it. Searching for that does yield a couple foreign hits, so maybe it'll be possible by the time I need it.

August 6, 2016
Hinges: the gift that keep on giving

Well, the second hinge went. It had two screws in it, and from its behavior I think the first one went long ago -- perhaps even in the March incident. The second screw went a couple days ago. Since there was no video on that side, the laptop was still functional, just the hinge was slowly breaking the top part of the case (the keyboard part).

Just as easy to replace the screws, but now that I've looked at it twice, I'm convinced it's not just an incident of toddler trauma, but actually a flaw in the laptop. For one, the plastic bits that hold the nuts to the cases are not beefy enough. They should have greater attachments to thicker plastic spreading the load out across the case.

But much more trivially, there are the wrong number of screws. Even after my repairs, when I open the laptop, the hinge is solid -- in that direction, the screws are cantilevered against solid plastic and motherboard grounding pad. But when closing the laptop, the hinge naturally lifts off of the motherboard grounding pad and flexes the screws a little bit. The problem is that both of the screws are too far away from the axis of the hinge, and are in a line with eachother, so the screws alone don't provide any rigidity along the important bending axis.

A third screw -- or even just moving one of the two screws to be in a better place -- would make it so the plastic doesn't have to flex every time you open and close the laptop.

I had to reboot to get the trackpad to come back. And I think if I have to do this again, I will destroy its little flat cable. *sigh*

December 9, 2016
My god, this laptop isn't perfect

Today my wi-fi died in the middle of normal usage. I immediately blamed my kid. Surely he found his way into the closet and unplugged the access point! Surely he flexed a bit of CAT-5E past the breaking point! Surely he pushed the damn "stop working" button Motorola so thoughtfully put on top of the cable modem!

Imagine my surprise when iwconfig hung, dmesg was full of wlan errors, and rmmod brcmfmac also hung. A race case or data corruption or something caused the wlan driver to develop an uncorrectable disability! My god, this laptop isn't perfect!

It had an infelicity that wasn't directly caused by my kids. After only 17 months of ownership, it manifest a single failure. I can't believe it. This is not the apex of perfection I have come to expect from this $180 budget disposable toy.

C'est la vie. 3 minutes to accept the diagnosis, 30 seconds to hard-reset and find it works again, 4 minutes to complain about it here. Life goes on.

April 7, 2017
Hinges again!

I bought a replacement keyboard because they're cheap now, but the key which was dying (home row 'e') "fixed itself" when I pushed real hard on it after having the replacement in hand. Just like with the last Chromebook, having the replacement available obviated its need.

The replacement keyboard came with a bonus part, the bottom piece of plastic, and it shows exactly the same damage as mine did: 3 of the 4 hinge screw receivers are totally sheared off. Jinx!

So a couple weeks later, I notice that the hinge on the right has failed again. This time it is on the screen side of the hinge. Oh boy!

I pried up the bezel by spudging along the outside, and I could see that only one of the two screws was still attached on that side. I could not completely remove the bezel without taking apart the whole shebang, so the first thing I did is use a ~3/16 drill bit to drill a hole in the bezel so I could access the top of the old screw. Then I removed the old screw and used a ~3/32 drill bit to drill a hole clean through the back of the display plastic under where the screw had been.

I inserted a short M2.5 screw, and to give it something to hold onto on the back (because the hole in the back was not entirely snug against the screw), I made a washer out of a bit of a license plate. Then I put a nut on top of it, and gauze and hot melt glue (to protect from snags) over that.

I'm getting over my fear of taking a drill press to a powered-on laptop, let me tell you.

I wonder which hinge screw will fail next!

I'm astonished that I'm able to repair this so easily, but it really points to a trivially-avoidable oversight in the mechanical engineering.

April 23, 2017
GL, finally

I did wind up installing the new keyboard, and it is astounding how different it is from the old one. Only one key was at all damaged, so it's not a huge improvement, but it is just *weird* to have keys that haven't been rubbed smooth or warped from over-use.

Taking apart something like this, it is easy to forget what laptop surgery used to entail. In my PC laptops, there were many more components and they were much more tightly packed. There were often two boards on top of eachother. There was never enough space for a proper frame so things like the HDD were structurally relevant, which is simply hard to believe but I've seen it with my own eyes.

I'm not saying Asus wasted any space, but it is absolutely not cramped in this thing at all. There's a small number of boards and they're all clearly visible and accessible in a single layer. You can immediately see where all the cables are routed. I have dreamed of this laptop all my life. The future is great.

Anyways, I decided to give Mali GL a try again.

ARM now provides a slightly better set of Mali binaries. The Firefly board sounds most similar to the Asus C201, so I got that. The R43 kernel I had been using has the kernel driver for Mali r5p0 built into it, so I downloaded malit76xr6p002rel0linux1x11tar.gz in hopes of compatibility.

I deleted the libEGL*, libGLES*, libOpenCL* files that were alread in /usr/lib/arm-linux-gnueabihf and replaced them with the libraries (symlinks to from that tarball.

Then I had to configure /dev/mali0 to be writable by my user account.

Bam -- incompatible:

file /dev/mali0 is not of a compatible version (user 9.0, kernel 8.0)

So I did a git pull on my kernel source cloned from I decided to go with release-R47-7520.B-chromeos-3.14, as it is the oldest kernel that uses the Mali r6p0 driver. I'm going to include fairly detailed kernel build instructions again, because each time I am nervous that I have forgotten everything.

First, I run:

chromeos/scripts/prepareconfig chromiumos-rockchip
export WIFIVERSION=-3.8
make oldconfig

I just accept the defaults for oldconfig. Then make menuconfig, and I disable everything under Security, because otherwise I can't load the Broadcom firmware. And I enable NFS Client, because I use it. Then make modules, make bzImage, and make dtbs, and make modules_install (as root).

I have the same kernel.its device tree file as from before. I have a file named cmdline that contains this line:

console=tty1 debug noinitrd root=/dev/mmcblk0p1 rw rootwait

And I have a script I've named doit:

echo before running this, export WIFIVERSION=-3.8\; make bzImage dtbs

rm -f kernel.itb kernel.signed
mkimage -f kernel.its kernel.itb
vbutil_kernel --pack kernel.signed \
      --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
      --version 1 \
      --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
      --config cmdline --vmlinuz kernel.itb --arch arm
echo run:
echo dd if=kernel.signed of=/dev/mmcblk0p4
echo cgpt add -i 4 -P 15 -S 0 -T 1 /dev/mmcblk0
echo and eventually: dd if=kernel.signed of=/dev/mmcblk0p2

I run doit and then follow the instructions for installing a temporary kernel in /dev/mmcblk0p4.

To set up the permission for /dev/mali0 correctly, I added this line to /etc/udev/rules.d/99-custom.rules:

ENV{MAJOR}=="10", ENV{MINOR}=="55", MODE="0660", GROUP="staff"

A few other things that have come up: I needed to adduser me input to get my trackpad to work under new version of xserver-xorg (because it isn't setuid root anymore). And I couldn't get the stock umountnfs script to work so I put umount -t nfs -a into a new script /lib/systemd/system-shutdown/custom.

A reboot kinda-sorta works. WebKit2 GTK browsers like Titanium and Epiphany now run and are passably fast, but fail to display a lot of things. eglInitialize() still returns FALSE, so I can't run stellarium. But at least my laptop still works.

The next step was a lot of work. I built armsoc using the devel/rockchip branch of (RaumZeit's branch is needed for newer versions of xorg -- mmind's has not kept up). But that was not enough, there has been a change in xorg that breaks armsoc! I have an egregious hack to work around it and now eglInitialize() works, and so does stellarium! webkit2gtk still fails to render a lot of things, though, so I guess that wasn't really the cause there.

When I get to the bottom of armsoc's breakage, I'll post more detailed instructions here, I guess...

But I did find this link that you might enjoy. It is the fruit of another person's quest using Crouton on an Asus C201.