kwin & hwcomposer packaging problems

Currently, kwin is built in Alpine side, and it's of course built without support for hwcomposer backend. And this backend is needed to run PlaMo in libhybris adaptations. To build kwin with hwcomposer backend, libhybris(-dev) is needed, and android-headers, in different variations for different android versions and CAF modifications. That's why hwcomposer backend needs to be built in several variations, producing the packages that are owning the same file and cannot be coinstalled. Ideally the backend should be built separately because of that. Those packages may be not useful for Alpine Linux at all (or maybe it is?). Anyway, I see 3 ways of solving this:

1. Long way. Upstream libhybris and android-headers to Alpine and modify kwin's APKBUILD to build hwc backend in a loop for different variations of Android (will that hacky build script be ever accepted?) I don't think that's right, because libhybris is unstable, has some bugs and is very experimental in its current state. We may have to modify it several times, currently it has to be rebuilt with custom patch to fix eglplatform linking issue, this is a whole story for another bug.

2. Continue to use kwin from Alpine as is. In our repos build only hwcomposer backend, separately from kwin. There is a problem here, original kwin does not recognize plugins that were not built with it. Its "plugin system" is not really a plugin system, but a hard-coded at compile time selection of available backends. There is a fix from me for that issue: https://phabricator.kde.org/D22418 . It will allow us to use separate build of backend, and also fix automatic backend selction between mesa-drm and hwcomposer. I think that's the best way to proceed, but upstream is resistant to any changes, even the very logical and sane ones.

3. We can fork kwin to our pmOS repos and build it the way whatever we want with any custom patches and backends. If honored kwin devs reject D22418 we can go this way.

I currently think that 2) is a correct way to do, but I may need your help to persuade KDE upstream to support plasma mobile. @ollieparanoid or @PureTryOut if you agree with me maybe you could come out and intercede for me that this the right way to do from the packaging point of view. Or maybe @bshah can say something?

Or, on the other hand, you can persuade me that I'm wrong and we should go for option 3) or some other way.

Anyway, I'd like to gather opinions.

P.S. I have a proof of concept that option 2 works:

• kwin APKBUILD with D22418 patch (ignore debug patch, it's only there for debugging)
• hwcomposer backend built separately

And this all is working:

• short video demo, youtube
• klte_plamo_homescreen
• klte_plamo_top_panel_wifi
• klte_plamo_index_fm