Building with system libraries

[jdek]

I've set up a buildroot for my ereader, and I am already building many of the libraries used by koreader. What would be the best way to direct the build to allow searching for system libraries instead of vendoring?

[NiLuJe]

Absolutely none ;).

This was vaguely touched upon a few years ago (I think?), and the conclusion was (and still is), that it's not how the build-system is designed, and as it's already a massive pile of kludges, we'd be extremely wary of changing that for a feature used by 0.001% of the target audience ;).

[NiLuJe]

One less-intrusive option would be to version-match what you can, and fudge the rpaths post-install.

But, here be dragons, because API/ABI mismatches for stuff that's not the right version (or stuff we patch to add needed APIs).

[jdek]

Hmm ok. I might try write a custom makefile for it then, should be a lot simpler since no dependencies. Also there seems to be a lot of hardcoded stuff relating to their default OS (no support for running a lot of these devices with a different base).

Unrelated: I've been trying to get Qt5 framebuffer working on the Kobo but I get no output on the fb but no errors. Fbink works fine. Where would be a good place to get some second eyes on this? I'm completely stumped.

[NiLuJe]

Also there seems to be a lot of hardcoded stuff relating to their default OS (no support for running a lot of these devices with a different base).

Yep, which is also another reason against doing that sort of things ;). But, at least on Kobo, see https://github.com/lgeek/okreader for previous attempts on older devices & I think @BloodRagg had also tried something like that on more recent hardware.

Unrelated: I've been trying to get Qt5 framebuffer working on the Kobo but I get no output on the fb but no errors. Fbink works fine. Where would be a good place to get some second eyes on this? I'm completely stumped.

That's rather vague without knowing exactly what you've done ;).

[NiLuJe]

For example, while we don't happen to support the default Sony OS layer, what was done for PRSTUX was to basically handle it as a completely separate platform.

(I'm not saying this would be the right approach here. I think it'd be easier to just writer a simple wrapper script that emulates/exports whatever may be needed and be done with it ;)).

[jdek]

I think it'd be easier to just writer a simple wrapper script that emulates/exports whatever may be needed and be done with it

Maybe, the koreader (bundled) doesn't seem to run for me anyway, it fails to mmap() the framebuffer. I'm still looking into debugging that.

That's rather vague without knowing exactly what you've done ;).

I'm using https://github.com/jdek/ereader-buildroot to build a base OS with qt5 etc. Then I'm just running the following super simple qt application with -platform fblinux on /dev/fb0.

#include <QtWidgets/QApplication>
#include <QtWidgets/QPushButton>
int main(int argc, char **argv) {
  QApplication a(argc, argv);
  QPushButton hello("Hello world!", 0);
  hello.resize(100, 30);
  hello.show();
  return a.exec();
}

[NiLuJe]

Maybe, the koreader (bundled) doesn't seem to run for me anyway, it fails to mmap() the framebuffer. I'm still looking into debugging that.

o_O. On which actual hardware is that? And with what kind of software stack (mainly libc/kernel here)?

I'm using https://github.com/jdek/ereader-buildroot to build a base OS with qt5 etc. Then I'm just running the following super simple qt application with -platform fblinux on /dev/fb0.

#include <QtWidgets/QApplication>
#include <QtWidgets/QPushButton>
int main(int argc, char **argv) {
  QApplication a(argc, argv);
  QPushButton hello("Hello world!", 0);
  hello.resize(100, 30);
  hello.show();
  return a.exec();
}

I'll check, but my money would be on the fact that the fblinux platform does just what it says on the tin.

It doesn't handle the specifics of an MXCFB at all (which means, Qt might be happily and properly painting to the fb, but nothing's actually asking the EPDC to use that to refresh the screen ;)).

(And even then, depending on how the device was brought up, we might disagree on what should be considered "properly", as NTX hardware boots in all kinds of fucked up state, especially older ones ^^).

[NiLuJe]

For slightly related details, see how sergey had to come up with custom platforms & plugins for basically everything, from input, to screen, to brightness.

(That's Qt4, though).

TL;DR: You can't use vanilla Qt on eInk and expect it to "just work". That's doubly true on Kobo/NTX.

[pazos]

yeah, for running qt4 on kobos it is better to build qt first. You need to add a new qws target, like sergey and then build. (ie: drivers are needed for the keypad and the framebuffer).

Here is a patch that compiles qt4 for a related board (cervantes bq4) qt_4.8.7-cervantes.patch.zip.

The only change you need to do for kobos is using hardfloat.

Then you can create a shell script as a helper to launch "standalone" graphical applications

#!/bin/sh

# launch standalone qt applications from cli.
PROGRAM_NAME="[qt-launch]"

export QWS_DISPLAY=einkfb
export QWS_MOUSE_PROTO=tslib:/dev/input/event1
export QWS_KEYBOARD=eb600keypad:/dev/input/event0
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event1
export TSLIB_CALIBFILE=/usr/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/lib/arm-linux-gnueabi/ts0/
export POINTERCAL_FILE=/usr/etc/pointercal
export QT_QWS_FONTDIR=/usr/lib/fonts

# run application in qws mode
echo "${PROGRAM_NAME}: opening ${1}"
"$@" -qws
echo "${PROGRAM_NAME}: ${1} returned ${?}"

About Qt5, I didn't try. I'm not really sure if qt5 is an improvement over qt4 for embedded devices (outside the qtwebkit - qtwebview mess). Of course C11 and lambdas and things, but you can code that elsewhere and have fun with retrocomputing with qt4.8 and good-old drivers :smile:

[pazos]

Also @jdek can use https://github.com/koreader/koxtoolchain generated toolchains for known targets. These modern toolchains are enough to build qt4/5 and most of the packages of buildroot (including the bootloader and the kernel in the specific case of kobos/cervamtes)

[jdek]

@pazos Thanks for your reply.

yeah, for running qt4 on kobos it is better to build qt first.

I have been building it but didn't even realise that you couldn't just write to the framebuffer and it would 'just work'. Also, I've been using Qt5 but I figured it out and wrote my own QPA platform plugin for it (needs a bit of refinement). Touch input works out of the box with libinput(?) instead of tslib on Qt5. I have CoolReader (from upstream master) running as well (though I need to change the UI a bit for eink devices as it's optimised for use with a mouse).

Also can use https://github.com/koreader/koxtoolchain generated toolchains for known targets.

My buildroot already builds a compiler, entire toolchain, dependencies, libraries, kernel (and even CoolReader itself).

[Frenzie]

I'll close this now.