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

[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