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

[NiLuJe]

Oh, perhaps more importantly: you might want to swap axes *before* mirroring, otherwise you end up mirroring the wrong axis .

[sublipri]

Originally Posted by NiLuJe

We talked briefly on Discord a while ago, did we?

I don't think we've ever talked before - I don't use Discord.

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

fbink_input_scan looks useful! I'll try out using that in the future.

* 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?

I tried running finger_trace on the Glo and it doesn't behave properly in landscape (but does in portrait). Swiping from the bottom left to the top left (relative to landscape) leads to a line being drawn from the top right to the bottom right.

I'm forcing the Glo into landscape by setting ForceAllowLandscape=true in Kobo eReader.conf and then selecting Landscape rotation in Nickel. I've attached the results of a devcap test.

Originally Posted by NiLuJe

Oh, perhaps more importantly: you might want to swap axes *before* mirroring, otherwise you end up mirroring the wrong axis .

I had originally swapped the axes before mirroring like in ftrace, but that didn't work. I tried a whole bunch of things without really understanding what I was doing (I'm terrible at maths ), and the current code was the only way I could get it to work on my devices. I thought perhaps since I'm translating the coordinates from canonical to native rather than native to canonical, that swapping the axes at the end was the correct thing to do. But I don't really understand why it works or whether it will actually work on other devices.

[NiLuJe]

Originally Posted by sublipri

I'm forcing the Glo into landscape by setting ForceAllowLandscape=true in Kobo eReader.conf and then selecting Landscape rotation in Nickel.

Does that actually result in fbink/fbdepth/ftrace reporting a landscape rotation as the canonical one?

(i.e., does this *actually* rotate the framebuffer in some way, or does Nickel handle rotation entirely in software on that device).

If it actually rotates the framebuffer, I've got a wrong mapping in fbink; but if it's software rotated, it's working as intended .

[NiLuJe]

Originally Posted by NiLuJe

(i.e., does this *actually* rotate the framebuffer in some way, or does Nickel handle rotation entirely in software on that device).

It does do a HW rotate to CCW (canonical) on a H2O, FWIW.

In which case... does this patch fix it?

diff --git a/fbink_device_id.c b/fbink_device_id.c
index c324c0c..9a10530 100644
--- a/fbink_device_id.c
+++ b/fbink_device_id.c
@@ -644,8 +644,14 @@ static void
                        strtcpy(deviceQuirks.devicePlatform, "Mark 4", sizeof(deviceQuirks.devicePlatform));
                        break;
                case DEVICE_KOBO_GLO:    // Glo (kraken)
-                       deviceQuirks.isKoboNonMT = true;
-                       deviceQuirks.screenDPI   = 212U;
+                       deviceQuirks.isKoboNonMT                = true;
+                       // {3, 2, 1, 0}, but no ioctl quirks
+                       deviceQuirks.ntxRotaQuirk               = NTX_ROTA_CCW_TOUCH;
+                       deviceQuirks.rotationMap[FB_ROTATE_UR]  = FB_ROTATE_CCW;
+                       deviceQuirks.rotationMap[FB_ROTATE_CW]  = FB_ROTATE_UD;
+                       deviceQuirks.rotationMap[FB_ROTATE_UD]  = FB_ROTATE_CW;
+                       deviceQuirks.rotationMap[FB_ROTATE_CCW] = FB_ROTATE_UR;
+                       deviceQuirks.screenDPI                  = 212U;
                        strtcpy(deviceQuirks.deviceName, "Glo", sizeof(deviceQuirks.deviceName));
                        strtcpy(deviceQuirks.deviceCodename, "Kraken", sizeof(deviceQuirks.deviceCodename));
                        strtcpy(deviceQuirks.devicePlatform, "Mark 4", sizeof(deviceQuirks.devicePlatform));

(Ideally, without breaking other rotations ;p. i.e., check `ftrace` in each rotation: `fbdepth -R UR` then `-R CW` -> `-R UD` -> `-R CCW`).

Keep in mind it means rotating the *device* itself, not the buffer. e.g., what Nickel does for landscape for me is a CCW rotate.

[NiLuJe]

Oops, fixed the patch above .

----

On that note, the sunxi devices (e.g., your Sage) do not support linuxfb hardware rotation at all, so they behave entirely differently (i.e., rotation is handled by the driver at blit-time). FBInk hides the mess away by returning potentially sensible rotate constants, but it's entirely fake ^^.

That also means things gets wonky if FBInk is not the one that triggered the rotation, because the only thing we can do is query the accelerometer... and that can be finicky as hell .

[sublipri]

Originally Posted by NiLuJe

Does that actually result in fbink/fbdepth/ftrace reporting a landscape rotation as the canonical one?

(i.e., does this *actually* rotate the framebuffer in some way, or does Nickel handle rotation entirely in software on that device).

If it actually rotates the framebuffer, I've got a wrong mapping in fbink; but if it's software rotated, it's working as intended .

It does appear to actually rotate the framebuffer.

Portrait:

[FBInk] Detected a Kobo Glo (330 => Kraken @ Mark 4)
[FBInk] Enabled Kobo w/o Multi-Touch quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 212 dpi
[FBInk] Variable fb info: 758x1024, 32bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 3145728 bytes & line length: 3072 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 16x16 (IBM (Default) base glyph size: 8x8)
[FBInk] Line length: 47 cols, Page size: 64 rows
[FBDepth] Screen is 758x1024 (768x1024 addressable, fb says 768x1024)
[FBDepth] Buffer is mapped for 3145728 bytes with a scanline stride of 3072 bytes

Landscape:

[FBInk] Detected a Kobo Glo (330 => Kraken @ Mark 4)
[FBInk] Enabled Kobo w/o Multi-Touch quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 212 dpi
[FBInk] Variable fb info: 1024x758, 32bpp @ rotation: 0 (Upright, 0°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 3145728 bytes & line length: 4096 bytes
[FBInk] Canonical rotation: 1 (Clockwise, 90°)
[FBInk] Fontsize set to 16x16 (IBM (Default) base glyph size: 8x8)
[FBInk] Line length: 64 cols, Page size: 47 rows
[FBInk] Horizontal fit is perfect!
[FBInk] Vertical fit isn't perfect, shifting rows down by 3 pixels
[FBDepth] Screen is 1024x758 (1024x768 addressable, fb says 1024x768)
[FBDepth] Buffer is mapped for 3145728 bytes with a scanline stride of 4096 bytes

Your patch does fix it! The canonical rotation for Nickel's landscape is now reported as CCW, and ftrace behaves correctly in all 4 rotations. The cursor in my remote works in landscape too

Originally Posted by NiLuJe

That also means things gets wonky if FBInk is not the one that triggered the rotation, because the only thing we can do is query the accelerometer... and that can be finicky as hell .

I have noticed the accelerometer rotation detection occasionally being out of sync with Nickel on my Sage. Think I'll make sunxi_force_rota user-configurable in my remote so people can lock it to a certain rotation if they want.

[NiLuJe]

Originally Posted by sublipri

Your patch does fix it!

Great, thanks for testing that, I've pushed the fix!

Originally Posted by sublipri

I have noticed the accelerometer rotation detection occasionally being out of sync with Nickel on my Sage. Think I'll make sunxi_force_rota user-configurable in my remote so people can lock it to a certain rotation if they want.

Yeah, especially for a device that's not actually held by a human, things can very easily get wonky when it can't decide whether it's face up or face down...

You can also set `FBINK_FORCE_ROTA` in the env to any of the values accepted by `fbink_sunxi_ntx_enforce_rota`, that'll be honored by the first `fbink_init` call .

[lordeagle]

Bought a Kobo Eclipsa2E and found out that it's not recognized by fbink. (using FBInk v1.24.0-78-g69a7f10 for Kobo)

Any chance to get this running?

[root@kobo ~]# fbink -x 1 -y 10 "Hello World!"
[FBInk] Unidentified Kobo device code (389)!
[FBInk] Detected a Kobo Unknown! (389 => ?? @ Mark ?)
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 167 dpi
[FBInk] Variable fb info: 1404x1872, 32bpp @ rotation: 1 (Clockwise, 90°)
[FBInk] Fixed fb info: ID is "hwtcon", length of fb mem: 10543104 bytes & line length: 5616 bytes
[FBInk] Canonical rotation: 2 (Upside Down, 180°)
[FBInk] Fontsize set to 16x16 (IBM base glyph size: 8x8)
[FBInk] Line length: 87 cols, Page size: 117 rows
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Printing string 'Hello World!' @ column 1 + 0px, row 10 + 0px (overlay: N, no BG: N, no FG: N, inverted: N, flashing: N, centered: N, halfway: N, left padded: N, right padded: N, clear screen: N, waveform: AUTO, dithering: PASSTHROUGH, nightmode: N, skip refresh: N, font: 0, font scaling: x0)
[FBInk] [refresh_kobo] MXCFB_SEND_UPDATE_V1_NTX: Interrupted system call!
[FBInk] [fbink_print] Failed to refresh the screen!
[CLI] Failed to print that string!

[PeterT]

Originally Posted by lordeagle

Bought a Kobo Eclipsa2E and found out that it's not recognized by fbink. (using FBInk v1.24.0-78-g69a7f10 for Kobo)

Any chance to get this running?

While it looks like there have been code updates to handle newer device, there has been no release created that includes those fixes.

[lordeagle]

Originally Posted by PeterT

While it looks like there have been code updates to handle newer device, there has been no release created that includes those fixes.

Yes, you are right, there seems actually to be ECLIPSA_2E support in the latest sources; https://github.com/NiLuJe/FBInk/blob...ice_id.c#L1000

Any chance to get this officially released @NiLuJe.

[lordeagle]

Originally Posted by lordeagle

Yes, you are right, there seems actually to be ECLIPSA_2E support in the latest sources; https://github.com/NiLuJe/FBInk/blob...ice_id.c#L1000

Any chance to get this officially released @NiLuJe.

Ok, thanks to the nice github/actions environment it was an easy job to get the latest binaries.

And I can confirm, with the current snapshot the Eclipsa 2E works.

[root@kobo bin]# fbink -x 1 -y 10 "Hello World!"
[FBInk] Detected a Kobo Elipsa 2E (389 => Condor @ Mark 11)
[FBInk] This device does not support HW inversion
[FBInk] Enabled MediaTek quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 227 dpi
[FBInk] Variable fb info: 1404x1872, 32bpp @ rotation: 1 (Clockwise, 90°)
[FBInk] Fixed fb info: ID is "hwtcon", length of fb mem: 10543104 bytes & line length: 5616 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 24x24 (IBM base glyph size: 8x8)
[FBInk] Line length: 58 cols, Page size: 78 rows
[FBInk] Framebuffer pixel format: RGB32
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Printing string 'Hello World!' @ column 1 + 0px, row 10 + 0px (overlay: N, no BG: N, no FG: N, inverted: N, flashing: N, centered: N, halfway: N, left padded: N, right padded: N, clear screen: N, waveform: AUTO, dithering: None, nightmode: N, skip refresh: N, font: 0, font scaling: x0)
Next line should start @ row 11

[readern4vi]

Hello,

I just wanted to understand if this patch works on Libra Colour.

I installed FBInk on my Kobo, since it is necessary to make the QR code show up with this Kobo File Server mod.

The following is the code from this mod, that should display the image on the Kobo. However, when I test it on my actual Libra, it does not display.

#!/bin/sh

WORK_DIR="${0%/*}"

FBINK=/usr/bin/fbink

$WORK_DIR/kobofileserver >>$WORK_DIR/log.txt 2>&1 &

sleep 1s

[ -e "$FBINK" ] && $FBINK -g file=$WORK_DIR/qrcode.png,halign=CENTER,valign=CENTER -f

Is this an issue with the code of the mod, or does FBInk need to be updated for Libra Colour?

[mergen3107]

What is Kobo Eclipsa 2E?
Do you mean Elipsa 2E?

[mergen3107]

Nevermind, it is Elipsa (saw in the other thread of yours)

[NiLuJe]

@readern4vi: Like the poster above, you'll need to grab a current snapshot from a GitHub Action to get a binary that supports your device.