I am using (and recommending) my reMarkable tablet for a few months now. The display is just lovely, crisp and responsive and I am one of the few lucky ones receiving it in the first badges that came out.

As a good user, I am not complaining (often) publicly about the bugs I stumbled up (and reported) and expect most of them to be fixed soon, even after 3 months without any software updates seen. Just be aware that convenient data import/export is still a big problem for Android + Linux -only users, you will have to stick to plugging in a USB cable and using the (beta) web app.

Anyway, one of the exciting features of the reMarkable is that it comes with a full running Linux (4.1.28) and enabled root SSH access - thanks to the GPL :)

remarkable: ~/ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 10 (v7l)
BogoMIPS : 48.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
Hardware : Freescale i.MX6 SoloLite (Device Tree)

remarkable: ~/ uname -a
Linux remarkable 4.1.28-zero-gravitas-01897-g7f82abb869aa-dirty #256 Tue Sep 12 08:53:59 CEST 2017 armv7l GNU/Linux

This blog post is exploring what we can do beyond the GUI-facing part of the device (e.g. to fix bugs and add missing features).

I am not trying to reverse engineer the features in hardware and software that make this tablet superior to anything I saw on the market. You can read more on that on HN by their CTO, which also contributed in the past to FOSS projects such as KDE.

My primary interest is more usable data exchange and (way better) data archiving & meta data of my (scientific) work on it. On a personal side node, I think it would increase the reMarkable’s market value if a documented API for efficient drawing and open file exchange (both accessing to their cloud and documenting the internal file formats) would be made public. Especially the last aspect should be better sooner than later, since the created data of the user (hopefully is) and should never be relevant for their successful hardware project.

Note: This blog post might be updated on the go in the future.

Home Structure

If one first logs in one finds oneself as uid=0 (root) on /home/root. The first things to hop on are the directories and config files within it, cat, less and vim are pre-installed.

.config/ for xochitl

  • wifi pws
  • serial number
  • settings from UI
  • ssh login
  • left/right handed
  • last emails used for “share”
  • device token


Individual PDFs, epubs(?) and reMarkable notebooks

remarkable: ~/ ls /home/root/.local/share/remarkable/xochitl/


Besides some json meta files, most of the files are some binary format. Understanding these would be wonderful to truly control ones data! Unfortunately, I have not seen anyone trying to document it yet.

Update December 19th: ok, I decoded the .lines file now :) A blog post will follow!
Update December 26th: and here the .lines format is!

Last but not least, one can also add the usual Linux stuff. For example just add your key to .ssh/authorized_keys for pwless login.

Wifi Beyond the GUI

By default, connecting to a WPA-EAP network (“WPA-Enterprise”) such as Eduroam is not possible throughout the GUI. This is especially bad for academic users. Since wifi is controlled via the well-established “wpa supplicant” tool let us change this!

Append to /etc/wpa_supplicant/wpa_supplicant-wlan0.conf (example for TU Dresden):


Add command line option to /lib/systemd/system/wpa_supplicant@.service:

ExecStart=/usr/sbin/wpa_supplicant -C/var/run/wpa_supplicant -i%I
ExecStart=/usr/sbin/wpa_supplicant -C/var/run/wpa_supplicant -i%I -c /etc/wpa_supplican

It still does not auto-connect yet, but if you restart wpa_supplicant it connects:

systemctl daemon-reload
systemctl restart wpa_supplicant@wlan0.service
  • https://tu-dresden.de/zih/dienste/service-katalog/arbeitsumgebung/zugang_datennetz
  • https://www.lrz.de/services/netz/mobil/802_1x/802_1x-linux/
  • https://www.cms.hu-berlin.de/de/dl/netze/wlan/config/eduroam/linux


The reMarkable supports drawing in up to five layers on PDFs and creating “notebooks” with individual “templates” as background. Templates are straight PNGs parsed from a directory and the filename.

remarkable: ~/ ls /usr/share/remarkable/templates/
Blank.png                 LS Week US.png            P Grid top.png
Isometric.png             LS Week.png               P Lined bottom.png
LS Checklist double.png   Notes.png                 P Lined heading.png
LS Checklist.png          P Black dots.png          P Lined top.png
LS Dayplanner.png         P Black grid.png          P Lines large.png
LS Dots bottom.png        P Black lines.png         P Lines medium.png
LS Dots top.png           P Black.png               P Lines small.png
LS Four storyboards.png   P Checklist.png           P Margin large.png
LS Grid bottom.png        P Cornell.png             P Margin medium.png
LS Grid margin large.png  P Day.png                 P Margin small.png
LS Grid margin med.png    P Dots S bottom.png       P One storyboard.png
LS Grid top.png           P Dots S top.png          P Two storyboards.png
LS Lines bottom.png       P Dots S.png              P US College.png
LS Lines medium.png       P Dots large.png          P US Legal.png
LS Lines small.png        P Four storyboards.png    P Week 2.png
LS Lines top.png          P Grid bottom.png         P Week US.png
LS Margin medium.png      P Grid large.png          P Week.png
LS Margin small.png       P Grid margin large.png   Perspective1.png
LS One storyboard 2.png   P Grid margin med.png     Perspective2.png
LS One storyboard.png     P Grid medium.png
LS Two storyboards.png    P Grid small.png
PNG image data, 1404 x 1873, 8-bit/color RGBA, non-interlaced

By adding two additional files I successfully added two new templates. I added two landscape variants of the portrait Notes.png with -33% and -50% line height.

One good further thing could be a bullet journal template (if I ever understand how it actually works.) What the template selection needs in general are thumbnails for faster loading and grouping by topic, which we can not influence at this point. It is also worth noting that one can adjust the splash, sleep and empty battery screens under /usr/share/remarkable-shutdown.


This is the main app of the reMarkable, which is started by systemd. Like all the (user-facing) software related to the product it is written in Qt 5.9. Under remarkable.engineering you can even find a pre-bundled SDK to develop your own apps.

Realistically, you can already build and run other Qt apps that view things, but drawing without reusing their own specially-crafted low-latency API will not be fun.

Anyway, if one likes to dig deeper: checking the shipped libraries for Qt5 might be worth investigating for APIs in case they never will be documented:

remarkable: ~/ ls /usr/lib/qt5/plugins/platforms/
libepaper.so      libqlinuxfb.so    libqminimal.so    libqoffscreen.so

From a first quick analyze of the app via strace it might be a bit suboptimal that xochitl calls clock_gettime a dozen times a second and tries to access quite a few not-shipped library files during its usual execution. Room for improvement I guess, especially for battery lifetime.

Web UI (Beta)

Allows to download all files as PDF and upload new files (PDF, epub) by just drag-and-dropping on the browser window. This functionality is also part of xochitl the same way as the file conversion is. After enabling it in the settings page (rM - Storage - Enable USB web interface) and DHCP-ing the new USB ethN device it is reachable at

I was always wondering why the PDFs via share and download are so extremely large for simple drawn notebook pages. It turns out it is likely that the conversion to PDF is still rather hard-coded (strace again) and uncompressed:

# many lines
1043  write(35, "<<\n/Type /Pattern\n/PatternType 1"..., 16168) = 16168

# few lines
1043  write(35, "/Pat24782 24782 0 R\n/Pat24783 24"..., 16380) = 16380
1043  write(35, "/Pat25601 25601 0 R\n/Pat25602 25"..., 16380) = 16380

This explains the dramatic size of the created PDFs (easily a dozen MB for a sketch). It would actually be very nice if a cmd line tool and/or API exists for those conversions as well.

Other apps

Other apps running by default (from /usr/bin) are

  • update_engine (relatively quiet)
  • crashuploader in /home/root (relatively active)

Of course, you never agreed to the crash collection and report uploading beforehand. Ouch.

Update 2018-01-05: Asked the support about crashuploader. They responded that “[t]he data collected contains no identifying data” and can be disabled in systemd via systemctl disable crashuploader && systemctl stop crashuploader.

Without analyzing the network traffic yet, it is still calming to see a public key in /usr/share/update_engine/update-payload-key.pub.pem.

Cross Compile

I did not use the SDK on their homepage yet but had good success using dockcross for linux-armv7. Compiling powertop with it two months ago I still fund no missing tunable besides VM writeback timeout to improve battery life.

FROM dockcross/base:latest

# Add the cross compiler sources
RUN echo "deb http://emdebian.org/tools/debian/ jessie main" >> /etc/apt/sources.list && \
  dpkg --add-architecture armhf && \
  curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | apt-key add -

RUN apt-get update && apt-get install -y \
  crossbuild-essential-armhf \
  gfortran-arm-linux-gnueabihf \
  qemu-user \
  qemu-user-static \
  libbz2-dev:armhf \
  libexpat1-dev:armhf \
  ncurses-dev:armhf \
  libssl-dev:armhf \
  libnl-3-dev:armhf \
  libnl-genl-3-dev:armhf \
  libnl-utils:armhf \
  libpci-dev:armhf \
  pkg-config:armhf \
  autoconf \
  autogen \
  autotools-dev \
  automake \
  libtool \
  autopoint \

ENV CROSS_TRIPLE arm-linux-gnueabihf
ENV AS=/usr/bin/${CROSS_TRIPLE}-as \
    AR=/usr/bin/${CROSS_TRIPLE}-ar \
    CC=/usr/bin/${CROSS_TRIPLE}-gcc \
    CPP=/usr/bin/${CROSS_TRIPLE}-cpp-4.9 \
    CXX=/usr/bin/${CROSS_TRIPLE}-g++ \

# Tuned for reMarkable tablet:
#   Freescale i.MX6 SoloLite
#   ARM A9 CPU @1GHz (1 Core, Cortex A9)
#   model name : ARMv7 Processor rev 10 (v7l)
#   BogoMIPS : 48.00
#   Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
# evaluate:
#   -mslow-flash-data
#   -mfloat-abi=hard
ENV CFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -funsafe-math-optimizations -mthumb" \
  CXXFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -funsafe-math-optimizations -mthumb"

#ENV DEFAULT_DOCKCROSS_IMAGE dockcross/linux-armv7

# Note: Toolchain file support is currently in debian Experimental:
# https://wiki.debian.org/CrossToolchains#In_jessie_.28Debian_8.29
COPY Toolchain.cmake /usr/lib/${CROSS_TRIPLE}/

# build examples
#   powertop
#   ./autogen.sh
#   ./configure LIBNL_CFLAGS="-I/usr/lib/arm-linux-gnueabihf/libnl3 -I/usr/include/libnl3" LIBNL_LIBS="-L/usr/lib/arm-linux-gnueabihf -lnl-3 -lnl-genl-3"
#   make

Building more tools, it turns out that just installing a cross-compiler for ARM and a few multi-arch libs on Debian/Ubuntu is way easier:

# add multi-arch for "armhf"
# https://wiki.debian.org/Multiarch/HOWTO
dpkg --add-architecture armhf
apt-get update

# install C/C++ compiler and standard libs
apt-get install g++-arm-linux-gnueabihf gcc-arm-linux-gnueabihf
apt-get install libstdc++6:armhf libelf-dev:armhf

# compile something
arm-linux-gnueabihf-g++ main.cpp

Then copy over the created executable (and the dynamic libraries from the armhf packages above which it might be missing during execution) to your reMarkable via scp.

Referral Program

On Oct 4th, 2018 reMarkable started a program to get 85 Euro off and me 85 Euro cashback. So let’s give this a try, here is my referrer link: buy a reMarkable tablet (affiliate link)



/etc/version: 20170911122159

$ file xochitl
xochitl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=0f8759a2e5ad62bb4f16d3b64a54e2bbef0ab271, stripped