a site about remarkable app dev

Current Status

input device compatible see oxide#48
battery compatible see oxide#48
framebuffer compatible rm2fb

as of 01/01/21, most rM1 apps have been verified as working on the rM2

see rmkit#34 for rmkit’s progress in specific.

Input Device

The input devices are mostly the same, just linked differently. event0, event1, event2 are no longer mapped in the same order. Now it is recommended to query the ioctl of the devices to detect if they are a touch, stylus or button input.

Alternatively, you can detect if the device is a rM2 and hardcode the correct paths to open.

See oxide#48 for relevant discussion


The battery lives in a different path in the /sys/ virtual filesystem, see oxide#48 for discussion



rm2fb package has been accepted into toltec repository and should mostly work out of the box


the last puzzle piece, xochitl, was solved by timower : now the client shim works with xochitl so that xochitl and homebrew apps can co-exist.


We’ve been experimenting with SWTCON and whether it makes sense to run one SWTCON per process or have a server/client model. So far, signs are pointing towards a server/client model with IPC.

Using the IPC prototype in rm2fb, rmkit apps now work on rM2, (see comments here), including remux and harmony but there is still work to do to make them place nice with xochitl.


For a demo of drawing to framebuffer see this repo


Currently, the framebuffer is not well understood. Based on bokluk’s work, there are several observations:

The goal is to understand how to draw to display which will likely consist of several parts:

Methods used to come to above conclusions