FBInk: A small tool/library to print crap on your screen!

[NiMa]

@Acorn

Or; install NiLuJe's stuff
and open up two SSH shells
one for command input
and the other for Vim/Nano

*shell 1*
ESC+:w or ^O

*shell 2*
./some_script.sh

voilà! It's done!

[Acorn]

Is there a better way to draw simple filled rectangles than using images? I saw that PoP posted an example doing that but I don't see any source code.

[NiLuJe]

fbink_cls/fbink_grid_clear (with a background color set).

(And there was a script attached to that post, @PoP used the CLI frontend's -k, --cls flag, which calls fbink_cls).

[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..

# 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?

Might be a total red herring, I'm not sure if it would necessarily understand the kobo's touch screen, not fully clear on how nix works with input devices / drivers etc.

Cheers!

[NiMa]

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..

# 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.

[Acorn]

Interesting! Might have a play with that..

[NiLuJe]

@Acorn: Yeah, the current approach is to kill all the things and restart Nickel on exit (c.f., KOReader).

And, no, unfortunately, libinput is not usable on the Kobo, for... reasons. (Mainly, it requires an up to date kernel & userland (mainly, udev), which, much to my dismay, is... *really* not a thing on Kobo ;p).

libevdev does work, on the other hand, but it's much lower level than libinput. (I use it in KoboUSBMS, although not for touch input, because touch input is hell on Kobo. And, also, I don't need it ^^).
[Given the mess you'll have to parse and make sense of, it's not necessarily a bad thing, though].

tslib, a much older project, can also be coerced into behaving, but it's slightly old-school, and is potentially less amenable (without dirty, dirty hackery at the C level) to the kind of trickery needed to translate the mess that is generated by the various Kobo input devices to something it understands than libinput might have been .

[Acorn]

Interesting insights, thanks! Where can I find libevdev? Had a rummage through KOReader, but it doesn't seem to be there. Is there anywhere I can find it compiled for Kobo?

Aha, also just saw that KFMon automatically restarts Nickel on exit.. that explains things.

[NiLuJe]

Err, libevdev is just... fdo's libevdev?

I was going to say I'm pretty sure that anything I build that depends on it (e.g., evemu/evtest) is linking to it statically, but, hey, that's no longer true, so it is in fact in KoboStuff.

And, no, it's not KFMon that restarts Nickel, it's KOReader (c.f., what I linked to in my previous answer, specifically the koreader.sh -> nickel.sh interaction).

[Acorn]

Oh right! I was misreading the comments in koreader.sh, makes total sense now.

Aha, I've found it in KoboStuff! For some reason macos file search wasn't finding it.. oops.

[sherman]

Another trick you can do (if you don't need access to /mnt/onboard) to do stuff without nickel clobbering input/framebuffer is to fake a USBMS session. Once on the "connected" screen, you can do almost anything without worrying too much about Nickel.

[Acorn]

Bingo!

Input device name: cyttsp5_mt

Event: time 150848.651488, type 01 EV_KEY code 145 BTN_TOOL_FINGER      value    1
Event: time 150848.651488, type 01 EV_KEY code 14a BTN_TOUCH            value    1
Event: time 150848.651488, type 03 EV_ABS code 039 ABS_MT_TRACKING_ID   value    0
Event: time 150848.651488, type 03 EV_ABS code 03b ABS_MT_DISTANCE      value    0
Event: time 150848.651488, type 03 EV_ABS code 035 ABS_MT_POSITION_X    value  222
Event: time 150848.651488, type 03 EV_ABS code 036 ABS_MT_POSITION_Y    value  172
Event: time 150848.651488, type 03 EV_ABS code 03a ABS_MT_PRESSURE      value   21

[Acorn]

Originally Posted by sherman

Another trick you can do (if you don't need access to /mnt/onboard) to do stuff without nickel clobbering input/framebuffer is to fake a USBMS session. Once on the "connected" screen, you can do almost anything without worrying too much about Nickel.

Is there somewhere I could see what that would look like?

[sherman]

Originally Posted by Acorn

Is there somewhere I could see what that would look like?

I used to do that with Kobo-UNCaGED, before v0.5.0. The startup shell scripts show what I did.

EDIT: More specifically, look here.

[Acorn]

Originally Posted by sherman

I used to do that with Kobo-UNCaGED, before v0.5.0. The startup shell scripts show what I did.

EDIT: More specifically, look here.

That's super handy, thank you!