Defender app update (harbour-defender) - my very own ‘Sailfish Devember’

I’ve been playing around with this a bit, and not really made much progress. I’ve done a couple of different things that cause a couple of different failure modes.

First one, already addressed above, is if I whitelist /vendor/lib/hw/mt6858/*, Defender exits with the following error:

[D] unknown:0 - Using Wayland-EGL
couldn't find an OpenGL ES implementation, make sure one of persist.graphics.egl, ro.hardware.egl and ro.board.platform is set

The only previous reference to this error in the forum seems unrelated enough not to be useful here, although I did play around with setting QT_QPA_PLATFORM=hwcomposer, which gave me:

library "libged_kpi.so" not found
Can't create AidlComposerClient, fallback to HIDL

I imagine this was a dead end, and probably unrelated to the solution to this issue.

Second one, which is pretty curious to me, is when I was just poking around kind of randomly at this, if instead of whitelisting /vendor/lib/hw/mt6858/*, I just copy /vendor/lib64/hw/mt6858/mapper.mediatek.so to /vendor/lib64, I end up with this very different error message:

[W] unknown:0 - QObject::moveToThread: Current thread (0x5dadc180c0) is not the object's thread (0x5dad1c7800).
Cannot move to target thread (0x5dad6e9eb0)

[W] unknown:0 - QObject::moveToThread: Current thread (0x5dadc180c0) is not the object's thread (0x5dad1c7800).
Cannot move to target thread (0x5dad6e9eb0)

[F] unknown:0 - Cannot make QOpenGLContext current in a different thread

I have no idea why forcing it to load the mediatek library from a different location would cause such a different output, but maybe this means something to someone. :slight_smile:

I am presently using the most recent version of Defender from Chum testing (0.9.3), but I get all the same behaviour from the release version.

1 Like