doesn't work with timower's rm2fb
HookedBehemoth opened this issue · comments
Presumably because it switched from message queues to unix sockets and libremarkable has it's own IPC code instead of using rm2fb-client.so.
https://github.com/timower/rM2-stuff/tree/master/libs/rm2fb
Uses UNIX sockets instead of message queues. Makes it easier to implement synchronized updates.
thread 'main' panicked at 'Failed to open swtfb shared buffer: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libremarkable-0.6.2/src/framebuffer/core.rs:128:18
I'll look into it further.
It sounds like timower's rm2fb broke backwards compatibility with apps and should re-add message queue support for older clients.
I'm not aware of his library, but yeah our default behaviour for the Gen 2 model is to use our own client. It should offer all the same functionality as the official rM2FB shim while making it more clear to developers that they're using one and giving them more control.
However that means that updates to rM2FB could break existing binaries with libremarkable and had been noted by rM2FB developers before.
If timowers rm2fb is acting like a shim and using different means to communicate with its server, that would certainly confuse libremarkable as it would behave like the official rM2FB shim, but not find the correct server via it's usual means.
In this case you can, as the app developer, choose to use the old method even on the rM 2. For that use the constructor Framebuffer::device instead of Framebuffer::new and it should work better on the rM 2 then and resolve your issue. You can get the parameter for device() from device::CURRENT_DEVICE::get_framebuffer_path or just look at the source code for the new() function mentioned above.
re-implementing the rm2fb protocol in libremarkable seems very fragile. As soon as the protocol changes apps will start to fail.
re-implementing the rm2fb protocol in libremarkable seems very fragile. As soon as the protocol changes apps will start to fail.
Which is why the intention would always be to support the older protocols until a major version change where you drop the old protocols, at which time apps would all have to be updated. My understanding is that the rm2fb client shim was originally intended to just get the rm1 apps to work, but provide an API to interact with the rm2fb-server, which would continue to work between releases.
Yeah... thinking of the long term, I'd much rather have a protocol that was intentionally designed / is controlled by the community than one that's an ad-hoc reverse-engineering of an protocol that rM itself decided to migrate away from four years ago!
That said - very cool if users can override the default. Agree with @LinusCDE - the ability to explicitly choose the old protocol in an app is good, and the env var in the linked PR seems even better.