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

[rinigus]

Hi,

indeed, NVidia is not an issue (for Flatpak), so it is possible to extend
the platforms. As for cross-compilation, I would probably have to use it
for the maps server anyway. In this respect, knowing which apt sources have
to be included in chroot is needed.

Cheers,

Rinigus

On Wed, Jul 3, 2019 at 12:23 AM Sebastian Krzyszkowiak <dos at dosowisko.net>
wrote:

> Hi,
>
> regarding Flatpak and its OpenGL support: recently I've stumbled
> across this MR:
> https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/458
>
> I haven't dug deep into it yet, but it seems like building a layer
> with newer Mesa for all Flatpak applications to use shouldn't be a
> hard thing to do. Which makes sense - after all, Flatpak somehow deals
> with proprietary Nvidia drivers on the desktop (at least I haven't
> noticed any Nvidia users loudly complaining about Flatpak anywhere
> :)).
>
> Cheers,
> dos
>
> On 7/2/19, rinigus via Librem-5-dev
> <librem-5-dev at lists.community.puri.sm> 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?
> >
> > 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
> >>
> >
>
> --
> Sebastian Krzyszkowiak
> dos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.community.puri.sm/pipermail/librem-5-dev/attachments/20190703/e0c54e83/attachment-0001.html>