Doesn't work on rM2

[slowpoison]

I just got my rM2 and tried installing. Installation went fine, but I cannot seem to bring up the launcher.
For one, there's no home button.

[raisjn]

Thank you for opening the issue and for your patience while we figure out rM2 stuff! The code in this repo is not expected to work on rM2 until we figure out how to write to the framebuffer for rM2: https://rmkit.dev/news/rm2-status/

In terms of launching without the home button: when we get remux working on rM2, you can slide up the left or right side of the screen to launch it.

[raisjn]

also, congrats on your rM2 (and sorry rmkit isn't working yet - but it is only a matter of time)

[raisjn]

we have succeeded in drawing to framebuffer on rm2 (with help from others) - i think rmkit will be ported reasonably soon.

[raisjn]

made some progress using ddvk/remarkable2-framebuffer rm2fb IPC server (see ddvk/remarkable2-framebuffer#9).

video of mines

current issues:

• screen blanking is not working correctly (this prevents remux from being the best it can be) EDIT: this was actually a separate problem related to multiple SWTCONs running at once
• the code for rm2 support is quick hacks that require compiling specifically for rM2, need to actually fix rmkit code to be able to dynamically work on rM1 or rM2
• fast refresh (for drawing with pen) is not working yet
• can't peer into xochitl's memory yet

what works:

• drawing demo
• harmony
• minesweeper
• remux ( has some hiccups with drawing screen, but i can switch between xochitl and harmony and minesweeper correctly)

untested:

• nao package manager
• simple app script

[raisjn]

video of remux + mines + harmony + xochitl

still having trouble switching back and forth between xochitl and non-xochitl apps, but its only a matter of time.

[raisjn]

I like ddvk's solution: use a touch gesture to go from xochitl -> launcher and launcher -> xochitl. When moving between the boundary of launcher / xochitl, the SWTCON has to get restarted, but otherwise it looks pretty smooth.

One downside is that re-starting xochitl will lose your place in it (i think), so I'd like to work towards a solution that will not require restarting xochitl (perhaps just flashing the screen once or twice)

[tadfisher]

I've been thinking about replacing /dev/fb0 with a virtual framebuffer managed by a daemon, which could facilitate multitasking in a safe way by locking the device around framebuffer updates. I might be paranoid, but this would also allow for rate-limiting updates to prevent bricking the display.

[raisjn]

I've been thinking about replacing /dev/fb0 with a virtual framebuffer managed by a daemon, which could facilitate multitasking in a safe way by locking the device around framebuffer updates. I might be paranoid, but this would also allow for rate-limiting updates to prevent bricking the display.

sounds interesting. have you looked at rm2fb's architecture? It is also a server model (with a "daemon" managing the framebuffer) and clients interacting with the server through IPC. in the future, we'd like to replace the daemon's FB code with the open source FB code. it would be nice if we (anyone in the rM community) could collaborate here (either on the server model or on the open source SWTCON).

in term's of the client interaction, we started with an LD_PRELOAD shim for rM1 apps (good idea, @pgaskin!) (which creates a "fake" /dev/fb0 by pretending to be there), but @pgaskin also suggested a way of making a virtual /dev/fb0 using FUSE. there are probably even more ways to create the fake /dev/fb0, but whichever way is taken, i think it's worth pursuing creating a fake /dev/fb0

for batching (it's not paranoid!), i've tried two things:

1. putting large updates in their own thread (didn't work out well)
2. merging all dirty regions into one larger region when emptying the update queue, then running the update. requires keeping track of the highest quality waveform mode used. (this does work well to prevent flooding)

not sure if either were useful, it is hard to tell before we have fast drawing working.

[pgaskin]

The FUSE method would be the only way (other than a kernel driver, but then you're basically reinventing the wheel) to support the normal ioctls without having control over the actual applications (e.g. LD_PRELOAD or strace) AFAIK. If the fake /dev/fb0 doesn't support the ioctls, it's arguably worse than the LD_PRELOAD shim (note that it can be directly linked into static binaries if needed) or implementing the IPC directly in applications (which I wouldn't recommend in general, since it'll restrict the changes you can make in the future) since it'll look the same but act differently.

As long as the rm2 kernel supports FUSE, I'm pretty certain that idea will work well. The only thing which I'm not sure about are the implications of mmap via FUSE.

Regarding the LD_PRELOAD shim: I saw your comment about it being ready for review, and I'll be getting around to doing a full review as soon as I have time.

[raisjn]

which could facilitate multitasking in a safe way by locking the device around framebuffer updates.

I think I understand the context a little better now (after re-reading the thread): Would your proposal help with xochitl -> launcher and launcher -> xochitl? Or would it help in general for multi-tasking apps? (or both?). I had wondered about giving each client its own piece of shared memory (so they can't clobber each other) and when they talk to server, their updates come from only their shared mem.

Regarding the LD_PRELOAD shim: I saw your comment about it being ready for review, and I'll be getting around to doing a full review as soon as I have time.

uh oh - be gentle, please 🤕

[raisjn]

remarkable2 support is now available with rm2fb

the current binaries on build.rmkit.dev have rm2 support. we'll update this task when the toltec packages land in testing and stable