сб, 14 дек. 2019 г. в 04:07, Brad DeMorrow <b...@demorrow.net>:
>
> First of all, thank you for taking the time to review and test this Vadim.
> Comments inline below.
> I have questions about using autotools for the intel-vaapi-driver port, so I 
> won't
> attach new tarballs yet.
>
> On Fri, Dec 13, 2019 at 3:58 PM Vadim Zhukov <persg...@gmail.com> wrote:
>>
>> пт, 13 дек. 2019 г. в 22:17, Brad DeMorrow <b...@demorrow.net>:
>>
>> It looks like not all inteldrm will work. At least mine (found on
>> ThinkPad X240) doesn't:
>
> You're correct, my mistake.  It specifically says "Intel G45 chipsets
> and Intel HD Graphics for Intel Core processor family" in their README.
>
> I reached out to intel to get a clearer picture and discovered that they 
> actually
> have a newer VA-API driver available called media-driver.  It appears better
> documented at least.
> https://github.com/intel/media-driver

Mine is called "HD Graphics" too, but this doesn't help. :(

inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x0b

> I'll have to consider working on that next.

It would be nice!

>> The autotools will work better in this case,
>> at least you'll have SHARED_LIBS stuff right. See the tweaked libva
>> port Makefile for example.
>>
>>
>> Please regen PLIST for intel-vaapi-driver port, this should add @so marker.
>
> I was able to get libva and libva-utils working with autotools, but the 
> intel-vaapi-driver
> ended up generating a .la file instead of a .so file.  I'm not very familiar 
> with autotools,
> is this an easy fix?
> Can you explain why using the meson module would be frowned upon?

For libva port autotools are better, since devel/meson module doesn't
force shared libraries versioning the OpenBSD way, forcing a lot of
work to be done in the port. You did some already, but there must be
much more: for example, resulting .la files (those are used by libtool
when building dependant software) will reference wrong libraries.

For the ports that does NOT produce "normal" shared libraries (like
actual VA-API drivers that are more plugins than proper shared
libraries here) you can keep the devel/meson as is, if it's easier for
you. In theory, the devel/meson port module could be tweaked, or more
port-specific magic may be put in, but at least I'm not the one
willing to do neither of those. :)

-- 
  WBR,
  Vadim Zhukov

Reply via email to