Now with charging limits!

Original Editable version 2 of 2

The C100P Flip is the best netbook I have seen in eight years. When I pick it up, I feel a magic that I haven't felt since the original Eee PC. Now normally I don't bother putting all my little one-off hacks online but I really like this machine and really hope it'll be more popular. However I suspect that I am a harbinger so chances are it'll flop and be another eight years before a netbook this good comes around again. I snapped up a 4GB model as soon as they became available, slapped Arch Linux Arm on it and have been very pleased.





Pros

15 hour battery life for my typical use (ssh, vim, pdfs, music)

6 hours for 'worst case' (video playback, max bright, max volume)

16 days in suspend

looks like a midget macbook pro

totally fanless and silent

solid aluminum chassis

lightweight, under 1kg

lovely IPS screen

backlight goes high enough to work in sun

backlight goes low enough to not hurt when reading at night

screen is usable in full sunlight without backlight

2W typical power draw (a 20cm solar panel is plenty)

decent keyboard

goofy tablet mode

flush uSD socket

Cons

glossy screen

only two USB2 ports

newfangled power jack shared only with the Asus X205 (beware, 19V vs 12V!)

no trackpoint

no removable/replaceable battery

ancient custom kernel (3.14.0)

weird google bootloader





Internals

Brian Ditfeld did an excellent C100P teardown and I have to say I like what I see. When the battery finally goes it appears it will be reasonably easy to fit a new li-poly pack in there. Maybe not the full 31Wh of the original, but even half the battery life would still be acceptable in 10 years.

Benchmark-wise, the single-thread performance of the Flip is a bit faster than my old Thinkpad X120e with an E350 CPU. Not going to set any records, but plenty enough for my dev work.

Installation





If you run into problems getting something to work, open an issue and I'll see if I can expand on a topic.





Follow the directions on the Arch Linux ARM page. But those directions are for installing to a micro sd card. You'll want to nuke the entire internal SSD for the best experience. Simply follow the uSD directions except substitute /dev/mmcblk0 for /dev/sda and /dev/mmcblk0p{1,2} for /dev/sda{1,2} . Though do consider making a full disk image of the drive beforehand in case you are worried about botching things.











Platform packages to install:

xf86-video-armsoc-rockchip veyron-libgl armsoc-rockchip vboot-utils









The classic startx is a huge pain to get working. I eventually gave up and used SDDM to get X11 rolling. Put alias startx="sudo systemctl start sddm" in your bashrc (and a matching passwordless exception in sudoers) with SDDM configured for automatic login to continue feeling leet for booting to console.





The default ALSA config was completely silent. Enabling Right Speaker Mixer Right/Left DAC fixed that. Supposedly there is a risk of burning out the amp if you thoughtlessly enable every option.







After suspend/resume, wifi will not work if the btsdio module was automatically loaded. See c100p.modules.conf for that.





For a video player VLC takes the least amount of setup. The best video output mode is X11 video output . Despite what everyone says about being slow, this is the only driver that doesn't have major desync problems. The OpenGL-ES output mode does not desync, but it also can't scale video or run for more than a few minutes. Like many ARM boards the sound chip is fickle and only accepts 44.1k data. Set alsa-audio-device=hw:CARD=ROCKCHIPI2S in ~/.config/vlc/vlcrc if you are not using pulse, otherwise it won't detect the correct sample rate.







The HW accelerated 3D drivers are what you'd expect from binary drivers. They mostly-sort-of work. The biggest problem I've seen is they fall over in a stiff breeze. For example, Stellarium would run at a buttery smooth 60 FPS for a few minutes and then everything would die. (No overheating though.) Capping the frame rate to 15 FPS has made it stable enough for a good star-viewing session. I expect you will run into similar problems on a per-application basis.

In a minor irony, Chromium will not run on this hardware. Thankfully Firefox has no problems.





What is the point of having a touchscreen if you can't doodle a play-by-play? The best drawing software I've found for this is

gromit-mpx-git.





The function keys don't generate XF86events, I bound Control+FX to scripts instead. The only one that I've had trouble with was the "lock" button (keycode 191), which binds to XF86Tools . For some reason my WM would not recognize that so I remapped XF86Battery to it. The dedicated volume buttons work properly.

Screen rotation through xrandr doesn't work at all, limiting the usefulness of tablet mode somewhat. But mupdf is usable enough though you have to drag the page "backwards" to advance in some orientations. While I still think the tablet mode is a little silly, it has lead to a noticeable increase in the number of PDF papers I read. Could also just be the novelty too.

To get the most battery life you need to run the backlight as low as possible. The easiest way to do this is to use a console theme with a white background. White backgrounds are also usable in full sun with the backlight disabled. I find they reduce eyestrain because it forces you to use the minimum contrast ratio. (If you think they are blinding, try turning down the backlight!) Almost all console applications assume a dark background and at some point I need to publish the collection of themes I've been putting together.

I have heard from a trustworthy source that these boards should be able to safely take up to 19V. Be warned that I have not confirmed it, nor do I plan to! The lower voltage cutoff has some hysteresis and is 9.8V (falling) or 10.2V (rising). If you want to experiment with alternative DC power supplies you can splice a barrel jack into the power cable. It is only a simple coaxial cable and there is no third wire for signaling the capacity of the power brick. I've operated the Flip from NiMH AA batteries (plus a boost regulator) and it is almost practical - you burn through an average of one cell per hour.

Scripts and Commands

Little odds and ends. These are designed to be as WM agnostic as possible. Most scripts require xosd and terminus-font installed.

Download the scripts from https://github.com/keenerd/c100p-tweaks/

/etc/modprobe.d/c100p.modules.conf - keeps wifi working

- keeps wifi working /etc/tmpfiles.d/c100p.backlight.conf - user permissions on the backlight

- user permissions on the backlight sudoers - a couple of passwordless commands (suspend and sddm)

- a couple of passwordless commands (suspend and sddm) c100p.bl-adjust.sh - quadratic ramp, takes "up/down" as an argument

- quadratic ramp, takes "up/down" as an argument c100p.tablet-mode.c - detects orientation and disables keyboard/touchpad, also requires xorg-xinput and compiling

- detects orientation and disables keyboard/touchpad, also requires and compiling c100p.vol-adjust.sh - takes "up/down/toggle" as an argument, also requires alsa-utils

- takes "up/down/toggle" as an argument, also requires c100p.status.sh - displays a bunch of system info

- displays a bunch of system info c100p.auto-suspend.sh - smartest idle detection yet, also requires xprintidle



Controlling the battery charge limits is done between sudoers and bashrc with the charge_current alias and the charge_until function. The charge_current requires the ec-utils package and sets how many milliamps flow into the battery during charging. The default value is 3456 and setting it to 0 will disable battery charging. Other small numbers may be useful for a gentle slow charging or using a smaller DC adapter. For example, reducing the current to 590 milliamps means you could charge the laptop (while off or suspended) from a USB port with a boost converter. The charge_until function takes a number between 0 and 100 and stops charging the battery when that percentage is reached. By never taking the charge over 80% for normal use I hope to greatly extend how many years the non-replaceable battery will last.

Suspend has some minor wonkiness. First, closing the lid will generate a wakeup event. A small delay is needed if you are manually triggering suspend. And then during the wakeup, the touchpad always generates a drag event towards the upper right corner of the screen. I handle both of these with an alias in ~/.bashrc

alias suspend="echo 'Five seconds!'; sleep 5; xinput -disable 'Elan Touchscreen'; sudo systemctl suspend; xinput -enable 'Elan Touchscreen'"

The c100p.auto-suspend.sh script requires a little explanation. I really don't like my computer entering suspend at a bad time. Closed the lid? I don't want to lose my wifi connection. Simple X11 idle time? Maybe I'm not in X. Or I'm compiling a build, downloading updates, etc. So the auto-suspend checks a half a dozen criteria every minute. After several minutes of idleness it blasts a warning across the screen. And one minute after that it finally enters suspend. Note that there is no way to detect idle time on the TTY. To hack around this, adjust your ~/.bashrc with PROMPT_COMMAND="touch /tmp/.bashidle" and the last-modified time of that file will be a proxy for tty idle time. (Obviously this has flaws if you simply stay in one program like emacs instead of your local shell, adjust accordingly.) ZSH requires further hackery for the equivalent.

A bit of background on the c100p.status.sh script; I grew up with floppy-based computers that barely had an operating system, where you could listen closely and hear every single twitch the machine made. And when Windows came around, I was running it on very underspecced systems. So it was natural for me to keep an eye on everything with TinyResMeter. Cleaning up errant processes required constant vigilance. So when I moved to Linux, I immediately put together a sweet Conky setup. But over the years I've realized that Linux was pretty amazing at resource management. I didn't need to be vigilant, the OS was. And then I realized the system monitor might be chewing up 10% of my CPU with the constant updates and graphical shininess. And providing a useless distraction of flickering numbers. The eventual evolution of system monitoring has left me with the status script. It only pops up when I am curious and hit the keybind for it. (On the Flip it's bound to the goofy dedicated lock button.) It is not very efficient code with lots of bash shelling, but it runs so rarely as to hardly matter. On computers with much shorter battery life I usually compliment it with a periodic alarm script that sounds the klaxons when approaching a dangerous status, but I have not felt the need to do that here.

Future and Things to Fix



Mainline kernel. I hear the veyron stuff is on track for being mainlined. I hope many of the below issues will magically go away on that day.

HMDI output. Very wonky, usually crashes X11 after a few minutes.

Xrandr screen rotation. Errors with cannot use rotation "left" .

. USB ethernet. The cdc_ether module will load but nothing happens.

module will load but nothing happens. Webcam. Crazy bucket of fail here. Maybe 25% of the time fswebcam can grab a single frame. Good luck with video.

can grab a single frame. Good luck with video. Libreboot. The C100P is a basically the Asus C201 but dressed up in a nicer case. Hopefully Libreboot's efforts will be portable.

Multitouch on the panel. No idea how to get that working.

Alternative battery chemistry. Poking around ectool shows knobs to adjust parameters such that charging LiFePO4 might be possible. Though I'm not going to consider attempting this until the stock battery is thoroughly decayed.







Helpful Hardware Info

Specifically relating to the previously mentioned gaps.

Webcam:



/dev/video2 appears to be the device 1280x720 960x540 640x480 supported resolutions v4l2-ctl --list-formats -d /dev/video2 ioctl: VIDIOC_ENUM_FMT Index : 0 Type : Video Capture Pixel Format: 'MJPG' (compressed) Name : MJPEG Index : 1 Type : Video Capture Pixel Format: 'YUYV' Name : YUV 4:2:2 (YUYV)

Touchscreen: