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.veli...@gmail.com> wrote:
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König <deathsim...@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.veli...@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.veli...@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.veli...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
