[VDPAU] [PATCH] Detect libflashplayer through /proc/self/maps

[Stephen Warren]

Aaron Plattner wrote at Friday, November 22, 2013 9:21 AM:
...
> I wonder if it would be better to create a function that applications
> can call when they know for a fact that they're loading the buggy
> libflashplayer.so.  It's uglier than having libvdpau try to detect it
> itself, but sounds like it would be much more reliable.  That doesn't
> really help applications that use the buggy flash player and their own
> native (correct) VDPAU renderers in the same process, but I don't see a
> way to solve that problem.

The problem is that it's not an application issue whether the bug is
present, but an issue with libflashplayer.so. The app can't know which
Flash Player version is present, and so doesn't have the knowledge to
make such a call. Of course, this argument pre-supposes that Adobe will
sometime fix their bug, which admittedly seems extremely unlikely now,
but we probably shouldn't make life difficult for ourselves if they do.

I wonder if environment variables are passed down to OOP processes?
Perhaps the solution is for a browser wrapper script to set up an
environment variable that enables/disables the workaround in VDPAU.
The wrapper script would be written by the distro, which then would have
knowledge of which specific Flash Player was packaged, and hence could
set the variable appropriately.

IIRC, this problem only affects applications that do SW decode and use
VDPAU for presentation. This shouldn't be a common use-case. So, I wouldn't
worry /too/ much about an app that loads VDPAU itself, yet also loads Flash
Player. The app would hopefully be using VDPAU for decode too and hence not
be affected by the WAR. This is admittedly just guessing though. Either way,
the app could control the environment variable explicitly when forking off
an OOP Flash Player process, so full control would be available if required.

-- 
nvpublic