Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow disabling the automatic use of our internal swtfb client by setting an env #118

Merged
merged 3 commits into from
Jul 26, 2024

Conversation

LinusCDE
Copy link
Collaborator

There was an issue raised at #117 where presumably a new library is used as a shim for rM 2 Framebuffer support, but it doesn't seem to use the offical server, which our client relies on.

In general there had been issues raised that issues could arise even with the official shim if it gets updated but our implementation still does the old behaviour. Such applications would require to be recompiled to use Framebuffer::device instead of Framebuffer::new or otherwise not work.

This PR allows people to make libremarkable choose the old implementation in case the developer didn't care about it anyway / left the choice up to libremarkable.

It is done by setting the lengthy env LIBREMARKABLE_FB_DISFAVOR_INTERNAL_RM2FB to 1, yes or true (case-insensitive). Feel free to suggest a better name, I couldn't think of any.

Package maintainers could also fix arising issues by setting that env in some wrapper script for that binary without the need of any source code change or even re-complication if the binary is recent enough.

Basically this should future proof applications built using libremarkable better.

…ct old way

This should ensure that binaries built using this version are fixable without
recompiling should issues with our current rm2fb client arise.
Sorry, but my pc has a billion toolchains and I'm not sure which one right now compiles correctly
@@ -50,7 +50,19 @@ impl Framebuffer {
let device = &*device::CURRENT_DEVICE;
match device.model {
Model::Gen1 => Framebuffer::device(device.get_framebuffer_path()),
Model::Gen2 => Framebuffer::rm2fb(device.get_framebuffer_path()),
Model::Gen2 => {
// Auto-select old method still if env LIBREMARKABLE_FB_DISFAVOR_INTERNAL_RM2FB is set affirmatively
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a mention in the README about this behavior plz?

src/framebuffer/core.rs Outdated Show resolved Hide resolved
@fenollp fenollp merged commit 9191261 into canselcik:master Jul 26, 2024
1 of 7 checks passed
fenollp added a commit to fenollp/libremarkable that referenced this pull request Jul 27, 2024
fenollp added a commit to fenollp/libremarkable that referenced this pull request Jul 27, 2024
fenollp added a commit to fenollp/libremarkable that referenced this pull request Jul 27, 2024
fenollp added a commit that referenced this pull request Jul 27, 2024
* Fix compilation issue after #118

Signed-off-by: Pierre Fenoll <[email protected]>

* Fix compilation of hlua by switching to a temporary fork

Signed-off-by: Pierre Fenoll <[email protected]>

---------

Signed-off-by: Pierre Fenoll <[email protected]>
@Havner
Copy link

Havner commented Sep 5, 2024

Hi,

I can't get this to work as intended. Seems that libremarkable doesn't like rm2fb client. I've compile the demo and it works properly (through built-in client). But with this it doesn't work. Has anybody managed to make it work?

(Software 2.15, original rm2fb from toltec, not timower)

reMarkable: /opt/demo/ LD_PRELOAD=/opt/lib/librm2fb_client.so.1 LIBREMARKABLE_FB_DISFAVOR_INTERNAL_RM2FB=1 ./demo
thread 'main' panicked at src/framebuffer/core.rs:206:9:
FBIOGET_VSCREENINFO failed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
reMarkable: /opt/demo/ LIBREMARKABLE_FB_DISFAVOR_INTERNAL_RM2FB=1 /opt/bin/rm2fb-client ./demo
thread 'main' panicked at src/framebuffer/core.rs:206:9:
FBIOGET_VSCREENINFO failed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants