сб, 14 дек. 2019 г. в 10:27, Brad DeMorrow <b...@demorrow.net>: > > On Sat, Dec 14, 2019 at 1:16 AM Vadim Zhukov <persg...@gmail.com> wrote: >> >> сб, 14 дек. 2019 г. в 08:25, Vadim Zhukov <persg...@gmail.com>: >> > >> > сб, 14 дек. 2019 г. в 06:10, Brad DeMorrow <b...@demorrow.net>: >> > > >> > > Thank you both, this is very helpful for me. >> > > Attached are updated tarballs. >> > > Since the meson module does the right thing, I stuck with using it for >> > > all three ports. >> > >> > Then why do you create that symlink mess and complicate SHARED_LIBS? >> > >> > I've just checked, just setting SHARED_LIBS to 0.0 work fine, as it >> > should. You'd simply drop the post-install target all variables >> > created for it. >> > >> > Also, lib/dri/i965_drv_video.so still lacks @so marker. Do you run >> > recent snapshot? Could you post your dmesg, please? >> >> Aha, so I found a problem: in intel driver, in i965_output_dri.c, >> there is the LIBVA_X11_NAME string which hardcodes the library version >> of libva-x11. The driver tries to dlopen this name and, obviously, >> fails. Same thing happens in Wayland-related code, but since we have >> no Wayland yet, we can ignore it for now. :) After removing ".2" from >> the LIBVA_X11_NAME things start to work! Well, vainfo starts to work. >> IIUC, existing stuff that could use VA-API needs to be recompiled... >> How do you actually use VA-API? > > I have a two follow up ports that can use it. > - ffmpeg: I sent a request to the maintainer earlier today about amending the > port to include vaapi support. > - moonlight-qt: relies on ffmpeg with vaapi support. Allows game streaming > from Windows PCs with Nvidia gamestream technology. I’ve played a couple > hours of games with it- it’s nice.
Aha, would be nice to test! IIRC, VA-API could be used for encoding as well... I'm building ffmpeg right now, and I will try to run some vaapi-enabled encoder. > As far as the hard coded library name, yeah that’s why I have to use the > symlinks.. I could patch it, but it looks like it’s very intentional on their > part. The email I sent you a few minutes ago includes a reference to their > warning message about changing the .so names. The upstream tries to hardcode major versions to fix the problem you won't have on OpenBSD: libva and intel-vaapi-driver would be kept in sync anyway. And hardcoding major version in dlopen() won't save you from calling a function not present in this minor version of shared library anyway. I don't understand yet why this dlopen() call is ever needed... >> > >> See meson.port.mk and patch-mesonbuild_build_py. >> > >> Using SHARED_LIBS foo 1.0 will make meson.port.mk set a >> > >> LIBfoo_VERSION=1.0 environment variable which meson will use. >> > >> > Whoa, thanks, Jonathan! And Antoine, of course. :) :) >> > >> > >> Using ports meson to build things outside of ports is more painful as >> > >> these environment variables have to be explicitly set and sometimes >> > >> ninja will re-run meson and not have the environment variables set. >> > >> >> > >> https://github.com/mesonbuild/meson/issues/3570 describes related >> > >> problems. >> > >> > -- >> > WBR, >> > Vadim Zhukov >> >> >> >> -- >> WBR, >> Vadim Zhukov > > -- > --Brad DeMorrow -- WBR, Vadim Zhukov
