looking for a prebuilt version #24
Comments
|
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. |
|
Awesome! Mind if i download and post a link thta is more perminant? |
|
Ill put together an nickelmenu file for it and share it here |
|
It's been ages since this has been tested inside Nickel, FWIW. |
|
Well. Ill be testing it tomorrow :) |
|
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 |
|
The crash.log (in .adds/inkvt) would be a good start ;). |
|
I was pebcaking (running nickel.sh from inkvt) when you should just type exit |
|
it works that way if inkvt was run from the terminal. but not if inkvt wsa run from nickelmenu. here is the crash.log
|
|
and here is a crash.log from a clean exit. |
|
What are you actually doing in both cases? (and, yeah, don't run nickel.sh manually, ever). |
|
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 |
|
does anyone have a valid link to a pre-built version of this? Ideally one that works on a Kobo Clara 2E :) |
|
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). |
|
Thanks for the quick response. Unfortunately the action result says expired. "This artifact is expired and you can no longer download it." |
|
Yay, github. I'm not on my dev machine, so it'll have to way ;). |
|
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: But then on building, I get: Not sure how to go about debugging that one |
|
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 |
|
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). |
|
Touch doesn’t work on Clara 2E. Do you guys have any fixes? |
|
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 |
|
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 |
|
could you build it for me? I dont have a working build enviroment for kobo |
|
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 |
|
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. |
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 |
|
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). |
|
could you send me a binary? i dont have a build enviroment for kobo |
|
Here goes: Untar, run You'll also want to run (You may want to sigstop/sigcont nickel to prevent stray refreshes during that). |
|
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 |
|
(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). |
Oh. Don't do that. That script is woefully unmaintained. Run inkvt_armhf directly, and pass it |
|
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 |
|
fingertrace.txt |
touching OSK is still entirely unresponsive |
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) |
|
That's probably because there was a stupid typo in the input device selection. :D |
Did it ever detect a contact lift properly? |
|
No. It does not! |
|
It’s only “Down” |
Oh, yeah, makes sense given the input stream, we never get a 0-pressure event. |
|
There, contact lift detection ought to be fixed in both finger_trace & inkvt ;). |
|
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! |
|
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)). |
|
Is it possible to flush the evdev queue before sigconting nickel? |
|
Nope, it's a private state tied to each fd handle. |
|
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
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA3KZWRZTFYQ7F4QZOKBLLXIWBZ5ANCNFSM6AAAAAASL4KNQA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
i dont have the ability to compile this can someone post a compiled version of this app?
The text was updated successfully, but these errors were encountered: