search

canselcik / libremarkable

The only public framework for developing applications with native refresh support for Remarkable Tablet
MIT License
616 stars 56 forks source link

Adding an orientation option? #121

Open FeDorDrolma98 opened 7 months ago

FeDorDrolma98 commented 7 months ago

Hello !

Would it be possible to add an orientation option to the libremarkable? I want to make an UI in landscape rather than in portrait. I didn't find any direct way (rotate seems interesting, but is currently only used to access the orientation?). It is the text element who is at stake here because we can modify easily the picture, but idealy, I think it would be better to modify all the coordinates (for ex as in this project : https://github.com/LinusCDE/plato)

Thanks in advance !

bkirwi commented 7 months ago

Allowing rotation for the text element sounds like a good idea, at least for 90 degree rotations.

What do you mean by modifying all coordinates? Plato uses libremarkable, so anything it does is possible using the library as-is...

LinusCDE commented 7 months ago

On plato, I translate the pixel coordinates manually when a rotation is used for the rM 2, because the shim does not support specifying a framebuffer rotation afaik.

For the rM1 it is possible to just set the rotation in some metadata, which I should do there as well. That approach is not very popular though. I think it can break/confuse launchers as they're always assuming portrait mode.

I'm not sure rn how much work it would be to have the elements rotate. Do you use the app with lua support or the framebuffer for ui work?

The orientation you mentioned indeed is only there for readouts and translating input coordinates to portrait. Would be an interesting idea to use the same mechanism to sw rotate all write_pixel calls as well. Not too sure how that would then play together with the inputs.

Eeems commented 7 months ago

For the rM1 it is possible to just set the rotation in some metadata, which I should do there as well. That approach is not very popular though. I think it can break/confuse launchers as they're always assuming portrait mode.

Not just launchers, but also other applications that might be running at the same time. Nothing has been designed to support the framebuffer being rotated, so it's probably best not to use it, especially if you want to target the rM2 as well.

FeDorDrolma98 commented 6 months ago

On plato, I translate the pixel coordinates manually when a rotation is used for the rM 2, because the shim does not support specifying a framebuffer rotation afaik.

Oh I see tks. I didn't read in detail your plato app, I thought you did something like that haha. But since it is mainly the text which is problematic, it is maybe overkill to do more.

I'm not sure rn how much work it would be to have the elements rotate. Do you use the app with lua support or the framebuffer for ui work?

I use the framebuffer for ui work

The orientation you mentioned indeed is only there for readouts and translating input coordinates to portrait. Would be an interesting idea to use the same mechanism to sw rotate all write_pixel calls as well. Not too sure how that would then play together with the inputs.

Didn't thought of the inputs, what are you worry of exactly?