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 .