Closed llandsmeer closed 4 years ago
Today is apparently not my day as far as posix sh is concerned... ^^ (context).
In any case, that's definitely something worth fixing, since I don't think anything else is really GNU-ish in there ;).
IIRC, the subshell might be unnecessary though, as each line in a Make recipe is already a subshell ;).
Otherwise I'd prefer a cd -
on the tail end, just for clarity (unless that's also a GNU extension ;p).
Definitely also fine with a PR for C++ compat, if it's behind a __cplusplus
guard, it's essentially harmless ;).
As for KFMon, I'm perfectly fine with discussions taking place in an issue. Or you can ping me on KOReader's gitter, or via PM on MobileRead ;).
Sidebar: you probably don't actually want to use the "kobo" target, since it does a bunch of packaging steps no-one but me probably cares about ;).
Sorry for the late reply, some things came up. Posix compliance isn't that important for me, but my make
apparently uses posix sh
? And yes after fixing that I quickly found out that the kobo
target wasn't the right one :smile:
Okay since its a small question, ill just ask it here then. What does a application have to do, after being started by KFMon, to stop Nickel from responding to inputs in the background? Grabbing evdev devices seems to work somewhat, but I think I should just killall nickel
? Or is there a nicer way?
AFAIK, there's unfortunately not much that can be done short of killing nickel and its friends.
Which gets slightly problematic if you want to restart it without a reboot, because it's very finicky about how the environment looks.
In practice, that implies inheriting a few of its env before killing it: https://github.com/koreader/koreader/blob/95d18fe8d9cc5f21763eaa76bd7960d0a746a309/platform/kobo/koreader.sh#L94-L102
And then being somewhat careful about how you go about restarting it: https://github.com/koreader/koreader/blob/master/platform/kobo/nickel.sh
IIRC, if you simply SIGSTOP/SIGCONT it, the input events will still accumulate and flood nickel on CONT. Been a while since I double-checked that, though, and I may be confusing what exactly happens here with what happens when you do that to the Kindle WM ^^.
So, if it's a short-lived app, it might be worth a try.
On a somewhat related note, If you're concerned with input events, nickel grabs event0 exclusively by default (that's physical buttons and synthetic gyro events). Touch input isn't grabbed, on the other hand ;). (If need be, there's a kobopatch patch to prevent the EVIOCBGRAB on event0).
Woah thats a bit more involved than hoped :) Thanks so much for the thorough explanation! :smile:
I think I'll go with stealing the shell scripts then. They look like they're full of hard learned lessons :) Or maybe SIGSTOP/SIGCONT + ptrace into Nickel to flush the input streams, if I ever figure out how to do that last step
Note that you need to be careful when ptracing nickel, as if you do it at the wrong time (I haven't yet figured out exactly when), you'll cause nickel to segfault. Doing a PTRACE_SEIZE seems to prevent this most of the time, though.
@geek1011: Oh. That would explain why my one "let's try ltrace for fun" experiment lead to an insta-segfault ^^. :D.
Hi, another small issue :)
Executing
make kobo
gave me:Quick fix with:
Not sure if that is something you want fixed. Shall I just sent a pull request next time (which you can ignore if you don't want the fix)?
Furthermore, I came across some small issues when trying to use fbink.h from C++, which can be fixed with a
extern "C"
and#define restrict __restrict__
. But maybe C++ support is not a design goal.Also, since you seem to be the author of KFMon and I have some questions about its use, whats the best way to contact you - if you're willing to answer some questions? :)
Kind regards, Lennart