inkvt.armhf says: /lib/libc.so.6: version `GLIBC_2.28' not found (required by ./inkvt.armhf)

[tux-linux]

I have a Kobo Libra updated to the latest firmware. I tried to install Inkvt, but libc version is 2.19. I'm not too surprised because every experimental program I install give me unusual issues (karma?). Yours seems to be awesome and I'd like to try it as soon as possible.
Have you an idea on how to fix this?
Thanks

[pgaskin]

This sounds like you're building tools from source code using a modern toolchain. If this is the case, you'll probably want to use koxtoolchain's Kobo toolchain (cc @NiLuJe).

[tux-linux]

Thanks pgaskin for your answer, but... it doesn't work either.
inkvt.sh still reboots my Kobo!

[NiLuJe]

Run readelf on the binary to make sure ;).

EDIT: Also, actual terminal output would be helpful (i.e., run the inkvt binary manually in a shell, first).

[tux-linux]

@NiLuJe : the terminal output is written on the title of the thread

[NiLuJe]

Then you're definitely not building with the right toolchain ;).

[tux-linux]

OK, I'll restart my live Linux and try recompiling from a fresh gcc-arm g++-arm etc. install. I have to build with the koxtoolchain ?

[NiLuJe]

Yes, you really do NOT want to use any random arm TC (especially distro's), you really need the one from koxtoolchain.

[NiLuJe]

Also, the "Waiting 20s for input" message is not a lie: it will really exit ^^.

Running the binary over an SSH shell (be it over WiFi or USBNet) will allow you to basically use your host's keyboard without having to bother about any other way of handling that.

[tux-linux]

@NiLuJe thanks! Koxtoolchain is setting up now... Building binutils (mmh... this will take a long time!)
I'll let you know if it works or not

[tux-linux]

And....... it works! And it's AWESOME!!!!!!! This might be the most awesome hack I've ever done with my Kobo.
One question: is it possible to slightly increase the font size? Because even if I have very sharp eyes, I find out that's a little bit too small...

Issue fixed by installing and compiling with koxtoolchain.
Recommendation: you should say in the description that the current Ubuntu/Arch Linux cross-compiler will NOT work with that.

[NiLuJe]

That's already documented in the Install section of the README ;).

As for the fontsize, there's a switch for that: https://github.com/llandsmeer/inkvt/blob/master/src/main.cpp#L90

A bitmap font being what it is, it's a integer multiplier (i.e., there's a good chance you'll find jumping to 3 too large). In which case you can try out different fonts, because they don't all have the same base cell size: https://github.com/NiLuJe/FBInk/blob/eb1e59da77d51a4b84a7180d6e6861e2f4d15cee/tools/hextoc.py#L74-L106

[tux-linux]

@NiLuJe thanks. I have three questions:

1. What font would you recommend to me other than Terminus?
2. How to change the font?
3. Is it normal that when the font size is set to 2, the terminal 'cuts' the output in the bottom of the screen? I cannot see the output past a few centimeters from the bottom, neither can I see what I input. I have to do "clear" to reset the thing. However, when it's set to 3, the text displays on the whole screen, and scrolls flawlessly when reaching the end. Any ideas?

Thanks

[NiLuJe]

1. Personal preference? Terminus looks just fine for a terminal emulator ;).

2. inkvt/src/main.cpp

   Lines 88 to 89 in c7e1f0c

   	("f,fontname", "FBInk Bitmap fontname, one of ibm, unscii, unscii_alt, unscii_thin, unscii_fantasy, unscii_mcr, unscii_tall, block, leggie, veggie, kates, fkp, ctrld, orp, orpb, orpi, scientifica, scientificab, scientificai, terminus, terminusb, fatty, spleen, tewi, tewib, topaz, microknight, vga or cozette",
   	cxxopts::value<std::string>()->default_value("terminus"))

3. Hmm, show me the initial FBInk greetings in the terminal. And an actual screengrab of what's happening if possible. The row/columns are centered horizontally/vertically if the grid doesn't fit perfectly on screen, which means it may not be edge-to-edge.
   That shouldn't prevent you from ever seeing the first/final col/row, though, quite the contrary, that trick is designed to make them more visible.

i.e., you'd be hard-pressed to notice it (the horizontal centering, especially) w/ terminus x2 on a H2O:

But if I jump to x4, it becomes more obvious (note that the code also fills in the edges w/ bg color if the line is full):

[tux-linux]

Hi,
I installed NeoVim ARM in my Libra and the text seems to show up properly centered on the greetings message. I can't take a screenshot, because I don't currently have the program to.
So... I deduct that the text is properly centered.

[tux-linux]

Any ideas?
Thanks

[NiLuJe]

I have no idea what you're talking about, and I can't help you without actual screengrabs and console output.

Keep in mind that a curses application also requires a proper termdb and a sane matching term.

KoboStuff ships one, and points (shipped) stuff that needs it to it automatically.

[tux-linux]

I have one there:

And there's the output I have when I launch inkvt from SSH:
[admin@storm inkvt-default]# ./inkvt.armhf [FBInk] Detected a Kobo Libra H2O (384 => Storm @ Mark 7) [FBInk] Enabled Kobo Mark 7 quirks [FBInk] Clock tick frequency appears to be 100 Hz [FBInk] Screen density set to 300 dpi [FBInk] Variable fb info: 1264x1680, 32bpp @ rotation: 0 (Upright, 0°) [FBInk] Fontsize set to 16x32 (Terminus base glyph size: 8x16) [FBInk] Line length: 79 cols, Page size: 52 rows [FBInk] Horizontal fit is perfect! [FBInk] Vertical fit isn't perfect, shifting rows down by 8 pixels [FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 9175040 bytes & line length: 5120 bytes [FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background atexit_called

[NiLuJe]

Huh.

Does forcing a full-screen refresh from outside that session (via fbink -k -f) magically makes the missing stuff at the bottom appear?

[tux-linux]

I'll test that

[tux-linux]

No, it doesn't seem to, although it refreshed the screen correctly.

[NiLuJe]

What about fbink -v -y 38 -F terminus -S 2 "foo" ? (If it doesn't display on screen, post the console output).

[tux-linux]

OK I'll try that right away.

[tux-linux]

It works on screen, and here's the console output:
[FBInk] Detected a Kobo Libra H2O (384 => Storm @ Mark 7) [FBInk] Enabled Kobo Mark 7 quirks [FBInk] Clock tick frequency appears to be 100 Hz [FBInk] Screen density set to 300 dpi [FBInk] Variable fb info: 1264x1680, 32bpp @ rotation: 0 (Upright, 0°) [FBInk] Fontsize set to 16x32 (Terminus base glyph size: 8x16) [FBInk] Line length: 79 cols, Page size: 52 rows [FBInk] Horizontal fit is perfect! [FBInk] Vertical fit isn't perfect, shifting rows down by 8 pixels [FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 9175040 bytes & line length: 5120 bytes [FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background Printing string 'foo' @ column 0 + 0px, row 38 + 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: 19, font scaling: x2) Adjusted position: column 0, row 38 Final position: column 0, row 38 Need 1 lines to print 3 characters over 79 available columns Line 1 (of ~1), previous line was 0 characters long and there were 3 characters left to print Characters to print: 3 out of the 3 remaining ones Line takes up 3 bytes snprintf wrote 3 bytes Printing 'foo' @ line offset 0 (meaning row 38) Character count: 3 (over 3 bytes) Adjusting vertical pen position by 0 pixels, as requested, plus 8 pixels, as mandated by the native viewport Region: top=1224, left=0, width=48, height=32 Char 1 out of 3 is @ byte offset 0 and is U+0066 (f) Char 2 out of 3 is @ byte offset 1 and is U+006F (o) Char 3 out of 3 is @ byte offset 2 and is U+006F (o) waveform_mode is now 0x101 (AUTO) Next line should start @ row 39

[NiLuJe]

Huh. Since it's a Libra, and you're running it manually for now, it'll handle rotations, so: what happens if you rotate the device and then just attempt to move the cursor?

[NiLuJe]

On the off-chance it's a weird FBInk bug I don't even remember, try my branch w/ an up-to-date FBInk tree: https://github.com/NiLuJe/inkvt

[NiLuJe]

Sidebar: use triple backticks for multiline code excerpts, it'll preserve newlines that way.

[tux-linux]

I tested with rotations, it handles them perfectly, but still not displays on the bottom.
I'll try with your updated version.
For your third message, I didn't understand it very well

Thanks!

[tux-linux]

EDIT: got it compiling

[tux-linux]

No, it has done nothing that I can see. I still have the same bug.
In last resort, do you have some precompiled binaries?

[NiLuJe]

Unlikely to change anything ;).

I guess you could stick a few printf around the sizing and damage events and see what shakes out?

That, and making FBInk verbose in case the quirk lies there:

diff --git a/src/vterm.hpp b/src/vterm.hpp
index 22ce40a..19ec7ca 100644
--- a/src/vterm.hpp
+++ b/src/vterm.hpp
@@ -275,7 +275,7 @@ public:
         fbink_init(fbfd, &config);
         fbink_cls(fbfd, &config, nullptr);
         fbink_get_state(&config, &state);
-        config.is_quiet = 1;
+        config.is_verbose = 1;
         fbink_update_verbosity(&config);
 
         vtsc = (VTermScreenCallbacks){

[tux-linux]

Ok thanks

[tux-linux]

I have one there:

And there's the output I have when I launch inkvt from SSH:
[admin@storm inkvt-default]# ./inkvt.armhf [FBInk] Detected a Kobo Libra H2O (384 => Storm @ Mark 7) [FBInk] Enabled Kobo Mark 7 quirks [FBInk] Clock tick frequency appears to be 100 Hz [FBInk] Screen density set to 300 dpi [FBInk] Variable fb info: 1264x1680, 32bpp @ rotation: 0 (Upright, 0°) [FBInk] Fontsize set to 16x32 (Terminus base glyph size: 8x16) [FBInk] Line length: 79 cols, Page size: 52 rows [FBInk] Horizontal fit is perfect! [FBInk] Vertical fit isn't perfect, shifting rows down by 8 pixels [FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 9175040 bytes & line length: 5120 bytes [FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background atexit_called

Coming back on this, almost one year later... my Linux knowledge has considerably grown since then!
Seems that with the most recent commit I don't get this issue on my Libra anymore. F/W 4.26 and compiled with koxtoolchain. Still one of the best hacks I've ever done to my Kobos (along with InkBox and serial console hacking ;p)

[tux-linux]

Hmm, actually.
It seems the issue's still there, only differently.

Look closely at the multiple "ls" commands I launched from the bottom of the screen. Before that, I did cat /dev/urandom so that the fb could be filled correctly. Then, CTRL+C and ran ls 3 or 4 times. Seems the output's appearing a bit below the middle of the screen.

[NiLuJe]

That's probably some kind of escape sequence wreaking havoc on the terminal state. Try filling the screen with plain ASCII.

[tux-linux]

Here it is with cat /etc/init.d/rcS, then running a couple of ls. Seems there's a persistent area where the text doesn't change.

[NiLuJe]

Can you still repro #10 (comment)?

(But, regardless, the earlier comment about sticking debugging printfs around both fbink & vte cursor positioning still holds).

[NiLuJe]

Also, in which context is this running and how are the screengrabs taken?

It might be ye olde' 32bpp alpha handling issue, so, it might be fixed either by switching to 8bpp, or by bumping FBInk.

[tux-linux]

I can try running fbdepth before

[tux-linux]

Nothing changes, either with bpp 8, 16 or 32.

[tux-linux]

Can you still repro #10 (comment)?

(But, regardless, the earlier comment about sticking debugging printfs around both fbink & vte cursor positioning still holds).

No, that has been fixed, but as you can see, something else appeared...

[tux-linux]

[FBInk] Detected a Kobo Libra H2O (384 => Storm @ Mark 7)
[FBInk] Enabled Kobo Mark 7 quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 300 dpi
[FBInk] Variable fb info: 1264x1680, 16bpp @ rotation: 0 (Upright, 0°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 9175040 bytes & line length: 2560 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 16x32 (Terminus base glyph size: 8x16)
[FBInk] Line length: 79 cols, Page size: 52 rows
[FBInk] Horizontal fit is perfect!
[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

Here's what doing cat /etc/init.d/rcS then running ls 5 times outputs.
log.txt

[NiLuJe]

Related to this FIXME:

inkvt/src/vterm.hpp

Lines 37 to 40 in 8d1355b

	// FIXME: Make it dynamic, and compute it based on maxcols x maxrows to make it a screenful?
	// (e.g., currently, at default settings, on a Forma, that'd be 90x46 or 90x59 depending on whether the OSK is enabled).
	// That'd render the double-disable workaround in tick superfluous.
	constexpr long HIGH_THROUGHPUT_THRESHOLD = 3000;

The default value happens to work fine on a H2O (67 * 44 = 2948), but apparently not so much for you (79 * 52 = 4108).

I can reproduce similar wonkiness over here if I lower it to 2000.

[NiLuJe]

Made it dynamic, see if https://github.com/NiLuJe/inkvt works?

[tux-linux]

Works flawlessly, thanks!