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.
Created attachment 202701 [details] debug output
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.
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.
Created attachment 202738 [details] Optinize multimedia/libva-intel-hybrid-driver
Created attachment 202739 [details] Optionize multimedia/libva-intel-driver
Created attachment 202740 [details] Optinionize multimedia/libva-utils
Created attachment 202741 [details] Optionize multimedia/libva-intel-hybrid-driver
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
Landed for what little control it provides. Wayland/X11 support in libva-*driver is completely depends on libva.
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!
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?
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.