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

[frostschutz]

I'm trying to use the --refresh option, any way to do a full screen refresh by default (after restoring a previously saved framebuffer state)?

For some reason I end up getting a Segmentation fault on my H2O.

# fbink --refresh top=0,left=0,width=1080,height=1429
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Variable fb info: 1080x1440, 32bpp @ rotation: 1 (Clockwise, 90°)
[FBInk] Enabled Kobo viewport insanity (1080x1440 -> 1080x1429), top-left corner is @ (0, 11)
[FBInk] Fontsize set to 24x24 (IBM base glyph size: 8x8)
[FBInk] Line length: 45 cols, Page size: 59 rows
[FBInk] Horizontal fit is perfect!
[FBInk] Vertical fit isn't perfect, shitfting rows by 7 pixels to the bottom
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6684672 bytes & line length: 4352 bytes
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Refreshing the screen from top=0, left=0 for width=1080, height=1429 with waveform mode (null)
Segmentation fault

Wonderful tool by the way, thanks so much for providing it.

[NiLuJe]

At a quick glance, I appear to have completely bungled the input validation of the refresh flag .

You're missing the wfm suboption, which currently should have caused fbink to abort with a relevant warning, but that check is busted, and the final sanity check has its logic inverted, so, double fail on my part here ;p.

TL;DR: Try with wfm=auto, and I'll fix that check when I get back to my computer .

[NiLuJe]

There, master should no longer segfault when the wfm suboption is missing, providing a slightly more useful error message in the process .

(Also, verbose logging when the option passed doesn't get recognized and falls back to AUTO).

Thanks!

EDIT: Random comment about your test command: if you want to mimic nickel, you want top=11,left=0,width=1080,height=1429, if not, top=0,left=0,width=1080,height=1440 (otherwise you'd be skipping the visible bottom 11 pixels) .

(The options are passed as-is to the ioctl, so the purported viewport trickery isn't actually done for a "manual" refresh call ).

EDIT²: For anyone else reading this, that's a quirk specific to the H2O .

[frostschutz]

I keep clicking that [karma] button but the forum software won't let me.

Thanks!

[NiLuJe]

PSA: I'm expecting mild annoyances related to Mobius and/or rotation on the Forma, which *hopefully* won't affect KFMon too badly, but, still, I'd let things sit for a few days if you're not confident in your Kobo-fu .

I do have a few ideas of what might go wrong and how, and what I can do about it, but I kind of have to see how exactly stuff breaks (if it does) first .

FWIW, I do intend to get a Forma, so I'll eventually suffer those very same issues myself, but a student's income (or lack thereof ;p) being what it is, this'll probably have to wait for the winter break .

[NiLuJe]

Ideally, I'd only need a kind soul with a Forma (and shell access) to run a test command (say, fbink -mv "Hi") in all four orientations, and post the full output each time .

(While mentioning where on the screen the message appeared, which, for the record, should be the middle of the top row).

The cherry on top would be doing the input test from this thread, too .

[frostschutz]

Originally Posted by NiLuJe

In the same vein, this one finally honors the crazy viewport on the H2O, with its 11 top pixels hidden behind the bezel.

This seems to work well most of the time, however when switching to USB connection mode, fbink suddenly starts showing things without applying the offset anymore. Until you disconnect from PC then it is back to normal. So I see things (like the miniclock from the other thread) shifting up by 11px while connected to USB.

[NiLuJe]

@frostschutz: Ah, right, the device identification currently relies on Nickel's version tag file (/mnt/onboard/.kobo/version), which is obviously unavailable if onboard is not mounted.

I'd really like to avoid having to do the hwconfig dance myself, because getting the PCB IDs right is going to be extremely unfun...

[frostschutz]

Originally Posted by NiLuJe

@frostschutz: Ah, right, the device identification currently relies on Nickel's version tag file (/mnt/onboard/.kobo/version), which is obviously unavailable if onboard is not mounted.

Sounds familiar, I have this problem in some mods. There's a tmpfs /tmp you can use to store stuff (until next reboot), so if H2O was detected once, you could create a marker in /tmp that fbink will re-use in subsequent. That way the onboard has to be mounted only first time fbink is called (and other case can't be helped then, can't have everything *shrugs*)

another thing I do is steal nickel's own environment /proc/$(pidof nickel)/environ and sometimes you're forced to do that (some versions of pickel segfault without those env vars set)

while on topic of subsequent calls, it would be cool if fbink could remember the last line it printed and print the next line on the next call. well, I was wondering how to keep track of this myself, so I don't just overwrite the previous message on every call. so maybe there's already another way

sometimes its intentional to overwrite text (like updating the clock every minute) sometimes you just want to print more stuff like a text terminal of sorts

[NiLuJe]

@frostschutz:

Turns out doing it with NTX's HWConfig thingy is less gnarly than I thought (plus, @pazos did most of the heavy lifting for the Cervantes port anyway ), so that's coming along nicely (as a fallback, because the distinction between some specific devices is harder to make... and of course, among those is one that's already crappy to handle right between the two versions, namely, the H2O² -_-").


As for your line issue, yep, you have a couple of choices: the -L flag usurps the process exit code to set it to the number of lines printed, while the -l flag does the same the old-fashioned way, by outputting it to stdout (which means it enforces the extra-silent mode of operation).
Yes, I had weird constraints on Kindle where non-zero return codes where a big no-no, hence the crappy workaround .

EDIT: See this for one example of how I'm using that in shell.

It's of course much easier in C, because fbink_print just returns that number, plain and simple, you just have to check for errors, which are always negative .

[NiLuJe]

@frostschutz:

Okay, this one should ID everything properly, even with onboard unmounted .

[NiLuJe]

Released v1.8.0!

A fairly juicy release, since it introduces OpenType/TrueType rendering, thanks to @sherman's work!

It also properly detects the new Forma .
And as mentioned earlier, it now properly detects Kobo devices even when onboard is unavailable.

It also makes an attempt at handling the native boot rotation properly... This is a bit tricky, and means I *may* have broken 16bpp rotation handling on a few devices (mainly, the H2O²r1, possibly r2 too).
If you're still running an old FW that runs in a 16bpp modeset, and stuff is badly rotated after this update, give me a shout .

[frostschutz]

Thanks for the update. Testing the TrueTypes as soon as I can

[sherman]

Hi

Just a couple of notes for those using the new OpenType/TrueType functionality, as there are some differences compared to the traditional FBInk printing methods.

Unicode linebreaking is used for wrapping lines. This means, that when printing OT/TT, the line will try to avoid breaking mid-word.

OT support uses margins, instead of cells, for positioning. That means you can set a printable area with top, bottom, left and right margins. The margins are specified in pixels, so at the moment API users may want to use the fbink_get_state() function to get the current screen resolution.

You can also align text WITHIN the printable area defined by the margins. This allows for both horizontal and vertical alignment. With the combination of alignment and margins, some creative positioning can be obtained...

Bold and Italics support is enabled via a simple markdown syntax (eg *italic*, **bold**, ***bold italic***). This is a very simplistic parser, so I would advise doing anything to complicated with it. EDIT: and it will abort if you don't have the appropriate bold and/or italic font loaded, so beware!

Other than that, have fun!

Huge thanks to NiLuJe for letting me play in the FBInk sandbox, and for graciously polishing my code.

(Also, if NiLuJe ever offers you a copy of Bookerly, run far far away. It is an evil version of the font, which made my code blow up...)

[frostschutz]

found some bugs:

- font size 256pt is understood as 0pt (integer overflow)?

- characters missing when using UTF-8 (string length miscalculation)?

xyzäöü1234567890 leaves out 890 presumably because 3 umlauts. is worse for CJK characters presumably because 3-4-byte chars instead of 2-byte-chars.

Otherwise great! I will try to find a way to use this in my FlashCard mod.