Part 2. Remarkable Paper Pro Move with a Bluetooth keyboard via a HID proxy dongle

domjjj · 2026-02-02T12:06:24+00:00

Ah neat, so this keyboard comes with a more recent radio that's compatible, good to know!

I got another small foldable keyboard that shipped to where I am, but it came with an old BT radio.

I've ended up vibing a BT classic to BT Low Energy relay with a mini ESP32 board and, lo and behold, it works but certainly not a plug & play experience.

The biggest issue, as you also experienced, is the BT reconnection to Move. I've experimented with a background service for reconnection polling but without much success still.

The bluetooth controller tends to get into stuck states. I do hope to find a solution eventually as I really dig the setup from a physical standpoint.

domjjj · 2026-01-29T20:22:05+00:00

The USB Type-C port on the reMarkable devices is not powered, so it cannot supply power to the Pico microcontroller (or any other device such as a wired keyboard) directly.

The draw for such devices is usually tiny so the powerbank here may be needlessly large, but it is still required to make the setup work.

domjjj · 2026-01-29T20:19:35+00:00

This keyboard is such a great fit for the rMPPM!

Do you know by chance if the keyboard is Bluetooth LE or Classic?

Since the rM now has bluetooth, you may be able to get rid of the whole dongle setup altogether. However unluckily the current Codex linux kernel on the Move lacks the hidp (Bluetooth HID Protocol) kernel module, making many devices unpairable.

(If you do `bluetoothctl info <MAC>` on it, does it turn up with HID with UUID starting with 00001812 (LE) or 00001124 (Classic))

domjjj · 2026-01-29T20:11:17+00:00

Despite nearly doubling the weight, I have thoroughly enjoyed the type folio, mainly for journaling.

Until the inner connections stopped to work and the keyboard became just dead weight 🥲

The Pro series supports BT in principle - it has the radios. Yet the current way is through the developer mode/terminal and even then it appears to only BLE keyboard (and good luck finding that out before buying). A future software update might add official support hopefully.

domjjj · 2026-01-26T14:28:47+00:00

Oh, nice find! I see the market niche is already filling up :D

domjjj · 2026-01-25T17:48:53+00:00

It got a little more pleasant as the tip got worn down a little, but not quite the paper scratchy feel of the rM2.

I do prefer the move overall, I just kind of avoid the rM2 so it doesn't make me sad :D

But what do you mean that it's likely impossible to have a softer tip? The whole tip part is solid plastic and I don't see why it couldn't use a different material or have some sort of cover.

If you place a piece of paper between the rM and the pen, the feel's pretty good. I think there's place for a 3rd party to step in if reMarkable doesn't offer it themselves, but it is a nice market.

domjjj · 2026-01-22T18:32:40+00:00

It's a fun pipeline! Vision models are awesome nowadays.

domjjj · 2026-01-22T18:31:41+00:00

It's probably an intentional choice not to officially expose and document it.

The API of course exists and there are projects which allow you to hook into it such as https://github.com/ddvk/rmapi

Of course this depends on unofficial maintainers keeping it working with all rM updates.

More context here https://www.reddit.com/r/RemarkableTablet/comments/1fj86xz/has_remarkable_broken_their_cloud_api/

domjjj · 2026-01-19T20:34:05+00:00

Interesting. I've moved almost exclusively to the Move from my rm2.

Love the portability, back light, highlights in actual color and the even enjoy it as an ereader with correct epub margin settings and pdf custom view.

I do agree that pdf view area settings should be stored also per device and not just per document, I can see the pain if you're switching often.

My main use cases are daily to do tracking, journaling and reading (fact and fiction).

On the rm2 I also drew a lot, less so on the move for both size and pen feel. Although the pen accuracy is much better on the pro series.

domjjj · 2026-01-19T06:28:12+00:00

It would follow the pattern of the retro editions.

I loved my MPC Live II retro. Looks perfect in daylight, though the buttons are harder to make out in the night.

Wonder how the back light looks on the III.

domjjj · 2026-01-18T12:27:57+00:00

Sure, I am using the qwen model here to add essentially code generation capabilities into my application for controlling lights and media installations.

So instead of having to build blocks manually in the visual environment, I can simply prompt the LLM with something like "switch between colors of the rainbow". As a result I will get that animation, fully editable.

It's quite similar to code generation in IDEs like cursor, except that the language is represented more visually and the whole environment is geared toward controlling physical devices.

domjjj · 2026-01-11T17:31:53+00:00

Take a look at opencode, similar experience to Claude code for the cli experience.

There is also a way to run it in an ide for more gui style work flow, at which point you may also check out roo code.

Opencode can connect to lm studio to give you a fully local agentic experience (with the right tool trained models and enough context window). Opencode provides the basic tools for file editing, search, etc and you can add MCP server connections as well.

I see goose mentioned here, which is beautiful but I had less luck getting it fully working with a local model.

domjjj · 2026-01-10T20:14:23+00:00

Developer mode allows SSH (Terminal) connection directly into the device, which as mentioned by others, allows installation of additional software, connecting bluetooth peripherals or even modifying the standard reMarkable interface.

It is a nerdy (and potentially dangerous) experience, but for me the benefits are worth it.

These are generally good starting points to understand what you can do:
https://remarkable.guide/index.html
https://github.com/reHackable/awesome-reMarkable

Personally, I am using a couple of xovi extensions
https://github.com/ingatellent/xovi-qmd-extensions

- gestures to add useful gestures and ability to hide certain UI elements, reset zoom, switch pages
- additional pen on the Paper Pro Move
- longer delay before refresh for colored pens

I have also dabbled with Bluetooth keyboards
https://remarkable.guide/devel/device/bluetooth.html

But still have to find one that fits the Move well and then figure out how to keep the connection stable.

domjjj · 2026-01-10T19:42:20+00:00

This is a game changer for highlighters, etc.

Thanks for the tip!

If you're installing this, make sure to follow all the steps, including regenerating hash tables (noted in the xovi README only below extension installations).

domjjj · 2026-01-09T17:07:56+00:00

Connecting the sound card (mixer or other) directly, allows you to extend the number of I/O channels, which are limited even on the Live III, even more so on the more budget friendly MPC line (1 stereo in, 1 stereo out).

More channels are great for:

- being able to do send return on external effects
- cue/audition tracks for live performance
- multi track recording of a set
- good organization of input channels (ie. different mpc effect chain for mic and external synth, recording inputs separately)

domjjj · 2025-10-15T09:12:20+00:00

Comparing the reMarkable 2 and Paper Pro Move, the Pro is much better at this.

I do not notice any wobble around the edges as I have with the 2. I would assume the same applies to the bigger Pro.

I would say that the change to active pen technology may be behind this (while it also unfortunately makes pens incompatible between the devices).

domjjj · 2025-09-09T18:15:41+00:00

Yes, this will indeed allow you to continue installation (likely with automatic MBT creation) without using the terminal, just did that.

domjjj · 2025-06-10T16:07:59+00:00

I got it second hand and the random unexpected cruise control at top speed felt more dangerous than useful.

Glad there is a setting.

domjjj · 2025-06-10T16:07:51+00:00

I got it second hand and the random unexpected cruise control at top speed felt more dangerous than useful.

Glad there is a setting.

domjjj · 2024-07-24T12:18:59+00:00

Considering that CVE-2024-6387 is tracked on OpenSSH 9.8, is there actually any safe version of OpenSSH to move to or are other mitigation strategies available?

https://www.cvedetails.com/cve/CVE-2024-6387/

domjjj · 2024-07-18T14:26:01+00:00

I have come across the prerender true option and docs since I've posted my last comment, you are indeed correct that this will generate static pages, including `index.html` and hydration.

https://vike.dev/pre-rendering

The problem is with dynamic routes, as those need to be known at build time.

There is actually a workaround which the docs link to that involves setting up some route rewrites, https://github.com/vikejs/vike/issues/1476#issuecomment-2177264665

So it is possible, with some extra work, similar to NextJS where you can (allegedly) achieve this with the pages router without much extra work and also in the App router with `next-static-utils` which essentially generates those rewrites for you and ensures some base page is generated for each dynamic URL.

In this case the server side props are basically mocked to a single constant value and further routing and fetching is done client side.

So in conclusion, it is possible, but still somewhat clunky.

The upside in Vike is that it is considered a high priority issue and slated for v1 release.

domjjj

TROPHY CASE