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

Tue Jul 2 23:59:30 PDT 2019

Hi,
On Tue, Jul 02, 2019 at 11:53:46PM +0300, rinigus via Librem-5-dev wrote:
> 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?

Yes, the devkit and the qemu image use the same apt sources list. The
devkit uses  *arm64* (elsewhere called aarch64) while the qemu image
uses *amd64* (elsewhere called x86_64).
Cheers,
 -- Guido

> 
> 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
> >

> _______________________________________________
> Librem-5-dev mailing list
> Librem-5-dev at lists.community.puri.sm
> https://lists.community.puri.sm/listinfo/librem-5-dev