reMarkable2 support

[yujikiriki]

From bordaigorl/rmview#22

For anyone interested, I am the author of the device side of the vnc branch. I unfortunately do not have a reMarkable2, and the fact that much of the framebuffer processing now happens in userspace makes the former solution for snooping on damage tracking information perhaps somewhat unfeasible. I do expect to take a look at trying to port the software with the assistance of others who do have rM2 devices over the next few weeks and would be happy to update here with the result should I find a solution.

[yujikiriki]

I'm interested in helping in any way possible as a owner of a rm2 and user of rmview. How can I help?

[sasozivanovic]

I'm a happy owner of rm2 and eager to help as well!

[pl-semiotics]

I'm happy to announce that rm2 support is here!

[raisjn]

Awesome, well done! I see that libqsgepaper-snoop is used which sends out damage info over unix socket. Does rm-vnc-server only rely on that damage info from the socket or is there more involved? If its only damage info, I feel like it would be quite easy to emit that same information from rm2fb server over a unix domain socket and it would be nice if we could support rmView (and the vnc branch) inside of rm2fb.

[pl-semiotics]

@raisjn rm2fb is currently working by using the libqsgepaper.a code inside remarkable-shutdown to drive the display, right? In this case the VNC server ought to work as it is, although I have not tested it---if it does not, please open an issue with a copy of the remarkable-shutdown binary you are using and logs. (I did take a quick look at remarkable-shutdown in ghidra while reversing xochitl, although I've been focused on xochitl---and it does appear to have the Qt metaobject that libqsgepaper-snoop uses to find things.)

If, in the future, we develop another swtcon driver---the server needs both the damage updates and access to the actual composited framebuffer (in libqsgepaper.a, this is originally mapped as MAP_ANONYMOUS|MAP_PRIVATE, so libqsgepaper-snoop has to go to some effort to yank that mapping out and replace it (without the other threads noticing) with MAP_ANONYMOUS|MAP_SHARED so that we can get it from another process), but that's all. The interface is in backend.h---basically, it needs a file descriptor that can be mapped to get a framebuffer at some offset, a file descriptor that is written to when a damage notification is available, and a function to retrieve a damage notification. It should indeed be quite easy to emit the necessary info!

[raisjn]

@raisjn rm2fb is currently working by using the libqsgepaper.a code inside remarkable-shutdown to drive the display, right?

yes, but there is xochitl and remarkable-shutdown running at once. i will open an issue on this

If, in the future, we develop another swtcon driver

there is at least one person writing a SWTCON driver, so this is good to know, thanks!

[pl-semiotics]

I'm going to go ahead and close this issue for now---feel free to open more if there are any specific issues like the rm2fb one!