Native FBInk: Another small tool to print crap on your screen!

[PoP]

I was thinking "what novelty could fbink do today?"

That came to mind:

#cd /mnt/us
#./turn -F mcr
#screenshot

But wait! Why do frame buffer rotations mess screenshots? @NiLuJe Care to shed some light?

[NiLuJe]

I have no idea how the stock screenshot tool works, but it's either going through X, or not expecting hardware rotations.

Use fbgrab, it doesn't rotate anything, so at least the dump will be correct, you may just have to rotate it yourself afterwards, although that shouldn't be necessary on Kindle if it's taken at the original rotation (i.e., whatever matches UR, which is most likely not going to be 0, and is likely to be device-specific to some extent ;p).

[PoP]

Originally Posted by NiLuJe

...Use fbgrab...

I did:

[root@kindle root]# cd /mnt/us
[root@kindle us]# ./turn -F mcr
[FBInk] Detected a Kindle PaperWhite 3 (0G1 -> 0x201 => Muscat on Wario)
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 300 dpi
[FBInk] Variable fb info: 1072x1448, 8bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 1088 bytes
[FBInk] Fontsize set to 24x24 (IBM base glyph size: 8x8)
[FBInk] Line length: 44 cols, Page size: 60 rows
[FBInk] Vertical fit isn't perfect, shifting rows down by 4 pixels
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
...         
[root@kindle us]# fbgrab grab.png
Skipping 0 bytes
Resolution: 1088x1448 -> 1072x1448 (cropping: 16 rightmost pixels) @ depth 8 (invert: no)
No conversion needed
Now writing PNG file (compression 4)
[root@kindle us]#

Same output:
screenshot: fbgrab:

[NiLuJe]

It's possible something's actually writing to the framebuffer during the runtime (status bar?), I'll double-check on a Kobo tomorrow .

Does a plain refresh wreck it the same way? (i.e., fbink -s -f).

[PoP]

The framework is stopped at that time, so no status bar, or other activity.

And yes, after fbink -s -f the physical eink screen is messed up and it matches the screenshot.

[NiLuJe]

Okay, a good night's sleep does wonders for your brain .

Yes, this is perfectly normal: a rotation doesn't actually rotate the framebuffer's *content*. It's still the same block of memory, it just gets addressed differently.

Some kernels *may* just zero the full region after a rotation to hide some of that away, but that doesn't seem to be the case on a Kindle.

So, essentially, this works because eInk, where what's on the screen can be completely different than what's on the framebuffer. It works because each and every time, you're refreshing *just* the right region .

As a quick test, if you display an full-screen image, and just *invert* the rotation, that "works", because the memory layout is identical (a scanline is still the same length). But as soon as you change the layout, things start getting funky .

[PoP]

"The FB contents doesn't get rotated, just the address space." Thanks, makes perfect sense.

Thankfully the Kindle not zeroing after a rotation allowed me to see the effect.

One could take a screenshot before a rotation, rotate the screenshot and fbink the new text over that screenshot graphics to finally be able to capture the effect. I definitely *won't be attempting this*

"It works because each and every time, you're refreshing *just* the right region" Yeah.

"As a quick test" Indeed.

Also of interest?? The PW3 has 3-0-1-2 top-right-bottom-left clockwise rotations and the K3 has 3-0-1-2 right-top-left-bottom counter-clockwise rotations. Go figure.

Insights much appreciated.

[NiLuJe]

Originally Posted by PoP

Also of interest?? The PW3 has 3-0-1-2 top-right-bottom-left clockwise rotations and the K3 has 3-0-1-2 right-top-left-bottom counter-clockwise rotations. Go figure.

This is... complicated. This is related to the way the panel itself is physically mounted, the way the touch layer itself is mounted, and whether it needs a translation or not, and a number of just plain heinous fuckery at the software level in the kernel.

It's mostly irrelevant on Kindle, because no-one cares about fb-level hardware rotation because X11, and the kernels are generally very sane, but it's fresh hell on Kobo, where having a bit of an idea of what the hell the current state is *is* kinda helpful, despite the kernels being wildly bonkers .

[PoP]

Originally Posted by PoP

One could take a screenshot before a rotation, rotate the screenshot and fbink the new text over that screenshot graphics to finally be able to capture the effect. I definitely *won't be attempting this*

Thanks to ImageMagic, I lied (again):

./turn -F mcr -S 4

[EDIT 2020-11-18] updated to v0.40 to support K3
[EDIT 2020-11-20] updated to v0.50 to stop parsing the lyrics (thanks NiLuJe)
[EDIT 2020-11-20] updated to v0.60 use "eval" don't parse

[PoP]

Writing miror images of text: another day another novelty.

/mnt/us/miror -S 10

[NiLuJe]

@PoP:

(Re: a comment in mirror)

You can stop argument parsing by using the magic token -- at the *end* of your list of flags, but *before* the actual "argument".

e.g., fbink -y -1 -mph -- "Wheeee"

(That's a standard GNU behavior, btw ).

[NiLuJe]

And you can also just eval $(fbink -e), no need to try to parse the output, it's already shell-friendly .

c.f., this, where it's used for ${deviceId} .

(-e also always implies -q).

[PoP]

Originally Posted by NiLuJe

@PoP:

(Re: a comment in mirror)

You can stop argument parsing by using the magic token -- at the *end* of your list of flags, but *before* the actual "argument".

i.e., fbink -y -1 -mph -- "Wheeee"

(That's a standard GNU behavior, btw ).

Ah. I didn't know ...turn script updated above, which allowed the amateur in me to faithfully respect the lyrics

[PoP]

Originally Posted by NiLuJe

And you can also just eval $(fbink -e), no need to try to parse the output, it's already shell-friendly .

c.f., this, where it's used for ${deviceId} .

(-e also always implies -q).

I will understand this, my current parsing in the turn script is horrible.

[EDIT 15:20] Got it! Didn't realize that you structured your output for "eval" since day 1. turn script updated above again.

[NiLuJe]

That's kinda why the flag is named -e, --eval ;p.