Use with Qt

[AdamSLevy]

Is it possible to use this library with Qt frameworks for building UIs

[Ameb]

You can already use Qt framework for building UIs, since the reMarkable ships with the libraries. Check this example, and if you are using Qt Creator here is a guide. xochitl, the main interface of the reMarkable is made with Qt.

This library allows you to control the framebuffer directly. To use Qt with this library i think we would need a QPA (another link) plugin implementation using libremarkable.

[canselcik]

As @Ameb pointed out, if you wanted to use Qt framework to build the UI and have it draw all UI elements on the framebuffer abstracted away by libremarkable, a Qt Platform Abstraction would be needed. You could also choose to use Qt framework to draw the UI elements and utilize libremarkable in your application to perform only the low latency drawing.

xochitl already comes with a QPA that's statically linked with it. It is not documented however by looking at the interface it provides, it looks like it would be similar to how one would use libremarkable.

Here is the interface for xochitl's libqsgepaper.

And here is the binary in case someone wants to load it up in IDA or link against it.

[AdamSLevy]

Thank you both so much for these replies and for your work on this library. I just got the remarkable tablet and see a ton of potential in the hardware but I am a little disappointed by the stock software.

It really is unfortunate that they didn't open source their software because no doubt the efforts made on this library could have also taken the existing software to new heights.

I want to build better applications for the tablet. I have experience with Qt but from an example I saw elsewhere the refresh/response time using the Qt libs they provided is a little slower than their proprietary application, and even a small delay can affect usability and enjoyability.

Am I correct that if a QPA was built around this library, that refresh rates could be improved?

Am I off base here? I'm brand new to rust and have limited experience reverse engineering binaries. However I understand the basic concepts.

[canselcik]

You're welcome. It's been a pleasure working on this platform: understanding and documenting it to create an alternative open implementation to which people from all over the world want to contribute is the reward on its own. :)

That being said, Remarkable is extremely open-source friendly. The platform is wide open and the founders are true open-source veterans. The only thing that would make this device more open-source friendly would be if they open sourced xochitl or at least provided usage documentation for their libqsgepaper. However since we both are abstractions of the same platform, there are a lot of parallels.

Am I correct that if a QPA was built around this library, that refresh rates could be improved?

Yes, that is correct. When you use Qt without any such specific abstractions, it utilizes a one-size-fits all approach to drawing on the display/framebuffer, which doesn't yield great results on a display behind an EPDC.

Slightly off tangent but theoretically you could even get X11 on the device (use bitbake to cross compile with all dependencies) and create a simple companion program in Rust with an infinite loop that just sends the framebuffer MXCFB_SEND_UPDATE with arguments to quick refresh the entire framebuffer. This would allow you to even be able to use a window manager with limited framerate.

I would recommend looking into the libqsgepaper interface if you want to create a QPA. You would probably end up creating a QPA wrapping around libremarkable and using its most essential features.

[LinusCDE]

You could technically do this with in combinations QT crates. Not sure how a custom epaper backend would look like though and whether it would have significant advantages to the default one contained in the toolchains.

For building current QT stuff, you need to make sure to use a current toolchain. Oecore will likely not run anymore due to outdated QT libs used in it. The most recent toolchain should always be available here and integration with rust will be similar to the examples with oecore.

As long as anyone is crazy enough to attempt this, I doubt it would be of significant benefit to actually do the integration here.

[LinusCDE]

For now I think this won't be happening anytime soon. Feel free to ask follow-up questions. If things progress on this and someone is willing to try to add some kind of QT-Integration we can re-open this issue or make a new one.

I doubt this will be happening anytime soon though. So closing this for now.