search

ddvk / remarkable2-framebuffer

remarkable2 framebuffer reversing
MIT License
276 stars 22 forks source link

Export client lib's init symbol #78

Closed fenollp closed 2 years ago

fenollp commented 2 years ago

cc https://github.com/canselcik/libremarkable/issues/65

matteodelabre commented 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.

fenollp commented 2 years ago

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

raisjn commented 2 years ago

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

raisjn commented 2 years ago

see https://github.com/ddvk/remarkable2-framebuffer/issues/11 for description of how the IPC works ("how to write an IPC client for rm2fb")

matteodelabre commented 2 years ago

@fenollp @LinusCDE Can we close this PR now that you are working on canselcik/libremarkable#78?

LinusCDE commented 2 years ago

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).