[Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"

[Christian König]

Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
> I'm under the assumption that OMX/etc don't do anything ridiculous. If
> they do, it's a bug just like this vdpau situation, and should be
> addressed as such. However addressing them should not preclude vdpau
> from being fixed.

Well, that was the whole point of the change. For OMX you don't have a 
standardized sub directory where to put the loadable modules, e.g. it's 
named libomxil-bellagio0 on Ubuntu and completely different on Fedora.

So what I did was just to use the $pluginsdir from libomxil-bellagio.pc 
to determine where to install the OMX files and ignored $prefix. But 
Emil wanted all generated plugins to be installed consistently so he 
changed VDPAU to the same behavior as OMX.

I'm perfectly fine with either approach, but it should just be consistent.

Regards,
Christian.

Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
> On Mon, Oct 6, 2014 at 11:31 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 05/10/14 01:26, Ilia Mirkin wrote:
>>> On Fri, Oct 3, 2014 at 3:43 AM, Christian König <deathsimple at vodafone.de> wrote:
>>>> Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
>>>>
>>>>> On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>>>> wrote:
>>>>>> On 02/10/14 06:41, Ilia Mirkin wrote:
>>>>>>> On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>>>>>> wrote:
>>>>>>>> On 29/09/14 17:24, Matt Turner wrote:
>>>>>>>>> On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
>>>>>>>>> <emil.l.velikov at gmail.com> wrote:
>>>>>>>>>> So all in all we have the following:
>>>>>>>>>>
>>>>>>>>>> Some distributions/people choose odd location of the modules. Which
>>>>>>>>>> can lead to the system (vdpau/omx) looking at the wrong place for the
>>>>>>>>>> backends, i.e. not working. One can consider that there is no way to
>>>>>>>>>> override the module location at runtime.
>>>>>>>>> Do we have more specifics? If they're doing something stupid and it
>>>>>>>>> breaks, they typically get to keep the pieces.
>>>>>>>>>
>>>>>>>>> Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
>>>>>>>>> ${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
>>>>>>>>>
>>>>>>>> Hmm I was under the impression that ${libdir} and
>>>>>>>> /usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as
>>>>>>>> a
>>>>>>>> volunteer for the following, even if the chances of it happening are
>>>>>>>> zero ?
>>>>>>>>
>>>>>>>> On 29/09/14 17:16, Emil Velikov wrote:
>>>>>>>> [...]
>>>>>>>>> How many volunteers do we have that will guide Debian/Ubuntu/other to
>>>>>>>>> do the correct thing ? If we have at least one, I will be OK with
>>>>>>>>> reverting the patch.
>>>>>>> Guide who? The maintainers? Sure, I'll happily help them out.
>>>>>>>
>>>>>> Pretty much everyone that reports a bug/send an email to the ML/posts a
>>>>>> big and flashy "review" along the lines of "vdpau/omx/va is
>>>>>> useless/broken" like YKW.
>>>>>>
>>>>>> The numbers/reports will be low (if any), but the encounters are likely
>>>>>> to be quite "interesting".
>>>>> I'm more than happy to enlighten people as to why what they're doing
>>>>> is wrong. I guess this patch is good then?
>>>>
>>>> You need to implement the same for the OMX target as well, since the
>>>> intention was to get a consistent behavior.
>>> Unfortunately I don't know anything about OMX.
>> Do I take that you've missed that my volunteer request covers vdpau, omx and va ?
> I'm under the assumption that OMX/etc don't do anything ridiculous. If
> they do, it's a bug just like this vdpau situation, and should be
> addressed as such. However addressing them should not preclude vdpau
> from being fixed.
>
> I'm getting this >< close to just not building vdpau anymore due to
> this breakage.
>
>    -ilia