[Librem-5-dev] early feedback: issues encountered while running maps applications

[rinigus]

Hi,

forwarding earlier reply of Guido (below) which escaped this list due to my
mistake (sending reply to him directly and not via the list).

I have a question regarding chroot environment that is suitable for L5
devkit compilation. On QEMU, apt sources are Debian buster and

deb http://ci.puri.sm/ scratch librem5

I presume that the architecture is arm64 (as for sbuild --host=arm64), but
would be great to verify the source.list which is suitable for L5 devkit
cross-compilation. Is the combination of the sources on L5 devkit the same
as for QEMU?

Idea is to build native DEBs that would allow us to use the latest OpenGL
and other's patches made for L5.

Cheers,

Rinigus

On Wed, Jun 26, 2019 at 11:45 AM Guido Günther <agx at sigxcpu.org> wrote:

> Hi,
> On Tue, Jun 25, 2019 at 11:53:47PM +0300, rinigus wrote:
> > Guido, thank you for the help! My replies are below.
> >
> > On Tue, Jun 25, 2019 at 11:08 AM <guido.gunther at puri.sm> wrote:
> >
> > > [..snip..]
> > >
> > > Are you using a patched runtime with our GC7000 mesa patches? If not
> there
> > > will
> > > be rendering issues. There's lots of stuff upstream already but some
> > > core parts are missing that are required for proper texture
> > > rendering. You should see a notable difference between pure maps
> > > as flatpak and pure maps built natively on the devkit / qemu image. If
> > > not please let me know.
> > >
> >
> > don't know whether David had the patches applied. As for native on QEMU
> > using virtual machine - do you expect noticeable difference for flatpak
> vs
> > native in QEMU running on PC?
>
> For amd64 there shouldn't be any major differences.
>
> > Second question: how can I cross-compile for devkit? Building on devkit
> > maybe too much for it, taking into account the libraries which are
> > needed.
>
> The devkit is quite powerful and I'm building lots of things
> natively. You can cross compile the way you want and what your toolset
> supports best. If you're Debian based see
>
> https://wiki.debian.org/CrossCompiling
>
> and
>
> https://wiki.debian.org/CrossToolchains
>
> > Since you filed https://source.puri.sm/Librem5/Apps_Issues/issues/135
> > (flatpak runtime patching), should we expect similar performance for
> native
> > and flatpak applications? Hopefully, patches will be applied for KDE
> > runtime as well.
>
> This is not about performance, it's about functionality. Without pathed
> runtimes there will be e.g. no working OpenGL in flatpak, toolkits are
> missing patches, etc.
>
> [..snip..]
> > > Can you be more specific. Do you expect polkit authentiction? If so
> > >
> > > https://source.puri.sm/Librem5/phosh/merge_requests/213
> > >
> > > does fix the shell side but we need to fix
> > >
> > > https://source.puri.sm/Librem5/phosh/issues/34
> > >
> > > for this to work (it basically works if you launch the compositor from
> > > the console when logging in instead of the systemd unit).
> > >
> >
> > I will have to look it up. Namely, we need some kind of mechanism to
> allow
> > users to accept or decline request by applications for geo data. How it
> is
> > done internally in GNOME, I don't know
>
> What does your app use to request these permission? Toolkit / desktop
> environment is secondary here.
>
> > > > # Apps are running with Window decorations
> > > >
> > > > I would expect to have apps running without any window decorations.
> That
> > > > holds for Gnome apps, as far as I can see. For QML, we are getting
> window
> > > > decorations and, in console,
> > > >
> > > > "Using the 'xdg-shell' shell integration"
> > >
> > [...]
> >
> > > This depends on your app. You need to provide more details. Are you
> > > rendering via x11 or wayland? Is there a simple one line test case to
> > > verify this (without installing pure maps)? By default all x11 surfaces
> > > are decorated. You should be rendering via wayland when possible.
> >
> >
> > It should be wayland. I am specifying wayland using platform switch of
> Qt.
> > During execution, Qt writes on stdout: "Using Wayland-EGL"
> >
> > As for simple 1-line test, you could clone
> > https://github.com/rinigus/qmltest , and follow repos README to install
> > packages and run a test_simple.qml .
> >
> > When compared to QML running through flatpak, where we get "Using the
> > 'xdg-shell' shell integration", native QML produces "Using the
> > 'xdg-shell-v6' shell integration".
> >
> > [just received David's reply]: When trying
> > with QT_WAYLAND_DISABLE_WINDOWDECORATION=1, running Pure Maps via flatpak
> > (Qt 5.12), all worked as it should and without any decorations. On
> native,
> > the application wasn't that content, but I will have to look into it
> myself
> > (or hope that Debian & PureOS will switch to 5.12). Thanks for your help!
> >
> >
> > BTW, after updating to the latest version, I noticed that the lock screen
> > in QML uses lots of CPU
> >
> > /usr/lib/wlroots/rootston: 70%
> > /usr/lib/x86_64-linux-gnu/phosh: 20%
> >
> > Probably due to swipe animation. As soon as you unlock, all is fine.
>
> Thanks for pointing this out!
>  -- Guido
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.community.puri.sm/pipermail/librem-5-dev/attachments/20190702/41ef9775/attachment.html>