FBInk: A small tool/library to print crap on your screen!

[bitfreak]

I can't get daemon mode to work properly, what am I doing wrong?
It should loop back to 1 with line 26, but it does not.

# fbink -y6 -d25
# for i in $(seq 1 1 30);do echo $i;done > /tmp/fbink-fifo

[NiLuJe]

Ooh, that's interesting .

The fifo is purged via a dumb read in a poll loop. It turns out that, in this case, by the time we get to the read, everything has already been written, and so read will read the whole string of data (e.g., `1\n2\n3\n...`), and that gets fed to fbink in a *single* print call.

That allows it to blow past the line limit, since that only applies to *consecutive* print calls.

I'm... sort of torn on whether I really want to do something about it.

I kind of *like* the fact that you can pass LFs to blow past the limit, but it does create a bit of an inconsistency, depending on the timing...

EDIT: This means that doing something like `for i in $(seq 1 1 30);do echo $i >| /tmp/fbink-fifo && usleep 500;done` instead *will* behave as expected .

[NiLuJe]

That, and I can't really use getline, as passing data without a trailing LF is a perfectly valid and expected use-case; and I don't really want to replicate the manual LF parsing that's already done inside fbink_print (I'm also mildly concerned about UTF-8 shenanigans, but apparently a blind search for a 0x0A byte *should* be safe...).

[NiLuJe]

Ohkay, tried something in https://github.com/NiLuJe/FBInk/comm...3887b249e83350

It has a few downsides as it murders any and all existing LF handling inside fbink_print, but, then again, that was already potentially quirky for that use-case anyway...

[NiLuJe]

Oh, and also relaxed the strtoul check we discussed earlier (in daemon mode, at least), so it no longer balks on trailing "garbage" .

[gonzule]

Hi, are there any plans to support SVG "images" in the future? I'm trying to get one to display ATM without having to convert it to PNG first.

[NiLuJe]

Not until someone comes up with a sane standalone SVG parser/rasterizer library without a dependency chain a mile long (looking at you, librsvg ;p).

(nanosvg & lunasvg are the top contenders right now, but they both have limitations. In the meantime, I'm vaguely hoping blend2d will ultimately support SVG once it's done cooking. IIRC, I was tracking something else on that subject but I can't recall what right now ;D).

[geek1011]

Originally Posted by NiLuJe

Not until someone comes up with a sane standalone SVG parser/rasterizer library without a dependency chain a mile long (looking at you, librsvg ;p).

(nanosvg & lunasvg are the top contenders right now, but they both have limitations. In the meantime, I'm vaguely hoping blend2d will ultimately support SVG once it's done cooking. IIRC, I was tracking something else on that subject but I can't recall what right now ;D).

Would rust do? https://github.com/RazrFalcon/resvg

[NiLuJe]

Rust allows one to sort of shove the mile-long dependency list under the carpet, but, yeah, that's the one I was forgetting, I think (I definitely remember looking at it, at least) .

[bitfreak]

Originally Posted by NiLuJe

That, and I can't really use getline, as passing data without a trailing LF is a perfectly valid and expected use-case; and I don't really want to replicate the manual LF parsing that's already done inside fbink_print (I'm also mildly concerned about UTF-8 shenanigans, but apparently a blind search for a 0x0A byte *should* be safe...).

Originally Posted by NiLuJe

Ohkay, tried something in https://github.com/NiLuJe/FBInk/comm...3887b249e83350

It has a few downsides as it murders any and all existing LF handling inside fbink_print, but, then again, that was already potentially quirky for that use-case anyway...

Originally Posted by NiLuJe

Oh, and also relaxed the strtoul check we discussed earlier (in daemon mode, at least), so it no longer balks on trailing "garbage" .

I hope I have some time this weekend to start testing some stuff \o/

[gonzule]

Quick question i'm struggling to solve. I'm trying to run fbink to display an image, for a weather dashboard. I can get it to work using "fbink -c -f -i weather-image.png -g w=-1,h=-1 " and it displays beautifully!

My issue is that after a few seconds, on the top left corner of the screen,the image disappears and it shows me the system clock. I assume that the reader is refreshing that part of the screen to show me the current time, but not sure of there is any way to stop the clock from refreshing, or to make fbink stay "always on top". I'm running the fbink command while i'm on the main home screen of my kobo reader (Old Kobo Aura)

[bitfreak]

Originally Posted by NiLuJe

Oh, and also relaxed the strtoul check we discussed earlier (in daemon mode, at least), so it no longer balks on trailing "garbage" .

Finally did some compiling and testing and it works great, however is there an easy way to reset it?
eg: clear screen and position to top left ? Now it just continues where it stopped previously.

Thanks

[gonzule]

Originally Posted by NiLuJe

Rust allows one to sort of shove the mile-long dependency list under the carpet, but, yeah, that's the one I was forgetting, I think (I definitely remember looking at it, at least) .

Hey! Was asking for support on displaying SVGs on another thread, and sublipri provided me with a useful binary that works pretty well, in case you want to give it a look.

https://www.mobileread.com/forums/sh...57&postcount=8

[sublipri]

Huge thanks for all your work on this NiLuJe! I've done some work on a Rust wrapper that's still quite incomplete but might be useful for some people. It adapts your script for dumping the private framebuffer on Sunxi so that it can be used like a regular fbink_dump. I've used it for a new accessibility feature in my remote control that lets you control a cursor on the Kobo's screen. There's a quick demo video of it in action on my Sage here.

I also just added updated code for the SVG utility mentioned above to the repo as an example.

[NiLuJe]

@sublipri: Cool . (We talked briefly on Discord a while ago, did we?)

A few random comments after (very) quickly skimming the input stuff in the remote:

* I implemented fbink_input_scan a few weeks ago, that should help with input device discovery .

* About that comment, does it behave in ftrace itself?

And if it doesn't, can you post the full results from a devcap test? (`make devcap` in FBInk, everything to run will end up in the generated tarball).

Also, *how* was the device forced into landscape?