<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">forwarding earlier reply of Guido (below) which escaped this list due to my mistake (sending reply to him directly and not via the list).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have a question regarding chroot environment that is suitable for L5 devkit compilation. On QEMU, apt sources are Debian buster and </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">deb <a href="http://ci.puri.sm/">http://ci.puri.sm/</a> scratch librem5<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Idea is to build native DEBs that would allow us to use the latest OpenGL and other's patches made for L5.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rinigus</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 26, 2019 at 11:45 AM Guido Günther <<a href="mailto:agx@sigxcpu.org">agx@sigxcpu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
On Tue, Jun 25, 2019 at 11:53:47PM +0300, rinigus wrote:<br>
> Guido, thank you for the help! My replies are below.<br>
> <br>
> On Tue, Jun 25, 2019 at 11:08 AM <<a href="mailto:guido.gunther@puri.sm" target="_blank">guido.gunther@puri.sm</a>> wrote:<br>
> <br>
> > [..snip..]<br>
> ><br>
> > Are you using a patched runtime with our GC7000 mesa patches? If not there<br>
> > will<br>
> > be rendering issues. There's lots of stuff upstream already but some<br>
> > core parts are missing that are required for proper texture<br>
> > rendering. You should see a notable difference between pure maps<br>
> > as flatpak and pure maps built natively on the devkit / qemu image. If<br>
> > not please let me know.<br>
> ><br>
> <br>
> don't know whether David had the patches applied. As for native on QEMU<br>
> using virtual machine - do you expect noticeable difference for flatpak vs<br>
> native in QEMU running on PC?<br>
<br>
For amd64 there shouldn't be any major differences.<br>
<br>
> Second question: how can I cross-compile for devkit? Building on devkit<br>
> maybe too much for it, taking into account the libraries which are<br>
> needed.<br>
<br>
The devkit is quite powerful and I'm building lots of things<br>
natively. You can cross compile the way you want and what your toolset<br>
supports best. If you're Debian based see<br>
<br>
<a href="https://wiki.debian.org/CrossCompiling" rel="noreferrer" target="_blank">https://wiki.debian.org/CrossCompiling</a><br>
<br>
and<br>
<br>
<a href="https://wiki.debian.org/CrossToolchains" rel="noreferrer" target="_blank">https://wiki.debian.org/CrossToolchains</a><br>
<br>
> Since you filed <a href="https://source.puri.sm/Librem5/Apps_Issues/issues/135" rel="noreferrer" target="_blank">https://source.puri.sm/Librem5/Apps_Issues/issues/135</a><br>
> (flatpak runtime patching), should we expect similar performance for native<br>
> and flatpak applications? Hopefully, patches will be applied for KDE<br>
> runtime as well.<br>
<br>
This is not about performance, it's about functionality. Without pathed<br>
runtimes there will be e.g. no working OpenGL in flatpak, toolkits are<br>
missing patches, etc.<br>
<br>
[..snip..]<br>
> > Can you be more specific. Do you expect polkit authentiction? If so<br>
> ><br>
> > <a href="https://source.puri.sm/Librem5/phosh/merge_requests/213" rel="noreferrer" target="_blank">https://source.puri.sm/Librem5/phosh/merge_requests/213</a><br>
> ><br>
> > does fix the shell side but we need to fix<br>
> ><br>
> > <a href="https://source.puri.sm/Librem5/phosh/issues/34" rel="noreferrer" target="_blank">https://source.puri.sm/Librem5/phosh/issues/34</a><br>
> ><br>
> > for this to work (it basically works if you launch the compositor from<br>
> > the console when logging in instead of the systemd unit).<br>
> ><br>
> <br>
> I will have to look it up. Namely, we need some kind of mechanism to allow<br>
> users to accept or decline request by applications for geo data. How it is<br>
> done internally in GNOME, I don't know<br>
<br>
What does your app use to request these permission? Toolkit / desktop<br>
environment is secondary here.<br>
<br>
> > > # Apps are running with Window decorations<br>
> > ><br>
> > > I would expect to have apps running without any window decorations. That<br>
> > > holds for Gnome apps, as far as I can see. For QML, we are getting window<br>
> > > decorations and, in console,<br>
> > ><br>
> > > "Using the 'xdg-shell' shell integration"<br>
> ><br>
> [...]<br>
> <br>
> > This depends on your app. You need to provide more details. Are you<br>
> > rendering via x11 or wayland? Is there a simple one line test case to<br>
> > verify this (without installing pure maps)? By default all x11 surfaces<br>
> > are decorated. You should be rendering via wayland when possible.<br>
> <br>
> <br>
> It should be wayland. I am specifying wayland using platform switch of Qt.<br>
> During execution, Qt writes on stdout: "Using Wayland-EGL"<br>
> <br>
> As for simple 1-line test, you could clone<br>
> <a href="https://github.com/rinigus/qmltest" rel="noreferrer" target="_blank">https://github.com/rinigus/qmltest</a> , and follow repos README to install<br>
> packages and run a test_simple.qml .<br>
> <br>
> When compared to QML running through flatpak, where we get "Using the<br>
> 'xdg-shell' shell integration", native QML produces "Using the<br>
> 'xdg-shell-v6' shell integration".<br>
> <br>
> [just received David's reply]: When trying<br>
> with QT_WAYLAND_DISABLE_WINDOWDECORATION=1, running Pure Maps via flatpak<br>
> (Qt 5.12), all worked as it should and without any decorations. On native,<br>
> the application wasn't that content, but I will have to look into it myself<br>
> (or hope that Debian & PureOS will switch to 5.12). Thanks for your help!<br>
> <br>
> <br>
> BTW, after updating to the latest version, I noticed that the lock screen<br>
> in QML uses lots of CPU<br>
> <br>
> /usr/lib/wlroots/rootston: 70%<br>
> /usr/lib/x86_64-linux-gnu/phosh: 20%<br>
> <br>
> Probably due to swipe animation. As soon as you unlock, all is fine.<br>
<br>
Thanks for pointing this out!<br>
 -- Guido<br>
</blockquote></div>