canselcik / libremarkable Goto Github PK

Ideally, I'd like to pop up a calculator widget upon gesture recognition, so to avoid disrupting the current flow, I'd like to capture what's actually on the hardware framebuffer while starting the app, and use that as a background image. So, is it possible to:

1. Capture the hardware framebuffer before it's actually messed up by the application?
2. Start the application without flashing the screen (so it's not disturbing)?

Hi! Thanks for all the work you've done on this library. I spent the day trying to make sense of it on an Apple M1 chip. I thought it would be easier since the ARM architecture seems to run through it all. Unfortunately, the scripts for the toolchain installation all require an x86_64 architecture. I spent some time googling. When I didn't find much, I just jumped into creating an x86_64 development container in VS Code using docker desktop for Mac. I got pretty far but couldn't make it work out in the end. I've made the repo for this public if anyone wants to take a look.

GioCirque/harmonizers

I would appreciate any pointers, and would be willing to author an Apple Silicon Setup Guide for the readme.

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

There is a buffer overread in the following call to msgsnd:

As per the man page, the msgsz argument (third argument) should not include the size of the mtype field, only of the data field, so currently this call will read 4 extra bytes from memory and send them to the server.

(Related to ddvk/remarkable2-framebuffer#89.)

Hi! Impressive work.

scp ./target/armv7-unknown-linux-gnueabihf/release/examples/demo remarkable:~/
demo                                                                                                                                                        100%   46MB   1.9MB/s   00:24    
ssh remarkable './demo'
./demo: /lib/libm.so.6: version `GLIBC_2.29' not found (required by ./demo)
./demo: /lib/libc.so.6: version `GLIBC_2.28' not found (required by ./demo)

Could this be the result of a misconfigured crosschain?

Note:

remarkable: ~/ ls -lh /lib/libc.* /lib/libm.*
lrwxrwxrwx    1 root     root          12 Mar 20 12:47 /lib/libc.so.6 -> libc-2.27.so
lrwxrwxrwx    1 root     root          12 Mar 20 12:47 /lib/libm.so.6 -> libm-2.27.so

I'm using the poky toolchain and xochitl v2.1.1.3

Linux remarkable 4.9.84-zero-gravitas #1 Thu Dec 5 18:14:12 UTC 2019 armv7l GNU/Linux

Because of this error:

root@localhost:~# RUST_BACKTRACE=1 ./demo
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ErrUnaligned', src/libcore/result.rs:999:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: rust_begin_unwind
             at src/libstd/panicking.rs:308
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::result::unwrap_failed
             at /rustc/cfdc84a009020c59e53e4039beae22eb59e41685/src/libcore/macros.rs:18
   9: <libremarkable::framebuffer::core::Framebuffer as libremarkable::framebuffer::FramebufferBase>::new
             at /rustc/cfdc84a009020c59e53e4039beae22eb59e41685/src/libcore/result.rs:800
             at src/framebuffer/core.rs:67
  10: libremarkable::appctx::ApplicationContext::new
             at src/appctx.rs:96
  11: demo::main
             at examples/demo.rs:673
  12: std::rt::lang_start::{{closure}}
             at /rustc/cfdc84a009020c59e53e4039beae22eb59e41685/src/libstd/rt.rs:64
  13: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  14: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:85
  15: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  16: main
  17: __libc_start_main

Hey I have been trying to build the code myself, because I am interested in playing around and maybe creating an application for the remarkable. I have installed both SDKs ("codex", "oecore"). But no matter which one i set in the cargo config the build of the examples fails with a linker error. Not really sure what to make of it. Any ideas what I am missing?

/home/judge/GitHub/remarkable/toolchains/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/7.3.0/real-ld: cannot find Scrt1.o: No such file or directory
          /home/judge/GitHub/remarkable/toolchains/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/7.3.0/real-ld: cannot find crti.o: No such file or directory
          /home/judge/GitHub/remarkable/toolchains/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/7.3.0/real-ld: cannot find crtbeginS.o: No such file or directory
          collect2: error: ld returned 1 exit status

Could you please release a new version?

I've built a minimal example, which works when I point to master, but it doesn't compile with the released v0.3.2.

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.

Somehow libremarkable's rm2fb client implementation is causing the server to stop working after executing the application once. The server no longer understands messages from either libremarkable apps OR the official rm2fb client - it is completely defunct. These log messages occur when the server becomes corrupteed:

reMarkable env[18332]: Error, unknown message type
reMarkable env[18332]: Error recv msgbuf: Invalid argument
reMarkable env[18332]: Error, unknown message type
reMarkable env[18332]: Error recv msgbuf: Invalid argument
reMarkable env[18332]: Error, unknown message type
reMarkable env[18332]: Error recv msgbuf: Invalid argument
reMarkable env[18332]: Error, unknown message type
reMarkable env[18332]: Error recv msgbuf: Invalid argument
reMarkable env[18332]: Error, unknown message type
reMarkable env[18332]: Error recv msgbuf: Invalid argument

Restarting rm2fb allows it to work again.

Forcing libremarkable to use /dev/fb0 and running it under LD_PRELOAD=/opt/rm2fb/librm2fb_client.so.1.0.1 does not exhibit the issue. The application can be run any number of times without affecting the server. The issue only occurs when libremarkable is allowed to use its built-in client.

Codex version 2.11.0.442
reMarkable 2 model RM110
rm2fb server invocation: /usr/bin/env LD_PRELOAD=/opt/rm2fb/librm2fb_server.so.1.0.1 /usr/bin/xochitl

I notice that there is a hard-coded git clone command in the Makefile, which seems a bit out of place to me.

Would it make any sense to make this a submodule instead?

That way, you could clone it automatically (and just once) with "git submodule init && git submodule update".

PS: I can make this a PR.

Originally discussed here: #62 (comment)

The basic idea is to issue calls to the /opt/lib/librm2fb_client.so.1 library directly, if it's present. This means libremarkable apps on rm2 would "just work" without needing to use the shim explicitly. (Though it would still need to be installed.)

I've been playing with the demo and I noticed that the pen latency is a bit higher than in xochitl. Any idea what the cause is or if it can be reduced?

The latest release has Git tag HEAD. This leads to a warning when using Git. Example (after a fresh checkout):

$ git status
warning: refname 'HEAD' is ambiguous.
warning: refname 'HEAD' is ambiguous.

I suggest deleting the HEAD tag and adding the 0.4.1 tag instead.

reMarkable version 2.1.1.3

remarkable: ~/ wget https://github.com/canselcik/libremarkable/releases/download/0.3.2/demo
Connecting to github.com (140.82.114.3:443)
wget: note: TLS certificate validation not implemented
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (52.217.37.68:443)
demo                 100% |********************************| 35.4M  0:00:00 ETA
remarkable: ~/ chmod +x demo
remarkable: ~/ systemctl stop xochitl
remarkable: ~/ ./demo
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Unable to open file: No such file or directory (os error 2)"', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
remarkable: ~/ export RUST_BACKTRACE=1 && ./demo
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Unable to open file: No such file or directory (os error 2)"', libcore/result.rs:945:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
			at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
			at libstd/sys_common/backtrace.rs:71
			at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
			at libstd/panicking.rs:211
3: std::panicking::default_hook
			at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
			at libstd/panicking.rs:511
5: std::panicking::continue_panic_fmt
			at libstd/panicking.rs:426
6: rust_begin_unwind
			at libstd/panicking.rs:337
7: core::panicking::panic_fmt
			at libcore/panicking.rs:92
8: core::result::unwrap_failed
			at /checkout/src/libcore/macros.rs:26
9: demo::main
			at /checkout/src/libcore/result.rs:782
			at examples/demo.rs:1033
10: std::rt::lang_start::{{closure}}
			at /checkout/src/libstd/rt.rs:74
11: std::panicking::try::do_call
			at libstd/rt.rs:59
			at libstd/panicking.rs:310
12: __rust_maybe_catch_panic
			at libpanic_unwind/lib.rs:105
13: std::panicking::try
			at libstd/panicking.rs:289
14: std::rt::lang_start_internal
			at libstd/panic.rs:392
			at libstd/rt.rs:58
15: main
16: __libc_start_main

I assume this is operator error, can you point me in the right direction?

Including Lua is wasted space when it's not used, please put it behind a Cargo feature (even if that's enabled by default). Honestly most of the crate should be behind cargo features.

Nothing gets rendered on the display if xochitl wasn't started at least once.

Steps to reproduce:

1. Deploy demo application on device
2. ssh to device
3. systemctl disable xochitl
4. reboot
5. ssh to device
6. ./demo (you won't see the demo, but it is running, e.g. touch events are logged)
7. Kill ./demo (e.g. with ctrl-c)
8. xochitl
9. Kill xochitl (e.g. with ctrl-c)
10. ./demo (now you can also see the demo)

Any help on how to get started debugging this problem would be appreciated.

I'm trying to follow the build instructions however I cannot seem to locate the official SDK. The links provided are effectively broken.

Here's the current install script link from the README. https://remarkable.engineering/oecore-x86_64-cortexa9hf-neon-toolchain-zero-gravitas-1.8-23.9.2019.sh. Click it for yourself and you should see the issue.

Did reMarkable pull a bait and switch recently, or is this a known issue by now? Are there workarounds for this?

I didn't see a software license in your repository. Would you be able to add one? The MIT license would preferable.

Thanks!

-P

Is there a 'best way' to clear the drawn elements on the screen without a full redraw?

So far, I've tried:

1. app.get_framebuffer_ref().partial_refresh(...)
2. app.draw_element(&name)
3. app.clear(false); app.draw_elements();

the only one that seems to be close to the desired effect is 3, and it causes a visual-nasty full-screen redraw. What's the recommended approach to a ... partial clear and redraw?

IMO: this should look something like:

fn on_hide(app: &mut appctx::ApplicationContext<'_>, element: UIElementHandle) {
    let region: mxcfb_rect = element.read().last_drawn_rect.unwrap();
    app.remove_element("button".to_owned());
    app.clear(&region);
}

🤔

I'm using libremarkable to port Plato reader on remarkable, i need to pass EPDC_FLAG_ENABLE_INVERSION to update flags

The following may come off as strong. I want to mention up front that I appreciate the work done on libremarkable greatly, and that this is absolutely not intended as a criticism of the project. I have merely spotted an issue which I believe would need addressing in order for the memory safety guarantees of Rust to continue to be useful to us.

In libremarkable, there is a function on the ApplicationContext called upgrade_ref. This function notes that it's probably bad practice, but asserts that its operation is safe because ApplicationContext will live forever. This is kinda valid reasoning for upgrading a reference to an immutable value that will live forever, but in the ways it's used, it's absolutely not safe. Specifically, it upgrades a &'a mut to a &'static mut, effectively annihilating any borrow checking as it asserts that the mutable borrow is valid forever, even in the face of other borrows. ApplicationContext is not an immutable value like a &'static str, it's more like a global state - and this state can currently have as many simultaneous mutable references to it as one likes. In my opinion, this is a problem.

I have attempted to resolve this by changing the signature from fn upgrade_ref(&mut self) -> &'static mut ApplicationContext<'static> to fn upgrade_ref(&mut self) -> &mut ApplicationContext<'static>, that is to say, changing it to return a reference with the elided lifetime rather than a static one. Unfortunately, while this is fine for all uses within libremarkable, uses outside of the core library, including examples, go ahead and pass mutable references to the ApplicationContext to as many threads as they please, while each of them assumes it has a unique reference. This is clearly undefined behaviour.

Now, whether this issue is of concern to library users is another question. I am not aware of any instances of memory corruption arising from the current implementation, so maybe the current implementation has less unsoundness than it seems, or maybe we're lucky. It may be that keeping the existing applications running is more important than addressing this undefined behaviour. However, there may be a way to resolve this without an architecture-breaking change: if all parts of the ApplicationContext (including Framebuffer) can be made interior mutable (e.g. atomics and mutexes rather than &mut), upgrade_ref could be largely superceded by a version that returns a shared reference, and all the methods can take it by shared reference. I have given this idea a poke, but I haven't spent much time attempting an implementation.

The other possibility I can think of is a major architecture-breaking change based on granular resource delegation. (I have been playing with this idea since 2019, but it happens to also maybe solve this issue - I only noticed the soundness issues this month. As such, the relationship to the problem is incidental.) My idea is essentially traits for receiving input events and drawing on screen regions, which are implemented by structs that hold mutable access to said screen regions. The idea would be that if you want to delegate control of, say, the top bar of the screen to a thread, then you split your canvas into two accessor structs (above region and below region) that both implement the drawing traits but have mutually exclusive safety checks in place to prevent overdraw.

This idea is actually one I've explored a little a couple of times, first in 2019 with my f-canvas-traits branch. On that branch, only pixel writing is implemented by Framebuffer, and the rest is on an extension trait. This means that one can have a wrapper struct man-in-the-middle pixel draw calls to e.g. mask the output. This allowed me to easily implement patterned drawing (pattern, masking) in the demo, for example. A more directly applicable change was tried on my (poorly named) split-out-draw-text branch, which makes FramebufferIO itself a trait. I believe the intent was to make generic framebuffer and event IO traits that would allow the implementation of PC emulation layers for dev and/or automated tests. I was blocked at the time by two major factors: I couldn't find a library for pen input, and I realised that ApplicationContext was a behemoth of state that would require significant work to convert to a clean interface. Attempts at the latter were what led me to finding this issue.

Anyway, I'd like to know what everyone thinks. Is this a non-issue? Do you think something should be done? If so, what?

tl;dr: there are some soundness issues I think it's worth being aware of and maybe fixing. There's a boring fix that might work and a pet idea of mine might also be a solution. I want to know what people think.

Hi,

Thanks for all the work you've put into this project, I am really excited to try and see what would it enable me to do!

Sadly I have not got far. I have encountered bunch of problems installing toolchain from
https://remarkable.engineering/deploy/sdk/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-neon-toolchain-2.1.3.sh

BTW https://remarkable.engineering/ seems to link to this one instead https://remarkable.engineering/oecore-x86_64-cortexa9hf-neon-toolchain-zero-gravitas-1.8-23.9.2019.sh (should I be using one above or things have changed in the meantime ?)

With the poky-glibc-* toolchain on macOS 10.15.5 I've run with following problems:

1. readlink -m causes illegal option -- m error.
   • I did worked around it via installing brew install coreutils and creating symlinking greadlink to readlink in my PATH.
2. Once I got passed issue above I've started having tar: Option --checkpoint=.2500 is not supported
   • Was able to workaround it via brew install gnu-tar and symlinking gtar to tar in my PATH.
   • However my PATH was not taken into account by toolchain script, but setting ENVCLEANED=0 solved that.
3. Now I'm stuck on find: -printf: unknown primary or operator.

Current output I get is following:

ENVCLEANED=0 ~/Downloads/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-neon-toolchain-2.1.3.sh -D
Poky (Yocto Project Reference Distro) SDK installer version 2.1.3
=================================================================
+ '[' '' = 1 ']'
+ '[' '' = '' ']'
+ '[' '' = Y ']'
+ read -p 'Enter target directory for SDK (default: /opt/poky/2.1.3): ' target_sdk_dir
Enter target directory for SDK (default: /opt/poky/2.1.3):
+ '[' '' = '' ']'
+ target_sdk_dir=/opt/poky/2.1.3
++ echo /opt/poky/2.1.3
++ sed 's/ /\\ /g'
+ eval target_sdk_dir=/opt/poky/2.1.3
++ target_sdk_dir=/opt/poky/2.1.3
+ '[' -d /opt/poky/2.1.3 ']'
++ cd /opt/poky/2.1.3
++ pwd
+ target_sdk_dir=/opt/poky/2.1.3
+ '[' 15 -gt 2048 ']'
+ '[' '' = 1 ']'
++ echo /opt/poky/2.1.3
++ grep ' '
+ '[' -n '' ']'
+ '[' -e /opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi ']'
+ echo 'The directory "/opt/poky/2.1.3" already contains a SDK for this architecture.'
The directory "/opt/poky/2.1.3" already contains a SDK for this architecture.
+ printf 'If you continue, existing files will be overwritten! Proceed[y/N]? '
If you continue, existing files will be overwritten! Proceed[y/N]? + default_answer=n
+ '[' '' = '' ']'
+ read answer
y
+ '[' y = '' ']'
+ '[' y '!=' Y -a y '!=' y ']'
+ mkdir -p /opt/poky/2.1.3
+ '[' '!' -x /opt/poky/2.1.3 -o '!' -w /opt/poky/2.1.3 -o '!' -r /opt/poky/2.1.3 ']'
+ '[' '' = 1 ']'
++ which sudo
+ SUDO_EXEC=/usr/bin/sudo
+ '[' -z /usr/bin/sudo ']'
+ /usr/bin/sudo pwd
Password:
Sorry, try again.
Password:
+ '[' 0 -ne 0 ']'
+ /usr/bin/sudo mkdir -p /opt/poky/2.1.3
++ grep -na -m1 '^MARKER:$' /Users/gozala/Downloads/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-neon-toolchain-2.1.3.sh
++ cut -d: -f1
+ payload_offset=289
+ printf 'Extracting SDK...'
Extracting SDK...+ tail -n +289 /Users/gozala/Downloads/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-neon-toolchain-2.1.3.sh
+ /usr/bin/sudo tar xJ -C /opt/poky/2.1.3 --checkpoint=.2500
...................................................................................+ echo done
done
+ printf 'Setting it up...'
Setting it up...+ real_env_setup_script=
++ ls /opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
+ for env_setup_script in '`ls $target_sdk_dir/environment-setup-*`'
+ grep -q OECORE_NATIVE_SYSROOT= /opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
+ real_env_setup_script=/opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
+ /usr/bin/sudo sed -e s:/opt/poky/2.1.3:/opt/poky/2.1.3:g -i /opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
sed: -i may not be used with stdin
+ '[' -n /opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi ']'
+ env_setup_script=/opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
++ /usr/bin/sudo cat /opt/poky/2.1.3/environment-setup-cortexa9hf-neon-poky-linux-gnueabi
++ grep OECORE_NATIVE_SYSROOT=
++ cut -d= -f2
++ tr -d '"'
+ native_sysroot=/opt/poky/2.1.3/sysroots/x86_64-pokysdk-linux
++ /usr/bin/sudo find /opt/poky/2.1.3/sysroots/x86_64-pokysdk-linux/lib -name 'ld-linux*'
+ dl_path=/opt/poky/2.1.3/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2
+ '[' /opt/poky/2.1.3/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 = '' ']'
++ /usr/bin/sudo find /opt/poky/2.1.3/sysroots/x86_64-pokysdk-linux -type f '(' -perm -0100 -o -perm -0010 -o -perm -0001 ')' -printf ''\''%h/%f'\'' '
find: -printf: unknown primary or operator
+ executable_files=
++ mktemp -d
+ tdir=/var/folders/z9/g6tzrv1n2sd0h_8snr784py80000gn/T/tmp.rcORvlA7
+ '[' x/var/folders/z9/g6tzrv1n2sd0h_8snr784py80000gn/T/tmp.rcORvlA7 = x ']'
+ cat
+ /usr/bin/sudo mv /var/folders/z9/g6tzrv1n2sd0h_8snr784py80000gn/T/tmp.rcORvlA7/relocate_sdk.sh /opt/poky/2.1.3/relocate_sdk.sh
+ /usr/bin/sudo chmod 755 /opt/poky/2.1.3/relocate_sdk.sh
+ rm -rf /var/folders/z9/g6tzrv1n2sd0h_8snr784py80000gn/T/tmp.rcORvlA7
+ '[' 1 = 1 ']'
+ /usr/bin/sudo /opt/poky/2.1.3/relocate_sdk.sh
+ '[' 255 -ne 0 ']'
+ echo 'SDK could not be set up. Relocate script failed. Abort!'
SDK could not be set up. Relocate script failed. Abort!
+ exit 1

All this issues got me wondering if I'm installing a right toolchain for mac. Searching lead me to arm-linux-gnueabihf-binutils but that doesn't seem to include arm-linux-gnueabihf-gcc so it did not do it either.

Any help would be greatly appreciated.

Hello,
The draw_text function currently use this formula to modify the color :
let mult = (1.0 - v).min(1.0); color::RGB((c1 * mult) as u8, (c2 * mult) as u8, (c3 * mult) as u8)

But when using it, it modify only the background of the glyph (which stay in black) :

Since it is more interesting to modify the color of the glyph itself, maybe this formula could be better (that's what I'm using) :
color::RGB((255.0+(c1-255.0)*v ) as u8, (255.0+(c2-255.0)*v ) as u8, (255.0+(c3-255.0)*v ) as u8)
If we want it to work we also have to modify this (not useful anymore to do '255 - components[_]' I guess):

        let c1 = f32::from(components[0]);
        let c2 = f32::from(components[1]);
        let c3 = f32::from(components[2]);

Then it is really the font that is changing color :

What do you think?

I know I'm a little late, but the 0.4.2 release introduced a breaking change. 3aeaa21 renamed Framebuffer::new() to Framebuffer::from_path(), which is a breaks things if you use Framebuffer directly (which I do).

I don't think any action is needed, I just want to bring it in hope there won't be such changes in the future. Or perhaps I even use the API wrong and shouldn't actually use Framebuffer::new().

Are you aware of any applications that people have developed using this library? Development of note taking apps seems nonexistent, surprisingly.

I'm doing some networking (with tonic) and I'm ending up with a tokio runtime and async fns.

I see ApplicationContext::new expects non-async function pointers and uses std::sync::mpsc{Sender,Receiver}.

Connecting my networking stuff and appctx callbacks is a bit awkward: it involves a mutex and some thought to give to the Receiver (which does not implement Send).

Are there any plans to move to using async functions in ApplicationContext?

tokio has Send MPSC channels.
Communication could be thread-safe I guess?

I'm more concerned over the inconvenience that using async with libreMarkable is right now.

Do you know if there is a way to turn off the screen?

for example, kobo readers turn it off by writing into file:

echo 1 > /sys/power/state-extended

In 1.8 the battery location has changed to /sys/class/power_supply/bq27441-0

Hello, and thank you for starting this wonderful project.

I'm trying to compile the examples so that I can run the live demo as I want to view the remarkable screen on my computer screen.

I used this comment to install the dependencies #5 (comment). There were no errors and I could follow all steps.

However, when I run the last step I get the following error:

$ make
cargo build --release --target=armv7-unknown-linux-gnueabihf
    Finished release [optimized + debuginfo] target(s) in 0.10s
cargo build --examples --release --target=armv7-unknown-linux-gnueabihf
   Compiling libremarkable v0.3.2 (/home/viktsend/Programs/libremarkable)
warning: use of deprecated item 'std::sync::ONCE_INIT': the `new` function is now preferred
   --> examples/spy.rs:106:1
    |
106 | / hook! {
107 | |   unsafe fn ioctl(fd: c_int, request: NativeWidthType, p1: intptr_t, p2: intptr_t, p3: intptr_t, p4: intptr_t) -> c_int => ioctl_hook {
108 | |     if request == FBIOPUT_VSCREENINFO {
109 | |         let info = p1 as *mut VarScreeninfo;
...   |
142 | |   }
143 | | }
    | |_^
    |
    = note: `#[warn(deprecated)]` on by default
    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

warning: use of deprecated item 'std::sync::ONCE_INIT': the `new` function is now preferred
   --> examples/spy.rs:106:1
    |
106 | / hook! {
107 | |   unsafe fn ioctl(fd: c_int, request: NativeWidthType, p1: intptr_t, p2: intptr_t, p3: intptr_t, p4: intptr_t) -> c_int => ioctl_hook {
108 | |     if request == FBIOPUT_VSCREENINFO {
109 | |         let info = p1 as *mut VarScreeninfo;
...   |
142 | |   }
143 | | }
    | |_^
    |
    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: lto can only be run for executables, cdylibs and static library outputs

error: aborting due to previous error; 2 warnings emitted

error: could not compile `libremarkable`.

To learn more, run the command again with --verbose.
make: *** [Makefile:7: examples] Error 101

17:18 viktsend@stealth
~/Programs/libremarkable
$ 

I'm running Ubuntu 19.10. Any help will be much appreciated.

Best
V

Hey guys,
I think i just got unlucky and pulled this at the wrong hour, but it looks like something is funny with the 0.5.0 release.
Crates.io was published 9 days ago, but the Cargo.toml only got bumped to 0.5.0 today, and deps of crate are older than deps in the commit containing 0.5.0 version bump.

Hello!
I'm using your library in my port of Plato ebook reader.

https://github.com/darvin/plato

(thats the usage)
https://github.com/darvin/plato/blob/master/src/framebuffer/remarkable.rs

I see those artifacts:

clearly, i misusing it somehow, got any tips?

Thank you for hard work making this library!

Hey, really like you work 👍
Would be great, if you add the remarkable-tablet label/tag to this repo so others can find you great work better.

See https://github.com/topics/remarkable-tablet

A configuration file for Make would be a nice thing to have. I thought I would run it by you before making a PR.

For me, this would be necessary because my cross-compiler toolchains are in weird, non-standard locations.

The classic example of this is with dwm. I would probably implement something similar to my own projects Soundpipe and Sporth.

What do you think?

Hi, this library looks awsome! My remarkable 2 is comming this October and I can't wait writing code for it (hope all the apis are the same so this lib will still work)

As far as I'm aware of, all the apps written for remarkable requires killing xochitl then restarting it when the app exits, which is slow.

I'm thinking about can we send SIGSTOP to pause xochitl instead of killing it, and send SIGCONT to it when the app exits.

Since xochitl is paused so the last frame is still on the screen, we can even create overlay on top of the original xochitl ui. (That will be super cool!)

I can't test these thoughts since I don't have the device yet, I'm wondering can someone test this approach and see how it turns out?

Cannot compile using nightly compiler.

error[E0502]: cannot borrow `*app` as mutable because it is also borrowed as immutable
   --> examples/demo.rs:437:63
    |
434 |                     match app
    |                           --- immutable borrow occurs here
...
437 |                         Some((region, _)) => (region.handler)(app, region.element.clone()),
    |                                                               ^^^  -------------- immutable borrow later used here
    |                                                               |
    |                                                               mutable borrow occurs here

error: aborting due to previous error

Please, specify exact version of nightly compiler, which is testes with libremarkable.

From a cursory glance, it seems like libremarkable does not support the Remarkable 2 yet, is that correct?

It looks like https://github.com/canselcik/libremarkable/blob/master/src/framebuffer/mxcfb.rs uses the mxcfb Framebuffer driver from the SDK for Remarkable 1, while Remarkable 2 uses a different driver koreader/koreader#6792

Would pay an hourly fee for someone to screen share me through getting a "hello world" up under os x. I'm a competent programmer, but don't know docker or the rust/qt toolchains so a bit stuck :/

I've got this error message for evdev, when I was running make TARGET=armv7-unknown-linux-gnueabihf deploy-x-demo:

error[E0308]: mismatched types
   --> /cargo/registry/src/github.com-1ecc6299db9ec823/evdev-0.11.7/src/lib.rs:390:29
    |
390 |     let dur = Duration::new(tv.tv_sec.unsigned_abs(), tv.tv_usec as u32 * 1000);
    |               ------------- ^^^^^^^^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`
    |               |
    |               arguments to this function are incorrect
    |
note: associated function defined here
   --> /rust/lib/rustlib/src/rust/library/core/src/time.rs:185:18
    |
185 |     pub const fn new(secs: u64, nanos: u32) -> Duration {
    |                  ^^^
help: you can convert a `u32` to a `u64`
    |
390 |     let dur = Duration::new(tv.tv_sec.unsigned_abs().into(), tv.tv_usec as u32 * 1000);
    |                                                     +++++++

For more information about this error, try `rustc --explain E0308`.
error: could not compile `evdev` due to previous error

I tried to use the link in the readme to obtain the toolchain from remarkable, but the link just redirects to the front page. Is there a new URL to get this?

I'd like to wrap this library for Racket.

Is there any interest in adding C bindings to libremarkable?

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 !

I was following the instructions to build with musl.

However, there seems to be a compile error. Building on MacOS.

Compiling evdev v0.10.2
convert_ioctl_res!(::nix::libc::ioctl(fd, ior!(b'E', 0x20 + ev, len) as ::libc::c_ulong, buf))
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `i32`, found `u32`

I'm new to the lang, but it seems the error might be due to this issue: emberian/evdev#22

Looks like the newest version hasn't been published with the fix

When you remove a named element from the ApplicationContext it stops drawing the element, but if you had an onclick registered, there is still an active region where the element used to be displayed.

I was able to get the Demo running on my Remarkable, however, it crashes as soon as I use the eraser.

Looks like there's some unhandled input.

2021-03-19T17:26:14Z INFO  demo] Init complete. Beginning event dispatch...
[2021-03-19T17:26:14Z INFO  libremarkable::input::ev] Init complete for "/dev/input/event1"
[2021-03-19T17:26:14Z INFO  libremarkable::input::ev] Init complete for "/dev/input/event2"
[2021-03-19T17:26:14Z INFO  libremarkable::input::ev] Init complete for "/dev/input/event0"
[2021-03-19T17:26:14Z DEBUG libremarkable::input::scan] Closed initially opened evdev fds (if not used by now).
thread 'main' panicked at 'internal error: entered unreachable code', examples/demo.rs:497:22
stack backtrace:
   0: rust_begin_unwind
             at /rustc/1705a7d64b833d1c4b69958b0627bd054e6d764b/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/1705a7d64b833d1c4b69958b0627bd054e6d764b/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/1705a7d64b833d1c4b69958b0627bd054e6d764b/library/core/src/panicking.rs:50:5
   3: demo::on_wacom_input
             at /home/builder/libremarkable/examples/demo.rs:497:22
   4: libremarkable::appctx::ApplicationContext::dispatch_events
             at /home/builder/libremarkable/src/appctx.rs:524:25
   5: demo::main
             at /home/builder/libremarkable/examples/demo.rs:1176:5
   6: core::ops::function::FnOnce::call_once
             at /rustc/1705a7d64b833d1c4b69958b0627bd054e6d764b/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.