Missing fbink.h

[rien333]

make fails for me with the following error when I try to cross-compile:

refresh.c:12:10: fatal error: fbink.h: No such file or directory
   12 | #include "fbink.h"
      |          ^~~~~~~~~
compilation terminated.
make: *** [Makefile:8: refresh.o] Error 1

Do I have to manually include fbink.h, by downloading it an placing it somewhere? Should I globally install it on my linux system somewhere (so not on my kobo?) I've never cross-compiled before, so I'm sorry for my lack of knowledge in advance.

Additionally, the Makefile specifies CC = arm-linux-gnueabihf-cc, whereas basically all inter resources mention arm-linux-gnueabihf-gcc (so a -gcc suffix). I have the latter, but not the former. This is unimportant/an oversight right?

[rien333]

I guess I have to download the fbink repo and compile it, right? I compiled it succesfully, but how do I tell fbpad-eink where to find it?

[NiLuJe]

I can't speak for the Makefile as I haven't looked at it (although cc is usually a symlink to gcc or clang, so the point is probably moot), but see the latest commit for an explanation of how FBInk is used (i.e., it's not, really, it's just hacked in via c/p for a quick test, there's a good chance it won't behave properly on devices that don't match what @kisonecat used, as was mentioned in the MR thread ;)).

TL;DR: You just need to pull the header in here. Ideally, from whatever version @kisonecat originally used, or shit may go boom (although, that bit of the API should be stable, so, master'll probably do).

[NiLuJe]

Otherwise, see this post for a quick overview of how to "do it right" (i.e., use FBInk as a library).

Note that I don't have any particular interest (and/or time) into doing this myself, and I'd probably fall into a rabbit hole of tweaks here and there for performance reasons... But I'm happy to give pointers to any motivated individual(s) ;).

[rien333]

All right, I might put in the effort of using fbink more correctly if I find the time, and no other good Kobo terminal/way to achieve what I want.

TL;DR: You just need to pull the header in here. Ideally, from whatever version @kisonecat originally used, or shit may go boom (although, that bit of the API should be stable, so, master'll probably do).

I can't figure out which header version @kisonecat was using. The error I'm getting is related to how fbink_refresh is defined in refresh.h:

int
fbink_refresh(int                fbfd,
                uint32_t           region_top,
                uint32_t           region_left,
                uint32_t           region_width,
                uint32_t           region_height,
                uint8_t            dithering_mode);

However, in every version of the fbink header from the official repo I tried, this function has an additional argument. Due to this mismatch the build keeps failing.

[NiLuJe]

Ah.

AFAIR, that was never a valid signature for fbink_refresh, ever. So, I'm guessing it was modified somewhat to make this build.

One close match would possibly be v1.13.0. If you pull that in, and remove the fbink_refresh declaration from the header, it builds (the header is basically only needed for a few constants at this point). Whether that behaves as intended, or at all, is another matter entirely.

[rien333]

@kisonecat As somewhat expected, I can't get fbpad to work. It runs without error when I run it under ssh/dropbear, and I can I even to get it to do a printf() from pollterms() everytime I press a key (hence triggering a refresh), but nothing is actually ever shown on the Kobo screen. Aside from my own printf's, no ouput is logged to the ssh session I run fbpad from, either.

I'm using the courr.tf files provided by fbpad's author. I'm trying this project on a Clara HD, a mark 7 device. Therefore, I also tried changing int isKoboMk7 = 0; in refresh.c to 1, but to no avail. As the fbink header, I'm using the v1.13.0, edited to ensure there is no argument mismatch (see discussion above).

How do you launch fbpad, @kisonecat ? I tried setting up a kfmon action, but that also doesn't seem to do a whole lot.

As an an aside, I had to change the the fbval_t typedef to:

/* fbval_t should match framebuffer depth */
typedef unsigned int fbval_t;

Apparently, the fbdepth on the Clara HD is 32bits.

[NiLuJe]

Yeah, Nickel switched to 32bpp in FW 4.something.

As a cherry on the cake, part of my rabbit hole descent would involve switching to 8bpp and optimizing that codepath, like we do in KOReader. But that's besides the point for now ;).

I'd strace fbpad to see what's actually happening, because the Clara should still support the legacy refresh ioctls (meaning the Mk7 codepath isn't mandatory). And if one were to actually fail, you'd see something on stderr...

[rien333]

Hey, it seems to work! The strace itself looks pretty disconcerning, but that could also be because the strace binary is not completely compatible with my system (I got the one from your kobo-stuff package, but so far most utilities won't launch)

I think part of the trick was to wait a little, and then hit one of fbpads keyboard shortcuts (e.g. alt+e to launch an editor). A little unfortunate that there is no onscreen keyboard though. @kisonecat Is the idea to only use this terminal emulator over the network? Or should/could it be controlled by some usb device, by hooking e.g. a keyboard onto the kobo?

[NiLuJe]

Hey, it seems to work! The strace itself looks pretty disconcerning, but that could also be because the strace binary is not completely compatible with my system (I got the one from your kobo-stuff package, but so far most utilities won't launch)

That's... not normal. Unless you pulled 'em off manually. (The directory structure and dependencies have to be there, and in the right place, as mostly everything is dynamically linked and setup with specific rpaths).