Quote:
Originally Posted by Acorn
Thanks that's perfect!
If I'm going the admittedly hacky route of stealing input and drawing my app over the top of everything, am I going to have problems with nickel trying to draw things over the top of me? If so is there a reasonable way to prevent this? Also, is there a way to get everything back onto the screen when my application is closed?
Is it a matter of stopping nickel and then starting it again when the app is closed?
I see kobo dashboard does this..
Code:
# Flush the disks: might help avoid damaging nickel's DB...
sync
# Stop kobo software because it's running
killall nickel hindenburg sickel fickel fmon > /dev/null 2>&1
Don't see anything that would then try and start nickel again.. I guess the user is just expected to power cycle the device.. that's an easy solution I suppose
Also, I've been having a bit of a play with using touch input.. and I was wondering if using libinput would be the proper way to do it, rather than the low level hacking that Kobo-Input-Python does.. looks like it would make it quite easy to have plug and play usb input devices if you were so inclined too..
Would libinput be hard to build for the kobo? Maybe it could be included in the almighty Stuff bundle?
Cheers! |
Check my development environment guide :
https://www.mobileread.com/forums/sh...d.php?t=336175
You could bind-mount /dev and be able to interact with input even if you're in a chroot.
Also, you can install gcc/g++/clang/meson/ninja/etc. flawlessly with the built-in package manager.