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

[Aaron Plattner]

On 11/21/13 12:40, Anssi Hannula wrote:
> 13.11.2013 01:44, Jeroen Roovers kirjoitti:
>> Parsing /proc/self/cmdline does not always detect libflashplayer since
>> not every browser includes that string. /proc/self/maps will always map
>> the library we are looking for, so we use that instead.
> [...]
>
> This patch causes various false positives.
>
> The one Rémi and Robert noted is that if a browser has a non-OOP Flash
> Player loaded, then any of the browser's other VDPAU usage (e.g. HTML5
> video rendering or video rendering of another NPAPI plugin) get caught
> in the workaround as well. One such browser running plugins in-process
> is midori.
>
> Additionally, some OOP-plugin browsers (e.g. firefox for me) have
> libflashplayer in their /proc/self/maps even though they actually run
> the plugin in a separate process.
>
> Wrongly triggering the workaround will AFAICS cause broken rendering,
> and it is IMHO much worse to have correctly written VDPAU applications
> behave wrongly (in case of a false positive) than to have incorrectly
> written VDPAU applications behave wrongly (the latter being current
> situation).
>
> I suggest:
> 1) Check if cmdline contains "libflashplayer". If so, it is a strong
>     indication that this is OOP plugin (this is what the code currently
>     does).
> 2) Check if comm contains "opera:libflashp".
> 3) Check if comm contains a known OOP plugin player ("nspluginviewer",
>     others?). If so, check /proc/self/maps like your patch does.

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.

-- 
Aaron