looking for a prebuilt version

[fennectech]

i dont have the ability to compile this can someone post a compiled version of this app?

[NiLuJe]

I've just setup automated builds in my branch, FWIW.

(e.g., right now the latest artifacts are at https://github.com/NiLuJe/inkvt/actions/runs/3617312390).

I don't quite remember how long GitHub retains build artifacts, though.

[fennectech]

Awesome! Mind if i download and post a link thta is more perminant?

[fennectech]

Ill put together an nickelmenu file for it and share it here

[NiLuJe]

It's been ages since this has been tested inside Nickel, FWIW.

[fennectech]

Well. Ill be testing it tomorrow :)

[fennectech]

Inkvt works fine but the nickel.sh is all sorts of broken. The result is a very broken display but nickel is running underneeth it. Everything is giant. It’s like what you’d see with a very fucked up modeline in x randr. If you’d like to troubleshoot it with me id be glad to help. It’s a kobo Clara HD which has a different display size and resolution than before. Its likely something simple as it ‘almost’ works

[NiLuJe]

The crash.log (in .adds/inkvt) would be a good start ;).

[fennectech]

I was pebcaking (running nickel.sh from inkvt) when you should just type exit

[fennectech]

it works that way if inkvt was run from the terminal. but not if inkvt wsa run from nickelmenu. here is the crash.log

crash.log This is when exiting inkvt from nickelmenu wiht a 9999 timeout It works exactly as expected until you exit

[fennectech]

and here is a crash.log from a clean exit. crash.log

[NiLuJe]

What are you actually doing in both cases?

(and, yeah, don't run nickel.sh manually, ever).

[fennectech]

If i run “inkvt.sh” from a terminal via SSH everything works fine. But if inkvt.sh is run from nickelmenu exiting inkvt via the “exit” command or issuing “killall inkvt.armh7” from ssh results in this screenshot

[randerzander]

does anyone have a valid link to a pre-built version of this? Ideally one that works on a Kobo Clara 2E :)

[NiLuJe]

I seem to recall having setup GH Actions for that in the fork. The FBInk bump might not be recent enough for the Clara 2E, though, can't recall.

EDIT: Eh, it should. At least for the screen. Rotation/input might be fucked up, though, as usual. Given our experience with the current Kobo lineup still on NXP SoCs, it might also horribly hang the kernel extremely quickly ;o).

[randerzander]

Thanks for the quick response. Unfortunately the action result says expired. "This artifact is expired and you can no longer download it."

[NiLuJe]

Yay, github.

I'm not on my dev machine, so it'll have to way ;).

[randerzander]

I tried building from your fork, but ran into a couple of problems. (your repo has GitHub issues disabled, so leaving here in case others try this):

In Makefile, I changed:

#CROSS_TC?=arm-kobo-linux-gnueabihf
CROSS_TC?=arm-linux-gnueabihf

But then on building, I get:

make[2]: Leaving directory '/home/dev/projects/kobo/inkvt/FBInk'arm-linux-gnueabihf-gcc  -DNDEBUG -D_REENTRANT=1 -D_GNU_SOURCE -DFBINK_FOR_KOBO -Ilibi2c-staged/include -DFBINK_WITH_DRAW -DFBINK_WITH_BITMAP -DFBINK_WITH_FONTS -DFBINK_WITH_IMAGE -DFBINK_WITH_OPENTYPE -DFBINK_WITH_BUTTON_SCAN -O2 -fomit-frame-pointer -pipe -ftree-vectorize -funroll-loops -fno-common -Wall -Wextra -Wunused -Wformat=2 -Wformat-signedness -Wformat-truncation=1 -Wnull-dereference -Wuninitialized -Wduplicated-branches -Wduplicated-cond -Wundef -Wbad-function-cast -Wwrite-strings -Wjump-misses-init -Wlogical-op -Wstrict-prototypes -Wold-style-definition -Wshadow -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wcast-qual -Wcast-align -Wconversion -Wno-jump-misses-init  -DFBINK_VERSION='"v1.25.0 for Kobo"' -flto=24 -fuse-linker-plugin -Wl,--as-needed -L./Release -Llibi2c-staged/lib -oRelease/fbdepth utils/fbdepth.c -l:libfbink.a -l:libi2c.a -lm
/usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/ld: libi2c-staged/lib/libi2c.a: error adding symbols: file format not recognizedcollect2: error: ld returned 1 exit statusmake[1]: *** [Makefile:667: fbdepth] Error 1make[1]: Leaving directory '/home/dev/projects/kobo/inkvt/FBInk'
make: *** [Makefile:131: build/fbdepth] Error 2

Not sure how to go about debugging that one

[NiLuJe]

Where does that TC come from?

[randerzander]

Where does that TC come from?

https://github.com/NiLuJe/inkvt/blob/master/Makefile#L3

Ahh, if you mean where did I get the compiler, at first I followed this article on installing the cross compile tool chain. Then I sudo apt install gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf, based on the instructions in the inkvt README.

[NiLuJe]

There's your mistake ;o).

You'll want https://github.com/koreader/koxtoolchain (and right now, probably a binary from the releases tab, as it won't build with make >= 3.4 without extra shenanigans).

[fennectech]

Touch doesn’t work on Clara 2E. Do you guys have any fixes?

[NiLuJe]

It should be behaving in my fork, but I admittedly can't test that.

(Also, in which conditions were you testing it?).

You're welcome to run the devcap script from FBInk devcap make target on your device for more details about its behavior, and I'll take a look at the log it spits out.

[fennectech]

I tried running it from the command line (running the script over ssh which worked properly over SSH Ill gave your dev cap thing a try in af ew hours

[fennectech]

could you build it for me? I dont have a working build enviroment for kobo

[fennectech]

when running your forks inkvt.sh (from 4 hours ago) from the command line over ssh the keyboard input comes from the ssh console and the on screen keyboard is entirely ignored also the letters on the screen are very smaall on clara HD and clara 2e

[NiLuJe]

What's running in the background when you're testing? (Nickel? KOReader? Plato? Nothing?).

To be clear: this repo does not support the Clara 2E. at all. That something shows up on screen is blind luck (and the kernel's compat ioctl ;p).

My fork should, which is why you're seeing a different DPI setting. Touch input is another kettle of fish, but it should be working... at least in the standard portrait orientation.

[fennectech]

Original fb rotation is set @ 3
Original fb bitdepth is set @ 32bpp
Switching fb bitdepth to 8bpp & rotation to Portrait
[FBInk] Detected a Kobo Clara 2E (386 => Goldfinch @ Mark 10)
[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: 1072x1448, 32bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 4352 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 24x24 (IBM (Default) 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] Detected a change in framebuffer bitdepth (32 -> 8)
[FBInk] Reinitializing...
[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] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 24x24 (IBM (Default) 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
[FBDepth] Screen is 1072x1448 (1088x1558 addressable, fb says 1088x1536)
[FBDepth] Buffer is mapped for 6782976 bytes with a scanline stride of 4352 bytes
[FBDepth] Requested canonical rota 0 translates to 3 for this device
[FBDepth] Current rotation is already 3!
[FBDepth] Switching fb to 8bpp @ rotation 3 . . .
Updating bitdepth from 32bpp to 8bpp
Sanitizing grayscale flag for 8bpp
Updating rotation from 3 (Counter Clockwise, 270°) to 3 (Counter Clockwise, 270°)
Bitdepth is now 8bpp (grayscale: 1) @ rotate: 3 (Counter Clockwise, 270°)
[FBDepth] Screen is 1072x1448 (1088x6234 addressable, fb says 1088x3072)
[FBDepth] Buffer is mapped for 6782976 bytes with a scanline stride of 1088 bytes
[FBInk] Detected a Kobo Clara 2E (386 => Goldfinch @ Mark 10)
[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: 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] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 16x32 (Terminus base glyph size: 8x16)
[FBInk] Line length: 67 cols, Page size: 45 rows
[FBInk] Horizontal fit is perfect!
[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
opened touch input device
atexit_called
Restoring original fb bitdepth @ 32bpp & rotation @ 3
[FBInk] Detected a Kobo Clara 2E (386 => Goldfinch @ Mark 10)
[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: 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] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 24x24 (IBM (Default) 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] Detected a change in framebuffer bitdepth (8 -> 32)
[FBInk] Reinitializing...
[FBInk] Variable fb info: 1072x1448, 32bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 4352 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 24x24 (IBM (Default) 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
[FBDepth] Screen is 1072x1448 (1088x6234 addressable, fb says 1088x3072)
[FBDepth] Buffer is mapped for 6782976 bytes with a scanline stride of 1088 bytes
[FBDepth] Current rotation is already 3!
[FBDepth] Switching fb to 32bpp @ rotation 3 . . .
Updating bitdepth from 8bpp to 32bpp
Sanitizing grayscale flag for bitdepths > 8bpp
Updating rotation from 3 (Counter Clockwise, 270°) to 3 (Counter Clockwise, 270°)
Bitdepth is now 32bpp (grayscale: 0) @ rotate: 3 (Counter Clockwise, 270°)
[FBDepth] Screen is 1072x1448 (1088x1558 addressable, fb says 1088x1536)
[FBDepth] Buffer is mapped for 6782976 bytes with a scanline stride of 4352 bytes

{21:02} Sun May 28
[root@kobo /mnt/onboard/.adds/inkvt]#  ls                                      
crash.log  inkvt.armhf  inkvt.startup    nickel.sh
fbdepth    inkvt.sh inkvtstartup.sh

I am running your fork wiht the build artifact from 4 hours ago here is crash.log Nickel is running when the script is run from the command line Over ssh as root

[NiLuJe]

Everything looks good there, FWIW.

I don't remember if there's input logging available in there, but that doesn't matter, because I know there is in ftrace and it's going to be much more useful anyway, so we're back to the devcap package ;o).

[fennectech]

could you send me a binary? i dont have a build enviroment for kobo

[NiLuJe]

Here goes:

Kobo-DevCap-Test.tar.gz

Untar, run devcap_test.sh, follow the on-screen prompt near the end, and post the generated Kobo-DevCap-Results.tar.gz.

You'll also want to run finger_trace and see if it actually follows your touch coordinates properly (if not, send me the console output of a simple run where you tried something simple, like a bunch of taps in the top-left corner).

(You may want to sigstop/sigcont nickel to prevent stray refreshes during that).

[fennectech]

https://ufile.io/v2l5qdhv Here is that file :) By the way Thank you for all you have done in the kindle scene! ive got a kindle 3 keyboard with usbnet

[NiLuJe]

(You could have attached it to GH natively).

Were the orientation markings accurate (e.g., CCW on the left, CW on the right, UR on the bottom, UD at the top; the numbers may be different, but the letters should be in the right place), like in https://github.com/NiLuJe/FBInk/blob/master/utils/devcap_expected_results.png

And that still leaves finger_trace, which is arguably the most interesting test in the context of input issues ;o).

[NiLuJe]

when running your forks inkvt.sh

Oh. Don't do that. That script is woefully unmaintained.

Run inkvt_armhf directly, and pass it --osk (IIRC) if you actually need an OSK.

[fennectech]

Run inkvt_armhf directly, and pass it --osk (IIRC) if you actually need an OSK. I tried that too. And yes. The markings were accurate. Ill run finger trace now

[fennectech]

fingertrace.txt Here is fingertrace output From top left to bottom right it seems to work fine

[fennectech]

opened touch input device
[FBInk] Detected a Kobo Clara 2E (386 => Goldfinch @ Mark 10)
[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: 1072x1448, 32bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 4352 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 16x32 (Terminus base glyph size: 8x16)
[FBInk] Line length: 67 cols, Page size: 45 rows
[FBInk] Horizontal fit is perfect!
[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

touching OSK is still entirely unresponsive

[fennectech]

when running your forks inkvt.sh

Oh. Don't do that. That script is woefully unmaintained.

Run inkvt_armhf directly, and pass it --osk (IIRC) if you actually need an OSK.

The script still works fine its just touch input that isnt working And it works well because it nicely wraps up nickel which makes running it from nickelmenu work well (but without touch its kinda useless lmao)

[NiLuJe]

That's probably because there was a stupid typo in the input device selection. :D

[NiLuJe]

fingertrace.txt Here is fingertrace output From top left to bottom right it seems to work fine

Did it ever detect a contact lift properly?

[fennectech]

No. It does not!

[fennectech]

It’s only “Down”

[NiLuJe]

No. It does not!

Oh, yeah, makes sense given the input stream, we never get a 0-pressure event.

[NiLuJe]

There, contact lift detection ought to be fixed in both finger_trace & inkvt ;).

[fennectech]

Could you create a shell script that pauses nickel when it’s launched and resumes nickel on exit? That way inkvt could easily be launched from nickelmenu If we include this along with inkvt that would make an easy way to use it!

[NiLuJe]

No, because you can't do that ;).

If you sigstop Nickel on start and sigcont it on exit, it'll get blasted by the full evdev queue it missed, and things get super wonky.

That's (mostly) fine for a very short process with few input requirements (e.g., that's what the devcap script does), but not really for any full-fledged application; which is why KOReader has been killing nickel pretty much forever.

(We can do more fine grained murdering on Kindle, FWIW, but that's mostly because the system is vastly more modular (to... the opposite extreme, really ;p)).

[fennectech]

Is it possible to flush the evdev queue before sigconting nickel?

[NiLuJe]

Nope, it's a private state tied to each fd handle.

[NiLuJe]

There's also input grabbing shenanigans involved on unpatched nickel, too.

(ironically, an exclusive grab is a way to sorta workaround this... assuming you can actually grab it in the first place. IIRC, that's also a factor in the Kindle thing I mentioned earlier).

On Tue, May 30, 2023, 07:39 FennecTECH @.***> wrote:

Is it possible to flush the evdev queue before sigconting nickel?

— Reply to this email directly, view it on GitHub https://github.com/llandsmeer/inkvt/issues/24#issuecomment-1567782043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3KZWRZTFYQ7F4QZOKBLLXIWBZ5ANCNFSM6AAAAAASL4KNQA . You are receiving this because you commented.Message ID: @.***>