Bug 236376 - Optionize libva set of ports with X11 and WAYLAND
Summary: Optionize libva set of ports with X11 and WAYLAND
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jan Beich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-07 20:07 UTC by Dries Michiels
Modified: 2019-03-13 18:36 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (jbeich)


Attachments
multimedia/libva-intel-hybrid-driver patch (744 bytes, patch)
2019-03-07 20:07 UTC, Dries Michiels
no flags Details | Diff
debug output (4.54 KB, text/plain)
2019-03-07 20:07 UTC, Dries Michiels
no flags Details
Optinize multimedia/libva-intel-hybrid-driver (609 bytes, patch)
2019-03-09 11:26 UTC, Dries Michiels
no flags Details | Diff
Optionize multimedia/libva-intel-driver (815 bytes, patch)
2019-03-09 11:27 UTC, Dries Michiels
no flags Details | Diff
Optinionize multimedia/libva-utils (2.31 KB, patch)
2019-03-09 11:27 UTC, Dries Michiels
no flags Details | Diff
Optionize multimedia/libva-intel-hybrid-driver (613 bytes, patch)
2019-03-09 11:29 UTC, Dries Michiels
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dries Michiels freebsd_committer 2019-03-07 20:07:03 UTC
Created attachment 202700 [details]
multimedia/libva-intel-hybrid-driver patch

Hi,

When building libva without X11 support vainfo errors out on the hybrid driver not being loaded. When the hybrid driver is also build without X11 support this problem does not occur. Attached debug info (both scenarios) and patch for multimedia/libva-intel-hybrid-driver.
Comment 1 Dries Michiels freebsd_committer 2019-03-07 20:07:24 UTC
Created attachment 202701 [details]
debug output
Comment 2 Jan Beich freebsd_committer 2019-03-07 21:48:58 UTC
What's the use case? Disabling X11 or WAYLAND globally via OPTIONS_UNSET? After changing any of options in multimedia/libva one has to rebuild every consumer. Some of those don't expose a knob to disable X11 or WAYLAND yet e.g., multimedia/libva-utils, multimedia/ffmpeg.
Comment 3 Dries Michiels freebsd_committer 2019-03-08 09:46:03 UTC
That is indeed the use case (and my use case). If someone wants to have hardware acceleration without a running X11 server, the X11 dependencies need not be pulled in. For example, I have a headless home server but would like to use my iGPU for transcoding (emby/plex) which requires libva, libva-intel-driver etc. (although for that use they don't need the X11 dependencies). It is true that other ports will also need to be optionized for the complete chain to be able to build without X11 or WAYLAND.

For that matter; there is a WIP for libva-utils (mailing with madpilot for this).

Libva-intel-driver could also be optionized using meson although I ran into some problems (took a quick look at this yesterday).

I know that OPTIONS_UNSET=X11 are commonly set variables in make.conf that people use with custom package builders like Synth and Poudriere.

If any of my above statements are incorrect please let me know :) I'm here to learn and contribute things to the project that are of benefit to me and other users. I could initiate a PR per port with a patch to optionize them.
Comment 4 Dries Michiels freebsd_committer 2019-03-09 11:26:13 UTC
Created attachment 202738 [details]
Optinize multimedia/libva-intel-hybrid-driver
Comment 5 Dries Michiels freebsd_committer 2019-03-09 11:27:01 UTC
Created attachment 202739 [details]
Optionize multimedia/libva-intel-driver
Comment 6 Dries Michiels freebsd_committer 2019-03-09 11:27:29 UTC
Created attachment 202740 [details]
Optinionize multimedia/libva-utils
Comment 7 Dries Michiels freebsd_committer 2019-03-09 11:29:14 UTC
Created attachment 202741 [details]
Optionize multimedia/libva-intel-hybrid-driver
Comment 8 commit-hook freebsd_committer 2019-03-12 16:53:52 UTC
A commit references this bug:

Author: jbeich
Date: Tue Mar 12 16:53:45 UTC 2019
New revision: 495470
URL: https://svnweb.freebsd.org/changeset/ports/495470

Log:
  multimedia/libva-intel*driver: allow disabling Wayland/X11 independently of libva

  PR:		236376
  Submitted by:	Dries Michiels (based on)

Changes:
  head/multimedia/libva-intel-driver/Makefile
  head/multimedia/libva-intel-hybrid-driver/Makefile
  head/multimedia/libva-intel-media-driver/Makefile
  head/multimedia/libva-intel-media-driver/distinfo
Comment 9 Jan Beich freebsd_committer 2019-03-12 16:59:57 UTC
Landed for what little control it provides. Wayland/X11 support in libva-*driver is completely depends on libva.
Comment 10 Dries Michiels freebsd_committer 2019-03-12 18:27:18 UTC
I know that this PR is not really useful for the wider audience in the FreeBSD project. Although, still very much appreciated. Thank you, Jan!
Comment 11 Jan Beich freebsd_committer 2019-03-12 23:31:57 UTC
Headless setups no-X11 or not are common. What I meant is controlling whether to use libva-x11 *if available* is only useful for debugging. Why would one build libva with X11 support only to disable X11 in consumers?
Comment 12 Dries Michiels freebsd_committer 2019-03-13 18:36:32 UTC
I completely agree that it only makes sense to either build everything with or everything without X11 support. Maybe flavorization would be better to prevent foot shooting? 

The optionization of the drivers and utils are spot on though. Some code paths are not compiled in when those flags are set. 

For example; libva-intel-hybrid-driver did not want to initialize before optionization when libva was build without X11 support (attachment: debug output). 

Another example; libva-utils produced error messages trying to attach to an X11/WAYLAND server, which is not the case anymore when building it without X11/WAYLAND support. (for what its worth)

Are you saying that the consumers of libva in the state before the commit already auto detect if libva-x11.so is present or not and auto configure themselves to build with or without X11 support (even though it was not an option)? Then I completely follow you that it did not make sense to optionize those ports.