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

[Sebastian Krzyszkowiak]

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