Excellent! If something in kernel config is missing, I expect that you could use Xperia 10 as a base to check the settings or for Xperia XZ2 used by me at https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig
Rinigus On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg <a...@piggz.co.uk> wrote: > Ill build it on mido and try it out, thanks! > > On Fri, 3 Jan 2020 at 22:45, rinigus <rinigus....@gmail.com> wrote: > >> Hi, >> >> I have submitted PR to libhybris allowing to use Flatpak on hybris >> devices with the same version serving its main purpose and inside Flatpak >> sandbox: https://github.com/libhybris/libhybris/pull/433. >> >> As soon as your device has such libhybris, you could >> >> - use https://build.merproject.org/project/show/home:rinigus:flatpak to >> install flatpak, flatpak-runner >> - run flatpak-extension-hybris to generate Flatpah hybris extension at >> user nemo's home (run as nemo) >> - install flatpak apps, see instructions at Flathub on how to do it >> - run them using flatpak-runner >> >> Many things don't work, but would be faster to get it fixed together with >> other devs. >> >> Cheers. >> >> Rinigus >> >> On Fri, Jan 3, 2020 at 12:18 AM rinigus <rinigus....@gmail.com> wrote: >> >>> Hi, >>> >>> just finished the first version of a wrapper for 'flatpak run' command >>> as well, available at https://github.com/rinigus/flatpak-runner . Its >>> based on qxcompositor and it opens new Wayland server before running an >>> application, all explained in README. Device rotation is supported and >>> should be followed. >>> >>> So, as it is: >>> >>> - we have to resolve libhybris linker issue to make it possible to >>> distribute. >>> - keyboard is not supported currently. At present, app has to have >>> qtvirtualkeyboard support added as in >>> https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel >>> . >>> - only single-window apps are working well, such as QML developed for >>> mobile >>> - no sound so far >>> - probably many other things are missing, haven't bumped into them. >>> >>> Essentially, we will have access to the latest Qt, but would have to >>> write apps for this use. Fortunately, it all goes along SFOS programming >>> and should be simple to convert later to Silica, when/if it catches up with >>> Qt versions. >>> >>> I guess we can get better integration after it will be simple to install >>> on other devices and start using it by others. >>> >>> Cheers, >>> >>> Rinigus >>> >>> On Wed, Jan 1, 2020 at 5:25 PM rinigus <rinigus....@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> wait a bit, I may have a way to simplify setup. Few days ago, after >>>> discussion on IRC, I found a way around disappearance of the window when >>>> wrapped into qxcomposer. So, that blocker is over now. Which means that we >>>> will be able to craft apps using the latest Qt available in Flatpaks. >>>> >>>> Currently, I am looking into >>>> >>>> - how we can use regular hybris >>>> - making a wrapper similar to qxcomposer for Flatpaks. >>>> >>>> Shouldn't take too long for an update on status. >>>> >>>> Cheers, >>>> >>>> Rinigus >>>> >>>> On Wed, Jan 1, 2020 at 4:55 PM <szo...@gmail.com> wrote: >>>> >>>>> Could you elaborate on: >>>>> > libhybris compiled with specification of default >>>>> hybris-ld-library-path, >>>>> > content of libexec/droid-hybris added with GL extension. >>>>> Is that libhybris build available (and safe to run on main device, or >>>>> should I dig out my j1)? >>>>> Also not sure what added with GL extension means? Having a browser >>>>> that uses up to date webengine would be awesome. >>>>> >>>>> Thanks and happy new year! >>>>> szopin >>>>> >>>>> On Sunday, 29 December 2019, rinigus wrote: >>>>> > Hi, >>>>> > >>>>> > I would have preferred to stay away from discussion on why do we >>>>> need/not >>>>> > need Flatpak on SFOS. But I guess I have to take it as the one >>>>> working on >>>>> > making it possible. >>>>> > >>>>> > Native apps rely on the libs allowed in the Store and bundle the >>>>> rest of >>>>> > them. I presume OSM Scout Server and Pure Maps are exceptions, but >>>>> they are >>>>> > built around almost 20 libs bundled with the application and >>>>> compiled with >>>>> > newer gcc than the one on the platform. If I would have continued to >>>>> > provide OSM Scout Server via the official Store, I'd have to bundle >>>>> > libsystemd as well - something that I found was crossing a line for >>>>> me. So, >>>>> > any security issue in those bundled libs would be propagated the >>>>> same way >>>>> > as with the Flatpak. I admit that its way less libs than distributed >>>>> via >>>>> > Flatpak. However, in the case of Flatpak, apps are provided on the >>>>> top of >>>>> > "runtimes" with the app including everything which is extending the >>>>> runtime >>>>> > to make it work. So, in case of OSM Scout Server and Pure Maps, their >>>>> > Flatpaks do include some libs as well. Those runtimes are updated. >>>>> Now, I >>>>> > am not in position to say whether its security updates are as fast >>>>> as of >>>>> > distros and have no idea how it compares to SFOS. >>>>> > >>>>> > However, I see mainly portability and up-to-date toolbox aspect of >>>>> Flatpak, >>>>> > not that much security in terms of sandbox. These are my preferences >>>>> and >>>>> > they could differ from yours. >>>>> > >>>>> > Looking at the speed of upcoming Qt update, I was considering >>>>> whether to >>>>> > make qt5.12 (or later) in /opt (/home/opt) and use it from there to >>>>> allow >>>>> > us to work on newer browser engine or make Flatpak available. The >>>>> both >>>>> > solutions would break look-and-feel of SFOS, but allow us to use >>>>> current >>>>> > libs, something that we have been missing for too long. And, in many >>>>> > aspects, we, as developers, waste lot of time to fight against. I >>>>> swayed >>>>> > towards Flatpaks as it has well developed tools around it, provides >>>>> > portability (you can run it on desktop), and will make sense to have >>>>> when >>>>> > other mobile Linux distros will start going as a way to use the same >>>>> app at >>>>> > all of them. >>>>> > >>>>> > Note that is we develop apps immediately with the reservation that >>>>> we could >>>>> > switch to a native version as soon as it is ready to receive it (in >>>>> terms >>>>> > of Qt version, for example), we can start working on things that are >>>>> > impossible right now on SFOS but may become available later (Qt >>>>> 5.12?). I >>>>> > would expect that this much better than using Android browser on >>>>> SFOS. >>>>> > >>>>> > Please note that it is not to criticize Jolla regarding the update >>>>> speed of >>>>> > Qt. Its probably a complex process and, as we have all built around >>>>> it, may >>>>> > break few things to put it mildly. But a large part of my work as a >>>>> > developer on SFOS is around incompatibilities imposed by old libs >>>>> and gcc. >>>>> > So, from developer POV, its important to prioritize Qt update as >>>>> much as >>>>> > possible. Not sure how much we can help with it, but that's probably >>>>> > separate discussion (please start it if you wish). >>>>> > >>>>> > Sorry for long post, please see my previous ones on technical issues >>>>> that >>>>> > we currently face. >>>>> > >>>>> > As for latest state: >>>>> > >>>>> > Test browser that I can run is executed with: >>>>> > >>>>> > QT_WAYLAND_FORCE_DPI=physical flatpak run --filesystem=host >>>>> --device=all >>>>> > >>>>> --env=HYBRIS_EGLPLATFORM_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris >>>>> > >>>>> --env=HYBRIS_LINKER_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker >>>>> > org.qutebrowser.qutebrowser together.jolla.com >>>>> > >>>>> > libhybris compiled with specification of default >>>>> hybris-ld-library-path, >>>>> > content of libexec/droid-hybris added with GL extension. >>>>> > >>>>> > Cheers, >>>>> > >>>>> > Rinigus >>>>> > >>>>> > >>>>> > >>>>> > On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg < >>>>> > es.rosenberg+sailfishos....@gmail.com> wrote: >>>>> > >>>>> > > Native apps rely on the libs shipped with the OS, thus they don't >>>>> ship >>>>> > > with unsecure libs unless Jolla is shipping them and they become >>>>> secure the >>>>> > > moment Jolla updated the libs (and should the update break binary >>>>> > > compatibility will require a new release compiled against the new >>>>> libs). >>>>> > > Flatpacks and snaps are security nightmares, instead of getting >>>>> them lets >>>>> > > work on moving the SFOS platform along. >>>>> > > >>>>> > > Op zo 29 dec. 2019 om 20:41 schreef rinigus <rinigus....@gmail.com >>>>> >: >>>>> > > >>>>> > >> Hi, >>>>> > >> >>>>> > >> If you refer to http://flatkill.org/ , it does have lot of good >>>>> points. >>>>> > >> In this respect, its similar to what we have with the native >>>>> apps, as soon >>>>> > >> as some security flaws are used. At the moment, I would prefer to >>>>> get >>>>> > >> access to the latest Qt and other recent software. But users are >>>>> still >>>>> > >> responsible for thinking before installing, as they are now. Note >>>>> that in >>>>> > >> many aspects our current packaging together with bundled libs is >>>>> similar to >>>>> > >> flatpak already. So, why not to make it with the recent libs as >>>>> well? >>>>> > >> >>>>> > >> Cheers, >>>>> > >> >>>>> > >> Rinigus >>>>> > >> >>>>> > >> >>>>> > >> On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg < >>>>> > >> es.rosenberg+sailfishos....@gmail.com> wrote: >>>>> > >> >>>>> > >>> No one is bothered by the serious (bad) security implications of >>>>> running >>>>> > >>> flatpacks? >>>>> > >>> Though I guess we are all tolerating the claim to "security" on >>>>> ancient >>>>> > >>> kernels so we have no right to blab about security now π€ >>>>> > >>> >>>>> > >>> Op za 28 dec. 2019 om 12:04 schreef rinigus < >>>>> rinigus....@gmail.com>: >>>>> > >>> >>>>> > >>>> Hi, >>>>> > >>>> >>>>> > >>>> I am not 100% sure whether xdg-shell availability is the >>>>> blocker. There >>>>> > >>>> is something going on which I cannot explain yet - its as if >>>>> Wayland >>>>> > >>>> rendering disappears even when I use qxcomposer. >>>>> > >>>> >>>>> > >>>> qxcomposer does allow me to minimize and then restore. However, >>>>> when >>>>> > >>>> keeping app minimized and switching to other apps, I do get >>>>> (with >>>>> > >>>> WAYLAND_DEBUG=1) >>>>> > >>>> >>>>> > >>>> [2294832.935] wl_pointer@8.motion(207667, 0.000000, 0.000000) >>>>> > >>>> [2299966.213] qt_extended_surface@29.onscreen_visibility(1) >>>>> > >>>> [2303645.301] qt_extended_surface@29.onscreen_visibility(0) >>>>> > >>>> [2303647.486] -> wl_surface@26.destroy() >>>>> > >>>> [2303648.296] -> wl_buffer@4278190080.destroy() >>>>> > >>>> [2303648.395] -> wl_buffer@4278190082.destroy() >>>>> > >>>> [2303648.448] -> wl_buffer@4278190081.destroy() >>>>> > >>>> >>>>> > >>>> and the app window disappears from qxcomposer. >>>>> > >>>> >>>>> > >>>> Same happens when running directly using SFOS composer: >>>>> > >>>> >>>>> > >>>> [2614530.331] qt_extended_surface@29.onscreen_visibility(0) >>>>> > >>>> [2614552.802] -> wl_surface@26.destroy() >>>>> > >>>> [2614555.653] -> wl_buffer@4278190080.destroy() >>>>> > >>>> [2614556.795] -> wl_buffer@4278190082.destroy() >>>>> > >>>> [2614557.099] -> wl_buffer@4278190081.destroy() >>>>> > >>>> >>>>> > >>>> So, looks like the surface gets destroyed, but nothing really >>>>> restores >>>>> > >>>> it. >>>>> > >>>> >>>>> > >>>> As such, some kind of wrapper, similar to qxcomposer, around >>>>> Flatpak >>>>> > >>>> programs maybe handy. It could take few tasks, such as >>>>> > >>>> >>>>> > >>>> - follow orientation of the screen >>>>> > >>>> - restore app after wl_buffer.destroy() >>>>> > >>>> - provide keyboard support >>>>> > >>>> >>>>> > >>>> I don't know enough about Wayland to be efficient in working on >>>>> it. So, >>>>> > >>>> I wonder if someone would like to step in and help with this >>>>> part. If there >>>>> > >>>> is interest, I will work on packaging libhybris extension and >>>>> provide an >>>>> > >>>> example at OBS for Xperia Tama devices. >>>>> > >>>> >>>>> > >>>> Cheers, >>>>> > >>>> >>>>> > >>>> Rinigus >>>>> > >>>> >>>>> > >>>> On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste < >>>>> dcali...@free.fr> >>>>> > >>>> wrote: >>>>> > >>>> >>>>> > >>>>> Thank you Rinigus for all of this. Indeed, the current main >>>>> blocker >>>>> > >>>>> seems to be the fact that xdg-shell is not available in >>>>> Lipstick. This is >>>>> > >>>>> linked to the ancient version of QtWayland, even not 5.6, but >>>>> still 5.4 ! >>>>> > >>>>> They already have a 5.9 branch in SailfishOS git ( >>>>> > >>>>> https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), >>>>> but we >>>>> > >>>>> need to wait for Jolla to make the Qt switch. I don't think >>>>> it's something >>>>> > >>>>> community can change on device... I hope I can be proven wrong >>>>> though. >>>>> > >>>>> >>>>> > >>>>> Damien. >>>>> > >>>>> _______________________________________________ >>>>> > >>>>> SailfishOS.org Devel mailing list >>>>> > >>>>> To unsubscribe, please send a mail to >>>>> > >>>>> devel-unsubscr...@lists.sailfishos.org >>>>> > >>>> >>>>> > >>>> _______________________________________________ >>>>> > >>>> SailfishOS.org Devel mailing list >>>>> > >>>> To unsubscribe, please send a mail to >>>>> > >>>> devel-unsubscr...@lists.sailfishos.org >>>>> > >>> >>>>> > >>> _______________________________________________ >>>>> > >>> SailfishOS.org Devel mailing list >>>>> > >>> To unsubscribe, please send a mail to >>>>> > >>> devel-unsubscr...@lists.sailfishos.org >>>>> > >> >>>>> > >> _______________________________________________ >>>>> > >> SailfishOS.org Devel mailing list >>>>> > >> To unsubscribe, please send a mail to >>>>> > >> devel-unsubscr...@lists.sailfishos.org >>>>> > > >>>>> > > _______________________________________________ >>>>> > > SailfishOS.org Devel mailing list >>>>> > > To unsubscribe, please send a mail to >>>>> > > devel-unsubscr...@lists.sailfishos.org >>>>> > >>>>> >>>>> -- >>>>> Sent from my Jolla >>>>> _______________________________________________ >>>>> SailfishOS.org Devel mailing list >>>>> To unsubscribe, please send a mail to >>>>> devel-unsubscr...@lists.sailfishos.org >>>> >>>> _______________________________________________ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
