Conversation
|
@wonderbeel Since you've already worked with the emulation, I would appreciate it if you could take a look at the research I've done and the changes that I'm proposing. Also, @simmsb, what are your thoughts on adding this manual/changes to include emulation guides/mechanisms directly to the inkview-rs SDK? |
|
This is very cool, but I don't see myself using this. There's a lot of extremely fragile code in this PR that I do not wish to maintain. I would prefer if this was a project hosted in a different repo. If there are any changes to this repo required to support an emulator located in another repo, then those are okay to PR. |
|
I agree with @simmsb this is extremely useful in my experience but also kind of brittle, it is better to just solve it in the application itself and/or use a qemu emulator. If it can be useful to you @ihrfv you can find my approach to driving the SDK/qemu emulators here https://codeberg.org/wonderbeel/pb-suwayomi an LLM can drive this with ease (and combined with logs you can debug stuff quite well). |
|
@simmsb @wonderbeel I appreciate your thoughts, and I do agree that the whole emulator setup is not super stable or refined, so having a dedicated repo makes sense to reduce the number of strings this repo has. I will prepare the updated version of this pr, as it still fixes the examples when it comes to scaling. Meanwhile, @simmsb pr #24 seems to be ready to be merged. Since I depend on it, could you please take a look at it? |
Extracted from inkview-rs, where the maintainer declined to carry it (simmsb/inkview-rs#25): "I would prefer if this was a project hosted in a different repo." The SDK ships a host x86_64 libinkview.so beside the ARM one, and inkview dlopens its library by name, so a x86_64-unknown-linux-gnu build against that copy runs the real app in an X11 window. Changes from the in-tree version it came from: - a project-agnostic `inkview-emu` CLI replaces the just recipes, which were bound to inkview-rs' own target/ layout - assets cache in ~/.cache/inkview-emu, shared across projects, instead of living inside the repo - SDK 6.10 support: it also ships a host libinkview, contrary to what the original claimed. It is a bookworm-era build needing GLIBC_2.34, so it gets its own container and its builds target glibc 2.36 rather than stretch's 2.24 The pbemu guide moves along too, with the operational notes pb-suwayomi documented and a lead on dropping one of the six macOS patches. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ihrfv
changed the title
|
@simmsb I've reworked this PR (with a force push) to make some fixes to the inkview and inkview-slint-demo + added a reference to the emulator that I've extracted in a separate repo. |
Once the panel is active, GetCanvas() hands back a canvas whose origin is PanelHeightFBOffset() rows into the framebuffer (75 rows at 828x1200), while still reporting the full screen height. Everything an app drew landed that far down and the last rows wrapped around to the top. Only apps that fall back to GetCanvas() are affected — the emulator, where GetTaskFramebuffer() is always NULL — and only once the panel has been set up, so drawing from the Init handler looked correct while drawing later from a worker thread (as inkview-slint apps do) did not. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
set_size resolves its argument against the window's current scale factor, so passing a logical size before announcing the scale made slint record that logical size as the physical one — a 828x1200 screen came out as a 331x480 window. Announce the scale first and pass physical pixels, which needs no conversion at all. Rendering is unchanged; it is what Window::size() reports that was wrong. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The SDK's host build of libinkview lets an app run on a desktop, which is not obvious from anything in this repo. Links the external tool that packages it, without taking on the tooling itself. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@simmsb I've rebased the branch and updated the description of the PR to clearly highlight what it is solving. TL;DR: There are 2 minor bugs related to scaling that this PR is fixing, as well as a small addition to the documentation to point to the emulator I've prepared in a separate repo. Sorry for the messy force-pushed history; if you want me to prepare a clean PR, I can do it with no problems. Also, if you find linking to the documentation of the emulator unnecessary, just let me know, and I will drop the commit with it. |
3 participants
While working on inkview-rs-emu, the 2 bugs were detected in this (inkview-rs) repo that are related to scaling and resizing.
This PR provides the two fixes:
inkview-slintannounced the window size before the scale factor.Window::size()then reported331x480 for an 828x1200 screen, because the size was interpreted against a stale scale factor.
Rendering was already correct, so this only bites code that reads the window size — layout
decisions, hit-testing, anything sizing itself from
Window::size(). Swapping the order fixes it.This one is not emulator-specific at all.
Screen::newleft the panel up when falling back toGetCanvas(). Once the panel is active, theglobal canvas starts
PanelHeightFBOffset()rows into the framebuffer while still reporting the fullheight, so everything drawn lands that far down (75px at 828x1200) and the last rows wrap to the top.
SetPanelType(PANEL_DISABLED)on that path fixes it. It only shows up when drawing happens afterthe
Inithandler — i.e. from the worker threadinkview-slintapps use — which is why it wentunnoticed.
Also adds a short README section pointing at the external emulator project, so the capability is
discoverable from here. Happy to drop that if you would rather the README stayed as it is.
🤖 Generated with Claude Code