[bug#40835] [PATCH] Update to use panfrost for graphics hardware acceleration

[Brian Woodcox]

> On Apr 27, 2020, at 3:54 PM, Vagrant Cascadian <address@hidden> wrote:

> 
> 
>>> On Apr 27, 2020, at 12:15 PM, Vagrant Cascadian <address@hidden> wrote:
>>> On 2020-04-24, Brian Woodcox wrote:
>>>> You need to edit the /boot/extlinux/extlinux.conf file on the SD card and 
>>>> alter the FDTDIR line.
>>>> 
>>>> I changed mine from
>>>> 
>>>> FDTDIR 
>>>> /gnu/store/ls1byzmapi911cylh4s6044x0cmc61c8-linux-libre-pinebook-pro-5.6.0/lib/dtbs
>>>> 
>>>> to
>>>> 
>>>> FDTDIR 
>>>> /gnu/store/ls1byzmapi911cylh4s6044x0cmc61c8-linux-libre-pinebook-pro-5.6.0/lib/dtbs/rockchip
>>> 
>>> The u-boot-pinebook-pro-rk3399 on guix master works correctly as well as
>>> the one from wip-pinebook-pro (should be the same).
> 
> Oops, my bad. I've been merging master and core-updates locally and
> forgot the status of wip-pinebook-pro... I think I was waiting for the
> core-updates merge, but it's probably worth merging master just to get
> the updated u-boot-pinebook-pro-rk3399 based more closely on upstream
> u-boot!

I would be happy to test that out when done!

> 
> 
>> I’m not sure what this problem is exactly.  For some reason the
>> rockchip folder is not being added to the end of the patch for the
>> FDTFILE, also, you do not need to actually specify the file as u-boot
>> will find it as long as it’s on the directory.
> 
> It's probably a bug in the u-boot fork that's still in wip-pinebook-pro.
> 
> 
>>>> diff --git a/gnu/packages/patches/mesa-skip-disk-cache-test.patch 
>>>> b/gnu/packages/patches/mesa-skip-disk-cache-test.patch
>>>> index 190f6b6ee1..585bf4f648 100644
>>>> --- a/gnu/packages/patches/mesa-skip-disk-cache-test.patch
>>>> +++ b/gnu/packages/patches/mesa-skip-disk-cache-test.patch
>>>> @@ -1,11 +1,6 @@
>>>> -disk_cache_create() here looks up the users home directory from <pwd.h>
>>>> -which resolves to "/" in the build environment. I could not find an easy
>>>> -way to set the home directory to something else, so we disable this test
>>>> -for now.
>>>> -
>>>> --- a/src/compiler/glsl/tests/cache_test.c
>>>> +++ b/src/compiler/glsl/tests/cache_test.c
>>>> -@@ -170,11 +170,6 @@
>>>> +@@ -219,11 +219,6 @@
>>>>    unsetenv("MESA_GLSL_CACHE_DIR");
>>>>    unsetenv("XDG_CACHE_HOME");
>>> 
>>> This removes a comment from the refreshed patch; I presume the comment
>>> is still appropriate, though?
>> 
>> Yes, Patch should have been applied to 
>> d4c6e06f369024efc63e11de1a5bacd3fe9f7e8d as stated above.
> 
> Regardless of which branch it applies to, the comment in this patch
> should probably be kept, unless it's no longer relevent.


Okay, I have to admit I was confused by this.  Turns out when I was debugging, 
I accidentally
removed the comment (or at least my fingers did).  I didn’t realize that and 
now I know why it
appeared in the patch set.  Thus my comment about being applied to the correct 
commit.
That’s what happens when you don’t think things through enough.

> 
> 
>>>> diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
>>>> index 8696dc4bb6..a1e7684964 100644
>>>> --- a/gnu/packages/qt.scm
>>>> +++ b/gnu/packages/qt.scm
>>>> @@ -15,6 +15,7 @@
>>>> ;;; Copyright © 2018 John Soo <address@hidden>
>>>> ;;; Copyright © 2020 Mike Rosset <address@hidden>
>>>> ;;; Copyright © 2020 Jakub Kądziołka <address@hidden>
>>>> +;;; Copyright © 2020 Brian C. Woodcox <address@hidden>
>>>> ;;;
>>>> ;;; This file is part of GNU Guix.
>>>> ;;;
>>>> @@ -485,6 +486,7 @@ developers using C++ or QML, a CSS & JavaScript like 
>>>> language.")
>>>>                 "-no-compile-examples"
>>>>                 ;; Most "-system-..." are automatic, but some use
>>>>                 ;; the bundled copy by default.
>>>> +                 "-opengl" "es2"
>>>>                 "-system-sqlite"
>>>>                 "-system-harfbuzz"
>>>>                 "-system-pcre"
>>> 
>>> This might break some things where a different opengl is the default,
>>> some architectures or platforms may require a different opengl
>>> implementation.
>>> 
>>> I seem to recall some conversations in Debian about the complexities
>>> around which opengl to enable per-architecture or per-platform or ... a
>>> complicated matrix of concerns.
>> 
>> Open to suggestions.
> 
> From what I remember there were no *good* options; to fix things for one
> platforms, you break things for another. In guix it might be slightly
> better off in that you can have variant pacakges more easily, though for
> libraries this would mean variants for everything that uses it,
> too... :/

From the different configuration files I’ve look at from other people,
it appears the patch could be done when the system is configured.
Does that sound like a better place to put it?

I don’t know how else to keep things from getting messy.
> 
> 
> Thanks for joining the guix on pinebook pro adventures!
> 
> 
> live well,
>  vagrant