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

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 4280 bytes --]

On 2020-04-27, Brian Woodcox wrote:
> Sorry, this should have been applied to commit
> d4c6e06f369024efc63e11de1a5bacd3fe9f7e8d on the tip-pinebook-pro
> branch.

Yeah, I got that!


>> On Apr 27, 2020, at 12:15 PM, Vagrant Cascadian <vagrant@debian.org> 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’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.


>>> 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 <jsoo1@asu.edu>
>>> ;;; Copyright © 2020 Mike Rosset <mike.rosset@gmail.com>
>>> ;;; Copyright © 2020 Jakub Kądziołka <kuba@kadziolka.net>
>>> +;;; Copyright © 2020 Brian C. Woodcox <bw@InSkyData.com>
>>> ;;;
>>> ;;; 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... :/


Thanks for joining the guix on pinebook pro adventures!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]