PocketBook support

[NiLuJe]

This has been bothering me for quite a while, and given the work & progress done in KOReader thanks to @ezdiy & @pazos, I figured it was finally time to give it a final push over the finish line ;).

Obviously, I still don't have a PB to test, so I could only vaguely check that it didn't horribly implode ^^.

In particular, I tried something as regards device identification to avoid a hard-dependency on InkView, hoping that this would help alleviate the various issues we've had with its crappy initialization and old dependencies in KOReader...
Since I'm not quite sure it'll necessarily help in every case, InkView handling can be disabled entirely at runtime by setting FBINK_NO_INKVIEW in the env.
The only thing we actually "need" device identification for is basically just setting a fancy codename and choosing the right DPI, so it's not the end of the world if we get it wrong.
(The only real exception being the weird Color Lux, which is broken by default if we can't ID it).

---

This change is 

[NiLuJe]

Here's a test binary, I'd be grateful if someone with a PB could check that it behaves (especially as far as device identification is concerned: that means I'm interested in the console output ^^) ;).

i.e., fbink -vMmw "Hello" should print Hello in the dead center of the screen.

FBInk-PB-r1.tar.gz

(I've attached all the other utils, but those may not be a great idea on PB, and we don't really have a use for 'em anyway, so, play with them if you want, but it's not critical ^^).

[NiLuJe]

If this behaves, that means we can finally enable fancy OTA feedback & the crash screen on PB in KOReader ;).

[NiLuJe]

I'm hoping there aren't any rotation shenanigans involved, but do warn me if stuff ends up being printed sideways ;p.

[ezdiy]

Hello appeared (landscape). Regarding inkview, it's possible to prod the task manager into "bring us into foreground" via ipc queue that is stable across inkview versions. This is the route used in an old pocketbook root exploit - https://github.com/ezdiy/pbjb/blob/v6/jailbreak.c#L34

Dealing with input is harder. While real linux evinput exists, it's hogged by the monitor proccesses that then signals individual apps via sysv ipc (acts as hub/subscriber). What happens once we stomp on it is uncertain but if we could, it would possibly mean getting rid of inkview entirely, just sending few os integration ipcs by hand.

[NiLuJe]

@ezdiy: Ah. Was afraid of that given the rotation discussion we had earlier ^^.

So, new question: Landscape in which orientation? Bottom of the text on the left or the right side of the device (when the device itself is physically in Portrait in front of you)?

(I wouldn't mind having a look at the console output regardless ;)).

---

Thankfully, I don't really have to deal with input in FBInk itself, so, wheee \o/.
Likewise as far as the stock system is concerned, we're basically doing everything by hand, so we should be flying under the radar.

[ezdiy]

Top right corner is 0,0. ie need to rotate 90 CCW, but this might be model specific.

Fun trick: echo 1 > /sys/class/graphics/fb0/rotate sets portrait rotation (and koreader can enjoy faster blits) .... until any other inkview app paints anything and it gets reset back to landscape (2). I'm not sure whether it's some ioctl doing it, or monitor/inkview writing to the variable itself, or whether we could affect that without need for root.

EDIT: It seems that 'rota' utility can set rotation, without need for root:

Rotate is now 1 (Clockwise, 90°)
Variable fb info: 1404x1872, 8bpp @ rotation: 1 (Clockwise, 90°)
Fixed fb info: ID is "", length of fb mem: 2637824 bytes & line length: 1408 bytes
^C

Would be nice if koreader could do the same?

[NiLuJe]

Huh. Well, if something is essentially preventing making use of HW rotations, I won't have to bother with a finer-grained check then (silver lining and all that ^^).

This one should print the right way round.

FBInk-PB-r2.tar.gz

[ezdiy]

Seems like inkview just brute sets FBIOPUT_VSCREENINFO right before it sends update request (ie presumable it does that before it blits into framebuffer).

Rotation values when viewed from portrait:
0 = 0,0 at bottom left (left hand landscape)
1 = 0,0 at top left (portrait, desired)
2 = 0,0 at top right (right hand landscape, spammed by inkview always regardless of orientation, it performs rots in SW)
3 = 0,0 at bottom right (portrait upside down)

[NiLuJe]

fbdepth -r 1 should essentially do the same thing.

This is what we use on Kobo to avoid the perf hit, but, of course there's a twist: it's extremely device-dependent on Kobo, and that's with actual mostly-accurate kernel sources on hand. So fbdepth has a 'magic' -1 value that attempts to do the right thing everywhere automagically on Kobo.

So, if there's a way to figure that out on PB (or it turns out it's always 1... one could hope ;p), then, yeah, that's definitely viable (I mean, the touch translation might have been to be fixed to handle it, but that's worth the effort), but it might be easier said than done.

Plus, that's assuming nothing randomly stomps on the rotation behind our backs? I haven't ever used a PB device, so I have no idea what/when InkView might try to do just that ;).

[ezdiy]

I presume if we spam the FBIOPUT_VSCREENINFO per update just like inkview does it's fine - if they steal our focus they paint correctly, and so do we if we steal focus back. The touch translation will be the annoying part indeed.

[NiLuJe]

Fair point ;p. That feels a wee bit dirty, though, but, oh, well ^^.

And that's assuming we actually know which rotation is the right one, as I said earlier.
And that no kernels have funky behavior on FBIOPUT_VSCREENINFO like on NTX, where nearly all of them will do extremely weird crap to the rotation flag ^^.

(That's the point of the rota tool, actually: checking if what you get after it is actually what you asked for ^^).

[ezdiy]

The autodetection is only 50% - one can discern rotation for portrait vs landscape from reported screen res - however one cannot for upside down :/. Guess just user configurable knob for that will suffice.

Also, the r2 fbink just does:

rapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0
Wrapped row back to 0

in infinite loop.

[NiLuJe]

Huh. Can you drop the -v flag and post the full terminal output? (it'll still hang, though ^^).

(And, yeah, right now the plan was only to get Upright, well, right ;p).

[ezdiy]

Still hangs:

/mnt/ext1 # ./fbink -Mmw "Hello"
[FBInk] Detected a PocketBook (PBInkPad3Pro)
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 300 dpi
[FBInk] Variable fb info: 1872x1404, 8bpp @ rotation: 2 (Upside Down, 180°)
[FBInk] Fixed fb info: ID is "", length of fb mem: 2637824 bytes & line length: 1872 bytes
[FBInk] xres_virtual -> 1888
[FBInk] yres_virtual -> 1408
[FBInk] line_length -> 1888
[FBInk] yres_virtual => 1408
[FBInk] line_length <- 1872
[FBInk] xres_virtual <- 1872
[FBInk] yres_virtual <- 1404
[FBInk] Enabled PocketBook rotation quirks (1872x1404 -> 1404x1872)
[FBInk] Fontsize set to 32x32 (IBM base glyph size: 8x8)
[FBInk] Line length: 0 cols, Page size: 0 rows
[FBInk] Horizontal fit is perfect!
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Printing string 'Hello' @ column 0 + 0px, row 0 + 0px (overlay: N, no BG: N, no FG: N, inverted: N, flashing: N, centered: Y, halfway: Y, left padded: N, right padded: N, clear screen: N, waveform: AUTO, dithering: PASSTHROUGH, nightmode: N, skip refresh: N, font: 0, font scaling: x0)

[NiLuJe]

Yeah, I'd forgot a few important bits inside the PB ifdef ;p.

This should do it:

FBInk-PB-r3.tar.gz

[ezdiy]

No hang, but draws nothing, huh:

/mnt/ext1 # ./fbink -vMmw "Hello"
[FBInk] Detected a PocketBook (PBInkPad3Pro)
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 300 dpi
[FBInk] Variable fb info: 1872x1404, 8bpp @ rotation: 2 (Upside Down, 180°)
[FBInk] Fixed fb info: ID is "", length of fb mem: 2637824 bytes & line length: 1872 bytes
[FBInk] xres_virtual -> 1888
[FBInk] yres_virtual -> 1408
[FBInk] line_length -> 1888
[FBInk] yres_virtual => 1408
[FBInk] line_length <- 1872
[FBInk] xres_virtual <- 1872
[FBInk] yres_virtual <- 1404
[FBInk] Enabled PocketBook rotation quirks (1872x1404 -> 1404x1872)
[FBInk] Fontsize set to 32x32 (IBM base glyph size: 8x8)
[FBInk] Line length: 43 cols, Page size: 58 rows
[FBInk] Vertical fit isn't perfect, shifting rows down by 8 pixels
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Printing string 'Hello' @ column 0 + 0px, row 0 + 0px (overlay: N, no BG: N, no FG: N, inverted: N, flashing: N, centered: Y, halfway: Y, left padded: N, right padded: N, clear screen: N, waveform: AUTO, dithering: PASSTHROUGH, nightmode: N, skip refresh: N, font: 0, font scaling: x0)
Adjusted row to 29 for vertical centering
Adjusted position: column 0, row 29
Final position: column 0, row 29
Need 1 lines to print 5 characters over 42 available columns
Line 1 (of ~1), previous line was 0 characters long and there were 5 characters left to print
Characters to print: 5 out of the 5 remaining ones
Line takes up 5 bytes
Adjusted column to 19 for centering
snprintf wrote 5 bytes
Printing `Hello` @ line offset 0 (meaning row 29)
Character count: 5 (over 5 bytes)
Incrementing pixel_offset by 14 pixels to compensate for dead space on the right edge
Adjusting vertical pen position by 0 pixels, as requested, plus 8 pixels, as mandated by the native viewport
Region: top=936, left=608, width=160, height=32
Moving pen 14 pixels to the right to honor subcell centering adjustments
Updated region.left to 622
Char 1 out of 5 is @ byte offset 0 and is U+0048 (H)
Char 2 out of 5 is @ byte offset 1 and is U+0065 (e)
Char 3 out of 5 is @ byte offset 2 and is U+006C (l)
Char 4 out of 5 is @ byte offset 3 and is U+006C (l)
Char 5 out of 5 is @ byte offset 4 and is U+006F (o)
waveform_mode is now 0x101 (AUTO)
Next line should start @ row 1
Update 15656 has already fully been completed

[NiLuJe]

That means I probably got the rotation wrong ^^.

If yo do a simple full-screen refresh right after, it'll probably show up, possibly upside down or something:

fbink -f -s

[ezdiy]

Indeed it appeared. Also the centering is wrong (appears in center of top left quadrant, looks like the source axes for centering are flipped), and oriented in hw landscape still. Maybe just forgo sw rotate and set hw rot?

[NiLuJe]

Ah, lightbulb moment.

The (blitting) code currently bypasses rotation @ 8bpp >_<".

[NiLuJe]

Okay, this should finally work ^^.

FBInk-PB-r4.tar.gz

[ezdiy]

Yup, does the right thing.

[NiLuJe]

Yay \o/.

Many thanks for testing this :).

Off to bed now, and I'll probably merge this and the KOReader stuff tomorrow ;).

[pazos]

Obviously, I still don't have a PB to test, so I could only vaguely check that it didn't horribly implode ^^.

@NiLuJe: I would be happy to send you the Pocketbook Touch HD3 that @Cellaris sent me.

[NiLuJe]

Obviously, I still don't have a PB to test, so I could only vaguely check that it didn't horribly implode ^^.

@NiLuJe: I would be happy to send you the Pocketbook Touch HD3 that @Cellaris sent me.

I may ultimately take you up on that offer, but not right now ;). Things are going to be pretty hectic on my end until at least winter break ;).