[bug#36814,BONUS,3/2] gnu: intel-vaapi-driver: Provide LIBVA_DRIVERS_PATH.
diff mbox series

Message ID 20190726184040.31236-1-me@tobias.gr
State New
Headers show
Series
  • Add VA-API Intel back-end and utilities
Related show

Commit Message

Tobias Geerinckx-Rice via Guix-patches via July 26, 2019, 6:40 p.m. UTC
* gnu/packages/video.scm (intel-vaapi-driver)[native-search-paths]:
Export LIBVA_DRIVERS_PATH when installed.
(libva-without-mesa)[native-search-paths]: Don't inherit any.
---

Guix,

This ties the two together.

I'm leaving the enormocomment in so I don't have to repeat it here, but I'm less sure about it now than when I wrote it.  I thought this was a filthy hack, but maybe it's just mildly unconventional ;-)  The documentation is very sparse indeed.

I don't see any acceptable alternative.

Stormy regards,

T G-R

 gnu/packages/gl.scm    |  3 ++-
 gnu/packages/video.scm | 13 +++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

Comments

Marius Bakke July 27, 2019, 6:26 p.m. UTC | #1
Tobias Geerinckx-Rice via Guix-patches <guix-patches@gnu.org> writes:

> * gnu/packages/video.scm (intel-vaapi-driver)[native-search-paths]:
> Export LIBVA_DRIVERS_PATH when installed.

Can this be squashed into patch 1/2 in this series?

> (libva-without-mesa)[native-search-paths]: Don't inherit any.

...and this added in a separate patch, so that the intel-vaapi-driver
change does not have to go through 'staging'?

> I'm leaving the enormocomment in so I don't have to repeat it here, but I'm less sure about it now than when I wrote it.  I thought this was a filthy hack, but maybe it's just mildly unconventional ;-)  The documentation is very sparse indeed.

The comment could perhaps be shortened by including a link to
<https://issues.guix.gnu.org/issue/22138>.
Tobias Geerinckx-Rice via Guix-patches via July 27, 2019, 6:50 p.m. UTC | #2
Marius Bakke 写道:
> Tobias Geerinckx-Rice via Guix-patches <guix-patches@gnu.org> 
> writes:
>
>> * gnu/packages/video.scm 
>> (intel-vaapi-driver)[native-search-paths]:
>> Export LIBVA_DRIVERS_PATH when installed.
>
> Can this be squashed into patch 1/2 in this series?

Sure.  I wasn't really going to merge this as FREE BONUS PATCH, 
don't worry.

>> (libva-without-mesa)[native-search-paths]: Don't inherit any.
>
> ..and this added in a separate patch, so that the 
> intel-vaapi-driver
> change does not have to go through 'staging'?

Are you sure?  This hunk is here to keep the mesa derivation 
unchanged.  Removing (or delaying) it *will* cause all of mesa's 
1436 dependents to be rebuilt.  I don't think we want that.

>> I'm leaving the enormocomment in so I don't have to repeat it 
>> here, but I'm less sure about it now than when I wrote it.  I 
>> thought this was a filthy hack, but maybe it's just mildly 
>> unconventional ;-)  The documentation is very sparse indeed.
>
> The comment could perhaps be shortened by including a link to
> <https://issues.guix.gnu.org/issue/22138>.

Oh thank gods yes.  I missed that bug.  I'm glad this is 
considered important.  For now, this workaround + a link seems 
acceptable to me.

Thanks!

T G-R
Tobias Geerinckx-Rice via Guix-patches via July 27, 2019, 7:08 p.m. UTC | #3
Tobias Geerinckx-Rice via Guix-patches 写道:
> Marius Bakke 写道:
>> Tobias Geerinckx-Rice via Guix-patches <guix-patches@gnu.org>
>> writes:
>>> (libva-without-mesa)[native-search-paths]: Don't inherit any.
>>
>> ..and this added in a separate patch, so that the 
>> intel-vaapi-driver
>> change does not have to go through 'staging'?
>
> Are you sure?  This hunk is here to keep the mesa derivation
> unchanged.  Removing (or delaying) it *will* cause all of mesa's 
> 1436
> dependents to be rebuilt.  I don't think we want that.

Actually, we're both wrong.  Yay!

This is a forgotten left-over from when the native-search-paths 
were in libva.  Now that they're not, it's useless & should just 
be dropped.

Right.  Right?

T G-R
Marius Bakke July 27, 2019, 7:13 p.m. UTC | #4
Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Marius Bakke 写道:
>> Tobias Geerinckx-Rice via Guix-patches <guix-patches@gnu.org> 
>> writes:
>>
>>> * gnu/packages/video.scm 
>>> (intel-vaapi-driver)[native-search-paths]:
>>> Export LIBVA_DRIVERS_PATH when installed.
>>
>> Can this be squashed into patch 1/2 in this series?
>
> Sure.  I wasn't really going to merge this as FREE BONUS PATCH, 
> don't worry.
>
>>> (libva-without-mesa)[native-search-paths]: Don't inherit any.
>>
>> ..and this added in a separate patch, so that the 
>> intel-vaapi-driver
>> change does not have to go through 'staging'?
>
> Are you sure?  This hunk is here to keep the mesa derivation 
> unchanged.  Removing (or delaying) it *will* cause all of mesa's 
> 1436 dependents to be rebuilt.  I don't think we want that.

I don't see 'libva' being changed anywhere in this series?  The search
path is added for intel-vaapi-driver only, no?

But then, it's 32 degrees here in Trondheim and I just returned from a
hike, so I have probably missed something.

Leaving libva-without-mesa unchanged was my intent too, so I think we
are all good.  :-)
Marius Bakke July 27, 2019, 7:16 p.m. UTC | #5
Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Tobias Geerinckx-Rice via Guix-patches 写道:
>> Marius Bakke 写道:
>>> Tobias Geerinckx-Rice via Guix-patches <guix-patches@gnu.org>
>>> writes:
>>>> (libva-without-mesa)[native-search-paths]: Don't inherit any.
>>>
>>> ..and this added in a separate patch, so that the 
>>> intel-vaapi-driver
>>> change does not have to go through 'staging'?
>>
>> Are you sure?  This hunk is here to keep the mesa derivation
>> unchanged.  Removing (or delaying) it *will* cause all of mesa's 
>> 1436
>> dependents to be rebuilt.  I don't think we want that.
>
> Actually, we're both wrong.  Yay!
>
> This is a forgotten left-over from when the native-search-paths 
> were in libva.  Now that they're not, it's useless & should just 
> be dropped.
>
> Right.  Right?

Right!  LGTM, thanks!

(...please disregard the other message...)

Patch
diff mbox series

diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 9ed043c7ae..9495e8ee24 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -219,7 +219,8 @@  also known as DXTn or DXTC) for Mesa.")
         '(#:make-flags)
         (substitute-keyword-arguments (package-arguments libva)
           ((#:configure-flags flags)
-           '(list "--disable-glx" "--disable-egl"))))))))
+           '(list "--disable-glx" "--disable-egl")))))
+      (native-search-paths '()))))
 
 (define-public mesa
   (package
diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
index b441c5e311..5e26b4c2dc 100644
--- a/gnu/packages/video.scm
+++ b/gnu/packages/video.scm
@@ -2756,6 +2756,19 @@  of modern, widely supported codecs.")
              (let ((out (assoc-ref outputs "out")))
                (setenv "LIBVA_DRIVERS_PATH" (string-append out "/lib/dri"))
                #t))))))
+    ;; XXX This variable is actually respected by libva, and in a perfect world
+    ;; would be found there instead.  Unfortunately, native-search-paths are set
+    ;; up only if the package using them is installed directly into the profile.
+    ;; This means that users would need to install libva into their profile for
+    ;; no good reason other than convincing Guix to export the right paths, or
+    ;; that every single one of libva's many dependents would would need to be
+    ;; modified instead (and would still be semantically dubious).  Moving it
+    ;; here is logically (almost) equivalent, and keeps this hack confined to a
+    ;; tiny handful of back-end packages.
+    (native-search-paths
+     (list (search-path-specification
+            (variable "LIBVA_DRIVERS_PATH")
+            (files '("lib/dri")))))
     (home-page "https://01.org/linuxmedia/vaapi")
     (synopsis "VA-API video acceleration driver for Intel GEN Graphics devices")
     (description