Closed fenollp closed 2 years ago
I think I understand the idea here, but I’m not sure using librm2fb_client symbols explicitly in clients is the best way forward. This lib is actually a bit of a misnomer, since it’s not only a client lib but first and foremost an rM1-compatibility shim meant for existing clients that do not know about rm2fb. It would be cleaner in my opinion to move the client API into a separate lib.
Yes I was half expecting this reply. The best way forward to me would be to produce a Rust version of said separate client lib so it can be easily depended upon by libremarkable.
Which parts of https://github.com/ddvk/remarkable2-framebuffer/blob/ae0da99d0f6d8e6d77c0dffcbab503dd50d985e4/src/client/main.cpp are actually needed to drive a rM2 (provided the server part is already in place)?
Thanks
Yes I was half expecting this reply. The best way forward to me would be to produce a Rust version of said separate client lib so it can be easily depended upon by libremarkable.
i'm a bit confused here - this is a shim, if you want libremarkable to directly work with rm2fb, you will probably only have to implement two pieces: opening /dev/shm/swtfb.01 and forwarding relevant ioctls on that FD to the rm2fb server using IPC. all that logic is contained in the init, open, open64, close and ioctl overrides in the file you linked
see https://github.com/ddvk/remarkable2-framebuffer/issues/11 for description of how the IPC works ("how to write an IPC client for rm2fb")
@fenollp @LinusCDE Can we close this PR now that you are working on canselcik/libremarkable#78?
I think so.
This was meant for binding directly to it, and we have abandoned this since the dependencies seemed way to complex to easily and portably integrate (integrating libstd++ and wt which seems to require libc would be very hard for musl builds).
cc https://github.com/canselcik/libremarkable/issues/65