Repository navigation
Fall back to GetCanvas() when the task framebuffer is unavailable - #24
Merged
Merged
Conversation
GetCurrentTask()/GetTaskFramebuffer() are only wired up on-device. In the desktop SDK emulator GetCurrentTask() returns -1 and the task framebuffer is null, so Screen::new() panics before anything is drawn. Fall back to the global canvas (GetCanvas) -- the same icanvas_s, populated in both environments. GetTaskFramebufferInfo is likewise task-only, so skip it on the emulator instead of unwrapping a null pointer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
@wonderbeel, hey, I was wondering how you did the SDK emulator? |
Contributor
Author
|
@ihrfv I used the one included in the SDK (you can find the last one here https://github.com/Sean-on-Git/PocketBook-SDK I found it on mobile read), I am on vacation right now so I don't have the full script at hand but it isn't too difficult to start it in a Debian host. There is also this full emulator https://codeberg.org/datyoma/pbemu that I found on mobileread that completely emulates a device (it loads a firmware and spin it up with qemu and podman) and here the the framebuffer issue didn't happen, I guess that it was indeed a quirk of the SDK emulator (it doesn't emulate the full device so probably there is some discrepancy under the hood and with stricter checks you find it while it slips undetected in inkview itself). |
simmsb
approved these changes
Jun 24, 2026
simmsb
left a comment
simmsb
left a comment
Owner
There was a problem hiding this comment.
Heya, thanks for adding this :)
I can't really remember why I have it fetch the framebuffer by using GetTaskFrameBuffer as opposed to just GetCanvas, if I find time I'll try having the library always use GetCanvas.
For a small change like this that is easily testable I don't have a problem with it being LLM generated.
Contributor
Author
|
Applied the comment, thank you for double checking :). |
ihrfv
added a commit
to ihrfv/inkview-rs
that referenced
this pull request
Jul 21, 2026
Two emulators now live side by side and they answer different questions, so picking between them should not require reading both READMEs. The SDK emulator is the default: seconds to build, one command, in-repo, and the only one wired into CI. pbemu is the escalation, because the SDK emulator has one systematic blind spot -- it does not run the binary you ship. PR simmsb#24 is the evidence that this matters rather than being theoretical: the host library hands back a NULL task framebuffer where the device does not. Also records what neither of them can tell you. Both fake the framebuffer, so e-ink refresh behaviour -- ghosting, partial-update artefacts, refresh timing -- remains device-only, and anything depending on the choice between full_update, partial_update and dynamic_update still has to be checked on hardware. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ihrfv
added a commit
to ihrfv/inkview-rs-templates
that referenced
this pull request
Jul 22, 2026
Generated projects can now run on the developer's machine instead of the device.
The PocketBook SDK ships a host x86_64 build of libinkview.so, and since inkview
resolves its library by name at runtime, a build for x86_64-unknown-linux-gnu
against that copy runs the real app in an X11 window.
just fetch-emu-assets # one-time, 0.6-1.3 GB download
just emu-image # one-time, builds the container
just pb_emu_resmode=3 build-run-emu # a window
just build-screenshot-emu # headless -> target/emu/screenshot.png
The tooling itself is not vendored here. It lives in
https://github.com/ihrfv/inkview-rs-emu, installed once per machine, so it can
be fixed or extended without regenerating every project that uses it. The
generated justfile passes the pb_emu_* variables through as PB_EMU_* and shells
out; a _require-emu guard fails with install instructions rather than "command
not found" partway through a docker run. Assets cache in ~/.cache/inkview-emu,
shared across projects, so the SDK download happens once per machine.
CI gains its first run-time assertion from this: each of the three framework
variants is generated, cross-compiled, and rendered under the emulator, failing
on a panic in the log or a frame smaller than the emulated panel. It clones
inkview-rs-emu at a pinned ref onto $GITHUB_PATH.
Inside the {% raw %} block the package name must be {{ binary }}, not
{{ crate_name }} -- cargo-generate does not substitute inside raw, so the latter
reaches just as an undefined variable and fails at parse time.
One temporary piece: template/Cargo.toml carries a [patch.crates-io] pointing
inkview at a fork branch. Published 0.3.0 both panics under the emulator
(GetTaskFramebuffer returns NULL there; simmsb/inkview-rs#24 adds the fallback)
and renders shifted by the panel's framebuffer offset. Remove the patch once a
fixed inkview reaches crates.io.
Verified end to end: all three framework variants generate, their justfiles
parse, and a generated project builds and renders a 1072x1448 frame through the
delegated recipes alone.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Was playing with your bindings yesterday night and noticed that my hello world app was working fine on my physical devices but panicking on the SDK emulator. Pocked at it with help from claude and found that on the emulator the framebuffer task is always null and that it is causing the panic. Let me know if the patch is fine (rust novice, I am starting to use it now to play on my pocketbook) or if you would prefer a different approach to make the emulator work