<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">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.</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, Jul 3, 2019 at 12:23 AM Sebastian Krzyszkowiak <<a href="mailto:dos@dosowisko.net">dos@dosowisko.net</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>
<br>
regarding Flatpak and its OpenGL support: recently I've stumbled<br>
across this MR:<br>
<a href="https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/458" rel="noreferrer" target="_blank">https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/458</a><br>
<br>
I haven't dug deep into it yet, but it seems like building a layer<br>
with newer Mesa for all Flatpak applications to use shouldn't be a<br>
hard thing to do. Which makes sense - after all, Flatpak somehow deals<br>
with proprietary Nvidia drivers on the desktop (at least I haven't<br>
noticed any Nvidia users loudly complaining about Flatpak anywhere<br>
:)).<br>
<br>
Cheers,<br>
dos<br>
<br>
On 7/2/19, rinigus via Librem-5-dev<br>
<<a href="mailto:librem-5-dev@lists.community.puri.sm" target="_blank">librem-5-dev@lists.community.puri.sm</a>> wrote:<br>
> Hi,<br>
><br>
> forwarding earlier reply of Guido (below) which escaped this list due to my<br>
> mistake (sending reply to him directly and not via the list).<br>
><br>
> I have a question regarding chroot environment that is suitable for L5<br>
> devkit compilation. On QEMU, apt sources are Debian buster and<br>
><br>
> deb <a href="http://ci.puri.sm/" rel="noreferrer" target="_blank">http://ci.puri.sm/</a> scratch librem5<br>
><br>
> I presume that the architecture is arm64 (as for sbuild --host=arm64), but<br>
> would be great to verify the source.list which is suitable for L5 devkit<br>
> cross-compilation. Is the combination of the sources on L5 devkit the same<br>
> as for QEMU?<br>
><br>
> Idea is to build native DEBs that would allow us to use the latest OpenGL<br>
> and other's patches made for L5.<br>
><br>
> Cheers,<br>
><br>
> Rinigus<br>
><br>
> On Wed, Jun 26, 2019 at 11:45 AM Guido Günther <<a href="mailto:agx@sigxcpu.org" target="_blank">agx@sigxcpu.org</a>> wrote:<br>
><br>
>> 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<br>
>> 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.<br>
>> > > 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<br>
>> 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<br>
>> 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<br>
>> > > 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<br>
>> allow<br>
>> > users to accept or decline request by applications for geo data. How it<br>
>> 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.<br>
>> That<br>
>> > > > holds for Gnome apps, as far as I can see. For QML, we are getting<br>
>> 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<br>
>> > > 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<br>
>> 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<br>
>> > flatpak<br>
>> > (Qt 5.12), all worked as it should and without any decorations. On<br>
>> native,<br>
>> > the application wasn't that content, but I will have to look into it<br>
>> myself<br>
>> > (or hope that Debian & PureOS will switch to 5.12). Thanks for your<br>
>> > help!<br>
>> ><br>
>> ><br>
>> > BTW, after updating to the latest version, I noticed that the lock<br>
>> > 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>
>><br>
><br>
<br>
-- <br>
Sebastian Krzyszkowiak<br>
dos<br>
</blockquote></div>