- 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
November 18, 2015: Now with charging limits!
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
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 * no charge limits on 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 the veyron kernel this hardware. It appears that the 3D driver is missing something that Chromium expects. 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 -
/etc/tmpfiles.d/c100p.backlight.conf
- user permissions on the backlight -
sudoers
- a couple of passwordless commands (suspend and sddm) -
c100p.bl-adjust.sh
- quadratic ramp, takes "up/down" as an argument -
c100p.tablet-mode.c
- detects orientation and disables keyboard/touchpad, also requiresxorg-xinput
and compiling -
c100p.vol-adjust.sh
- takes "up/down/toggle" as an argument, also requiresalsa-utils
-
c100p.status.sh
- 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. -
Webcam. Crazy bucket of fail here. Maybe 25% of the time
fswebcam
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.
* Charge limits. I'd really like to extend the life of the non-replaceable battery by limiting the peak charge to 70% or so. (With the option of pushing it to 100% when traveling, of course.) I've got some ideas but they are sufficiently dumb to not share while I iron out the bugs.
* 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.
Basic charge controlling is done, see charge_current
in the bashrc.
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:
can be disabled with
xinput -disable "Elan Touchscreen"
this reduces power consumption by 0.1W
no other information?
Supposedly the DC input can handle up to 19V. Not going to test this.