(Help requested) Getting started with Qt on Kobo

[Namret]

Hello everyone!

I stumbled upon this corner of the internet the last few days and decided I want to dabble in developing a simple application for my Kobo, just for fun.

I am a software developer and regularly use C++ with Qt for desktop apps in my job, so seeing that Nickel is built on Qt was a nice surprise

To get started, I successfully extracted the toolchain from this docker image: https://github.com/geek1011/NickelTC and setup my Qt Creator Kit to use this toolchain.
I've also installed NickelMenu in order to launch my future app.

So far so good! I've got a binary compiled with the toolchain, let's run it!

I've created the following script based on the launch script from plato:

#! /bin/sh

WORKDIR=$(dirname "$0")
cd "$WORKDIR" || exit 1

# shellcheck disable=SC2046
export $(grep -sE '^(INTERFACE|WIFI_MODULE|DBUS_SESSION|NICKEL_HOME|LANG)=' /proc/"$(pidof nickel)"/environ)
sync
killall -TERM nickel hindenburg sickel fickel fmon > /dev/null 2>&1

echo $QT_PLUGIN_PATH >> info.log
echo "starting.." >> info.log
./kobo-test-app -qws >> info.log 2>> error.log
echo "stopping.." >> info.log

./nickel.sh &

And setup NickelMenu like this:

menu_item :main   :Start test app     :cmd_spawn      :/mnt/onboard/.adds/kobo-test-app/kobo-test-app.sh

At this point, I'm running into an issue I'm not sure how to fix: NickelMenu starts the script, but my app immediately quits and returns to Nickel. My error.log contains the following:

This application failed to start because it could not find or load the Qt platform plugin "xcb".

Reinstalling the application may fix this problem.
Aborted

Does anyone have any tips on how I could proceed? Is the xcb plugin necessary, is it available on the Kobo itself or should I ship it with the app? It seems like $QT_PLUGIN_PATH is not set by itself.

Any help would be highly appreciated

[geek1011]

Yeah. That issue.

To run Qt apps on the Kobo, a QPA is needed. Kobo provides one (libkobo.so), but it is closely tied to Nickel, and it isn't really possible to use it in the standard way.

In short, you'll need to either use an existing e-ink QPA (there are a few on GitHub), write your own, or hijack the running instance of Nickel the way NickelMenu does it.

[Namret]

Ah, that's unfortunate, I was hoping I wouldn't have to bother with the drawing itself, but I can see that was maybe a little optimistic.

Your response does make me wonder though: would it be possible to develop "plugins" for NickelMenu, since it already does the hard work of hooking into Nickel. NickelMenu could load this plugin (an .so) dynamically at runtime, hooking it into Nickel and thus a platform would be available for Qt to direct it's drawing calls to.

I have no idea if this would be possible at all, I might be able to put some time into researching this in the next couple of days.

It would make NickelMenu a new "platform" for Qt apps on the Kobo, which I think would be lovely! I love the way it integrates so cleanly into Nickel.

[geek1011]

Originally Posted by Namret

Your response does make me wonder though: would it be possible to develop "plugins" for NickelMenu, since it already does the hard work of hooking into Nickel. NickelMenu could load this plugin (an .so) dynamically at runtime, hooking it into Nickel and thus a platform would be available for Qt to direct it's drawing calls to.

See my comment at the end of this message.

I have no idea if this would be possible at all, I might be able to put some time into researching this in the next couple of days.[/QUOTE]

If you give me your GitHub username, I'll add you to the semi-private repo where we (me, @NiLuJe, @shermp, others) have been discussing this sort of thing.

It would make NickelMenu a new "platform" for Qt apps on the Kobo, which I think would be lovely! I love the way it integrates so cleanly into Nickel.

I've been trying to avoid feature-creep in NickelMenu, but I'd be happy to make this a separate thing. It should be as simple as copying the Makefile, src/qtplugin.h, src/failsafe.* (not strictly required, but it's a good idea), and src/dlhook.* (if you want to hook stuff), then making everything around that. If you want to take it further, you could make an init system based on NickelMenu which can run apps or load additional libs at startup.

[Namret]

Originally Posted by geek1011

If you give me your GitHub username, I'll add you to the semi-private repo where we (me, @NiLuJe, @shermp, others) have been discussing this sort of thing.

My GitHub username is @LanderN. I'd love to have a look at what you guys are doing, I can't promise I'll be much of a help though, seeing as I don't have the expertise you guys have with all this stuff. (Strictly speaking, I don't even own an eBook reader, it's my girlfriend's ) So I would totally understand if you'd rather not add me to the repo.

[geek1011]

Originally Posted by Namret

My GitHub username is @LanderN. I'd love to have a look at what you guys are doing, I can't promise I'll be much of a help though, seeing as I don't have the expertise you guys have with all this stuff. (Strictly speaking, I don't even own an eBook reader, it's my girlfriend's ) So I would totally understand if you'd rather not add me to the repo.

Added. Have a look at https://github.com/geek1011/kobo-plu...ments/issues/2, https://github.com/geek1011/kobo-plu...ments/issues/3, and https://github.com/geek1011/kobo-plu...commits/master.

[Namret]

Originally Posted by geek1011

Added. Have a look at https://github.com/geek1011/kobo-plu...ments/issues/2, https://github.com/geek1011/kobo-plu...ments/issues/3, and https://github.com/geek1011/kobo-plu...commits/master.

Thanks! I will take a look at it later, looks like you guys were way ahead of me on that idea

[OfficerAction]

Hey there is also the option to make a standalone Qt app. The advantage is you can use the latest version of Qt. I made a Kobo platfom plugin for that purpose. You can find it here: https://github.com/Rain92/qt5-kobo-platform-plugin. It does need a bit more tinkering since you have to compile Qt yourself, but I have instructions for that in my other repo.

[NiLuJe]

IIRC, the QPA API has only seen mild updates between 5.2 and 5.14, so it could be a good candidate .

EDIT: Mildly curious about input, though. How do you deal with the device-specific translation quirks?

[OfficerAction]

Originally Posted by NiLuJe

Mildly curious about input, though. How do you deal with the device-specific translation quirks?

In short, I don't. Maybe you can elaborate on this.
I let Qt's evdevtouch manager take care of touch inupts. The rotation has to be manually specified.
For me it works great, but I only have a KA1 for testing.

[NiLuJe]

@OfficerAction: Yeah, I saw that a rotation could be fed, I just hadn't seen a frontend bit to confirm what you were feeding it, exactly .

(I'm *hoping* Qt can actually deal with the various protocol quirks sanely on its own (at least for basic touch events, multi touch gestures might be a tougher ask), but I wouldn't necessarily bet my life on it ^^. IIRC, the Aura One is using roughly Multi Touch B w/o ABS_MT_SLOT and w/ possibly broken timestamps (since boot instead of epoch, AFAIR)).

Which leads to my next question: do you deal with rotation in your app, and if so, how? (hardware fb rotations, or a rotated sw viewport?).

[OfficerAction]

Originally Posted by NiLuJe

(I'm *hoping* Qt can actually deal with the various protocol quirks sanely on its own (at least for basic touch events, multi touch gestures might be a tougher ask), but I wouldn't necessarily bet my life on it ^^. IIRC, the Aura One is using roughly Multi Touch B w/o ABS_MT_SLOT and w/ possibly broken timestamps (since boot instead of epoch, AFAIR)).

Which leads to my next question: do you deal with rotation in your app, and if so, how? (hardware fb rotations, or a rotated sw viewport?).

I have not tried multitouch. In theory it should have support for all of that but unfortunatly in practice there are issues. Even for swipe gestures I had to reimplement some parts. Don't pin me down on that but I think the problem was that the touch inputs got mapped to mouseclick events and the builtin guesture recognizer didn't like that.

For the rotation I just use FB rotation at startup. SW rotation in Qt is also possible but it just seems cleaner that way.
Actually for that and the whole Nickel exit and restart sequece I used parts of the Koreader scripts, they helped out a lot