background

The rM2's framebuffer is not well understood, but we know it requires a software thread (SWTCON) to drive it. This thread runs with high priority and is responsible for using data from a memory location to drive the contents of the display.

We are able to get access to the framebuffer update APIs by using LD_PRELOAD while loading the remarkable-shutdown binary and hardcoding their memory addresses. The update API is similar to the way the rM1 updates: it takes a rectangle and a few arguments (like waveform_mode) and updates the display.

We propose using a client/server model for interacting with the framebuffer, instead of each applications starting its own SWTCON. (supernote a6 uses a similar design: only one process interacts with the framebuffer and the rest use IPC to communicate with it.)

proposal

• have a server process that drives the SWTCON. It opens a shared memory location (/dev/shm/swtfb) and listens over IPC for clients to invoke the update API.
• client process can write to the shared memory location and then invoke the IPC API to tell the server which region to update and any additional flags.

Underlying technology:

• use shm_open (POSIX) shared memory
• use msgrcv/msgsnd (SysV) message queue

remarks

advantages of using a server/client model

1. the LD_PRELOAD method is fragile and is awkward to launch, isolating that technique to one place will make it easier to manage
2. easier for different languages to interface with - they only need to make IPC calls
3. with a client/server API for the framebuffer, we are opening up the path to supporting split applications.
4. with shared memory, the framebuffer can be screenshotted easily. if each application uses its own SWTCON, they have to expose their framebuffer's memory for screenshotting

potential pitfalls

1. the API across IPC needs to be stable or upgradeable so that rm2fb doesn't have mismatches with client versions
2. we are creating extra headache by having to create and maintain a server
3. we might not achieve low latency drawing if we use IPC
4. what's the point of server/client? what will you do when SDK comes out?

open questions

1. do all clients share the framebuffer memory or does each client request its own?
2. do we deal with input sharing now or later?
3. what does API look like?

prototype

see master branch