reStream pipes a reMarkable framebuffer over SSH into an ffplay window
Stream your reMarkable screen over SSH.
At a glance
- What is it?
- reStream is a small Rust program with a shell wrapper that turns a reMarkable tablet into a screen you can watch on your desktop, by pulling the framebuffer over SSH, compressing it with lz4 and piping it to ffmpeg. It runs on the tablet as a static ARM binary and on the host as a shell script, and the transport is the same SSH session you already use to reach the device.
- Who is it for?
- reStream fits someone who wants to view or record a reMarkable screen from a laptop, or to expose the tablet as a webcam to a meeting application, and who already has SSH access to the device. Skip it if you need the same from a tablet model the project does not list, if your environment blocks SSH to the device, or if unencrypted transport on your network is not acceptable.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 136 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A screen for a device whose screen you cannot reach
The reMarkable is an e-ink tablet, and the reason this project exists is that the device's display is not a normal screen you can capture. There is no desktop environment to run a screen recorder on, no video output, and no easy way to mirror what is drawn on the panel to another machine.
reStream's answer is to read the framebuffer on the device, push it across an SSH connection, and render it locally. The README calls it reMarkable screen sharing over SSH, and the repository topics name the moving parts: framebuffer, ffmpeg, video4linux-loopback and remarkable-tablet. The README also carries badges saying the rM1 and the rM2 are supported.
The audience is narrow and clear. It is someone who develops on the tablet, or who wants to show a document or a sketch to a room from a laptop, or who wants the tablet to appear in a video call as a camera. The demo animation in the repository is a screen popping up on the host with a live view of the tablet, which is the whole product in one image.
The interesting design decision is that the transport is not a new protocol. It is SSH, which the tablet already exposes for development access, which means the same key that lets you run commands on the device also carries the video. That choice removes an entire class of setup work and introduces a bandwidth ceiling that the options list spends a lot of words addressing.
A host script and a static ARM binary on the tablet
The project ships as two pieces, and the README is precise about the split. The `reStream.sh` file is the executable on the host, and `restream.arm.static` is the binary that has to be moved to the reMarkable and renamed to `restream`.
The tablet-side program is Rust. The manifest in the repository names the package `restream` at version 1.5.0, using edition 2024.
name = "restream"
version = "1.5.0"
edition = "2024"Its dependencies tell you what the program actually does. `libremarkable` at version 0.7 with the `input` feature enabled is the library that talks to the reMarkable, and it is the piece that knows how to read the device's framebuffer and how to deliver input events. `lz-fear` is a pure Rust implementation of the lz4 compression format, used to shrink the framebuffer data before it goes down the wire. `clap` 4.5 with the derive feature is the command line parser, and `anyhow` handles error propagation. The `input` feature matters for anyone who wants to write back to the tablet while streaming, since the feature is what makes that path available at all.
The static binary is the reason installation is simple on the device side. It carries no dynamic library requirements, so it runs on the tablet without a package manager having to be involved.
On the host, the shell script is what the user runs, and the README's option list is the script's own interface, with the framebuffer data ending up in ffmpeg or ffplay. The host requirements are a POSIX shell, ffmpeg with ffplay, ssh and lz4.
Getting onto the tablet, four documented ways
The install section is unusually complete, and it covers the part that usually goes wrong, which is getting the binary onto the device.
The first path uses vellum, if you already have it, and the command runs on the tablet over SSH.
$ ssh [email protected] 'vellum add restream'The second uses toltec instead, with its own package command.
$ ssh [email protected] 'opkg install restream'The third downloads the binary directly, which the README says requires internet access on the reMarkable.
$ ssh [email protected] 'wget https://github.com/rien/reStream/releases/latest/download/restream.arm.static -O /home/root/restream && chmod +x /home/root/restream'The fourth is the manual route, copying the file to the host first and then pushing it across with scp.
$ scp restream.arm.static [email protected]:/home/root/restream
$ ssh [email protected] 'chmod +x /home/root/restream'On the host, the script is downloaded from the releases page and made executable.
$ chmod +x reStream.shThe README also gives a tip for people who prefer a command on their path. If you save `reStream.sh` in a path directory as `reStream`, you can launch it by that name, and the example shows installing it into `/usr/local/bin` as root with a wget and a chmod.
The usage section is short. Connect the tablet with the USB cable, make sure an SSH connection works, run `./reStream.sh` in the script directory, and a window appears on the local machine with a live view of the reMarkable.
The option list is where the engineering shows
The options are what separate a proof of concept from something people use daily, and the README lists them in full.
- `-h --help`: show usage information
- `-s --source`: the ssh destination of the reMarkable (default: `[email protected]`)
- `-o --output`: path of the output where the video should be recorded, as understood by `ffmpeg`; if this is `-`, the video is displayed in a new window and not recorded anywhere (default: `-`)The `-p --portrait` option switches the display to portrait orientation, since the default is the screen rotated 90 degrees to the right. The default source of `[email protected]` is the tablet's address on the USB network, which is why the setup instructions talk about connecting the USB cable. The output option is the bridge to the recording side of the project, since a dash means display only, and any other value is passed to ffmpeg as an output path.
The `--webcam` option is the most unusual. It records to a video4linux2 webcam device, and the README says the video is scaled to 1280x720 to keep it compatible with MS Teams, Skype for Business and similar programs. The companion `--mirror` flag exists because those applications mirror the camera by default, and the flag restores the correct orientation.
Then there is `-m --measure`, which uses `pv` to report how much data throughput you have, and the README says explicitly that it is good to experiment with parameters to speed up the pipeline. That is a hint about the real constraint of the project, which is bandwidth, not CPU.
And there is `-u --unsecure-connection`, which sends framebuffer data over an unencrypted TCP connection, giving more frames per second and less load on the reMarkable, with netcat as the extra dependency. The speed gain is bought by giving up encryption on the video path, and the README asks for the eye to be open about that.
Turning the tablet into a webcam needs a kernel module
The webcam path is not self contained, and the README treats the missing piece honestly. To present the reMarkable as a camera you have to fake a capture device, and the tool for that is the Video4Linux Loopback kernel module, which the repository topics also list.
The installation needs the dkms and util packages, and the README gives the Ubuntu command.
# apt install v4l2loopback-utils v4l2loopback-dkmsIt notes that some package managers ship `v4l2loopback-utils` under the name `v4l-utils`, which is the kind of detail that saves an afternoon. The module then has to be enabled, and the check is a device listing.
# modprobe v4l2loopback$ v4l2-ctl --list-devicesThe README says the output of that listing should contain a line with `platform:v4l2loopback`. If it does not, the module is not loaded, and the webcam option will not find a device.
This is the point in the project where the host stops being a normal Linux or macOS machine. A kernel module, a device node and a 1280x720 scaling step are involved, and on a machine where you cannot install kernel packages the `--webcam` route simply is not available, leaving only the window display and file recording paths.
The netcat dependency for the unencrypted transport is the smaller of the two extra requirements, and it is listed in the same extra dependencies section.
Release history, licensing and what the tablet side demands
The project is MIT licensed, with the licence text in the `LICENSE` file at the top of the tree, which is the permissive end of the scale for a tool you run on your own machine.
The release history has three entries in the record. v1.3.1 was published on 2024-01-10, v1.4.0 on 2026-01-05 and v1.5.0 on 2026-06-10, and the last push was on 2026-06-10 as well. The gap between 1.3.1 and 1.4.0 is two years, and the gap from 1.4.0 to 1.5.0 is five months, so the cadence is irregular rather than predictable.
The manifest and the dependency versions are the concrete picture of the maintenance burden. Edition 2024 in the Cargo manifest means a current Rust toolchain, `clap` 4.5 and `libremarkable` 0.7 are the moving parts, and the repository ships both `flake.nix` and `shell.nix` alongside a `flake.lock`, which is a reproducible development environment for a Rust and shell project.
The tablet side has a constraint that shows up in the install steps rather than in the code. The README notes that the reMarkable 2 does not support ed25519 keys, and suggests generating an ecdsa or rsa key in that case. That is a small sentence with a large practical effect, because a key that the tablet will not accept looks identical to a network problem, and the verification step in the README is the thing that distinguishes them. The check is to try `ssh [email protected]` and confirm that it does not prompt for a password.
The other prerequisite worth naming is lz4 on the host, which the README installs with the usual package manager, and on Ubuntu with `apt install liblz4-tool`.
Editorial conclusion
reStream fits someone who wants to view or record a reMarkable screen from a laptop, or to expose the tablet as a webcam to a meeting application, and who already has SSH access to the device. Skip it if you need the same from a tablet model the project does not list, if your environment blocks SSH to the device, or if unencrypted transport on your network is not acceptable. Verify first that your key type is accepted by the tablet, since the reMarkable 2 does not take ed25519 keys, and check the frame rate on your own link before relying on the unencrypted option.
Frequently asked questions
What does reStream need on the host and on the reMarkable?
On the host it needs a POSIX shell, ffmpeg with ffplay, ssh and lz4, plus the Video4Linux Loopback module if you want the webcam option and netcat if you want the unencrypted connection. On the tablet it needs the `restream` binary, copied over as `restream.arm.static` and made executable.
How do I get the restream binary onto a reMarkable tablet?
The README lists four ways: install via vellum with `vellum add restream`, install via toltec with `opkg install restream`, download it directly on the tablet with wget if it has internet access, or copy it from your host with scp and then chmod it executable.
Why does my SSH key not work with my reMarkable 2?
The README states that the reMarkable 2 does not support ed25519 keys, and advises generating an ecdsa or rsa key instead. The check is to run `ssh [email protected]` and confirm that it does not prompt for a password.
Can I record the reMarkable screen instead of just viewing it?
Yes. The `-o --output` option takes a path as understood by ffmpeg, and any value other than `-` records the video to that path instead of only displaying it. The `-f --format` option can force the encoding format, otherwise ffmpeg detects it from the file extension.
What does the --unsecure-connection option do in reStream?
It sends the framebuffer data over an unencrypted TCP connection instead of SSH, which the README says results in more frames per second and less load on the reMarkable. It requires netcat on the host, and the trade is that the video path is no longer encrypted.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/rien-restream)Was this useful?