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

[NiLuJe]

@baskerville: AFAICT, the *framebuffer* rotates completely sanely, for once. (i.e., it boots UR, pickel stays UR, nickel stays UR, and ioctls cycle properly from UR to CCW in the expected manner, without fun surprises). I would assume it means that @ CW, the device is actually physically rotated CW too .

(From what I gathered from the logs with fbdepth's attempts to correct the rota when it was mistakenly applying Forma quirks).

Touch input, on the other hand, your guess is a as good as mine without a device on hand .
Apparently, the relative shift is still the same as on a Forma, except the Forma's "Portrait" state happened to be CCW and not UR.

[NiLuJe]

Released v1.20.1!

Minor tweaks here & there, especially as far as the Libra is concerned.

[NiLuJe]

Released v1.20.2!

A few minor fixes, and the new daemon mode for the CLI, to make some specific workflows slightly more API-like in shell scripts .

[NiLuJe]

Released v1.20.3!

Boring maintenance release with a few minor fixes .

[NiLuJe]

Released v1.21.0!

A major release, with a bunch of fixes and a quite a few new features, see the release notes for details .

To name a few of those things:

* A bunch of subtle rendering fixes & performance improvements when running on 16bpp fbs.
* Padding handling in the OT/TTF codepath, making it easier to print overlapping text at the same coordinates without having to worry about overlap.
* Being able to clear a specific region of the screen (A.K.A.: let's paint filled rectangles freely).
* You're now able to try out the legacy dithering features available on Mk. 6 devices.
* The doom demo featured a while back now ships with the standalone packages. Using similar settings as before, I can push a solid 55fps out of my Forma .

There are a couple of breaking changes, both as far as the CLI & API are concerned, so, do read the relevant sections of the release notes .

Also, if you happen to own a reMarkable tablet, it is now supported, thanks to @tcrs!

[NiLuJe]

Released v1.22.0!

A few fixes here and there, a few minor performance improvements in both font rendering codepaths, and a few new API calls geared at making life easier for grid-layout aficionados .

[burphl]

Quite an awesome library you've built there!

I've currently got ssh running on my Kobo Touch and installed your library. I'm planning to use my Kobo as a display for my upcoming shifts at my local red cross department

[NiLuJe]

As mentioned in the README, feel free to ping me if you've got any question .

[taos]

From time to time I'm a little impatient (especially if there's a nice new feature announced in fbink I'd really like to have - such as the padding for true type fonts a couple of months ago - thank you very much for this), so I sometimes scan the trac site for new versions if there's not yet an official release.

So, until yesterday, I used fbink@16051 on my Kobo Glo HD without any problems. After the update to fbink@17028, two of my shell scripts stopped working. A little research showed the same problem for fbink@16952.

In one case the previous screen is not completely cleared before the script freezes/crashes. I'm left with faint parallel lines. The relevant part (for displaying stuff with fbink) starts with:

# Show animation
$fbink -k
sleep 2
i=0
for FILE in $ICONFOLDER/$ICONNAME*.png ; do
    i=$(($i+1))
done
j=1
while [ $j -le $i ] ; do
    $fbink -g file=$ICONFOLDER/$ICONNAME$j.png,halign=CENTER,valign=TOP,w=0,h=$iconheight,y=$icontop -h -W A2 #-c
    sleep 0.1
    j=$(($j+1))
done
sleep 5

Do you have any ideas what I'm doing wrong? Or why it stopped working?

Another script now stops during/after(?) the display of the icon file:

Spoiler:

# Extract information line for line from download queue:
if [[ "$QUEUEFILE" ]] ; then

  $fbink -mMc -t regular=$font_directory/$font-Regular.otf,$viewport,padding=HORIZONTAL "Download queue found in $QUEUEFILE."
  sleep 3
  $fbink -k
  while read LINE ; do
    $fbink -g file=$ICONFILE,halign=CENTER,valign=TOP,w=0,h=$iconheight,y=$icontop
    
    if [ $(echo $LINE | cut -c 1)  != '#' ] ; then
      LIST=$(echo "$LINE" | sed 's/    /\n/g')
      
.
.
.

      fbink_info=$($fbink -m -t regular=$font_directory/$font-Regular.otf,top=$top,left=$left,right=$right,padding=HORIZONTAL "$title.epub 
downloaded to 
$target_directory
 " -l)
      fbink_infolist=$(echo "$fbink_info" | sed 's/;/\n/g')
      top=$(echo -e "$fbink_infolist" | grep "next_top" | sed -r 's/^next_top=(.*)$/\1/g')
      sleep 5

    fi
  done < "$QUEUEFILE"
else
  $fbink -mMc -t regular=$font_directory/$font-Regular.otf,$viewport,padding=HORIZONTAL "No download queue found."
  sleep 5
fi

It's probably obvious what's going wrong but I can't see it.

[NiLuJe]

@taos: I don't see anything obviously wrong at a glance, but it's pretty hard to say what might happen given that pretty much everything is being fed dynamic values .

On that note:

* I'm all for braces, braces everywhere! This should ensure nothing "bleeds" through a variable. shellcheck should warn about this when it's a real potential issue. I personally pretty much always use braces to keep it simple. And then double-quote it unless it doesn't make sense to.

* Put a set -xe on top of the script, and watch it crash and burn on the first non-zero return code (and/or at least you'll have the actual expanded command being run when something blows up).
(I'd recommend pairing that w/ set -o pipefail, which *should* be supported on Kobo's bb ash, IIRC).

* In the second script, you probably use to ought the -l, --linecount flag instead of trying to parse the full output yourself. It'll be ready to eval straight away, with only the requested information, no need for half-assed attempts at validation.

EDIT: Which you are, I missed it because of the wonky linefeeds ;p. So you can just eval the output, it's always going to be a single eval-friendly line.

EDIT²: Speaking of, if you need the explicit LFs, passing something like "$(echo -e 'Blah\nBlah\nBlah')" works, too .

* Check FBInk's output, my best bet would be on wonky input tripping getopt, there were some various cleanups on that front somewhat recently.

EDIT: r16051 was v1.16.0-5-gaac4b3e, there have been *numerous* getopt tweaks since (especially around 1.21, IIRC), and the output on getopt parsing errors has been greatly enhanced.

* In the first script, nothing's doing a clear screen except the very first invocation, so, not quite sure what you're describing?

[NiLuJe]

@taos: Another comment about quoting suboptions and/or suboption limitations as far as image filenames are concerned: here .

[taos]

@niluje, thank you very much for this vast amount of information. It will probably take me a number of days to work through all suggestions.

Concerning the clear screen in the first script - it's actually the first line which doesn't seem to work. I start the script manually from the KSM user script menu, so I still see part of the script files list from the KSM sub-menu kind of "shining through" (but as horizontal lines, not ghosting) which should be completely cleared before the "animation" starts.

EDIT:
Firmware is at 4.20.14622.
I should already have a much more recent version of fbgrab in one of the many subfolders in .adds (whenever I search for a new version of fbink I also always get the latest fbgrab and strace - you never know ... )

[NiLuJe]

@taos:

Ah, good point, I forgot to ask you in which context you were running this, and on which FW version.

KSM means it's running in shitty rotated 16bpp mode, so, higher potential for stuff to go incredibly wrong .

In the first case, I wouldn't mind an actual capture of the screen right after the broken clear. KSM bundles fbgrab, but it's probably old/broken, see here for up-to-date standalone binaries .

(I say standalone because the in-repo one depends on a full tree (well, on zlib & libpng, but, still ;p).

[NiLuJe]

And, yes, indeed, a (fullscreen) clear is currently subtly broken in this context. >_<".

EDIT: fixed, thanks!

(That means no need for a screen grab ).

[taos]

Originally Posted by NiLuJe

@taos:
(I say standalone because the in-repo one depends on a full tree (well, on zlib & libpng, but, still ;p).

The Mark 6 Kobo firmware includes both in /lib, so I've never even noticed...

Thanks for the fix, I'm looking forward to try it out.