review of OpenGL blacklist work

Thorsten Behrens thb at documentfoundation.org
Fri Jun 5 04:59:05 PDT 2015


Markus Mohrhard wrote:
> 2.) The blacklist is in the source code which means that if you discover
> combinations that cause issues (crashes, rendering issues, ...) you have no
> chance to help users until the next release. Mozilla, despite a much faster
> release cycle, has therefore already switched to mostly a xml based
> blacklist that is updated from a central server and only a small part (e.g.
> for past security issues) stays in the code).
> 
Makes quite a lot of sense.

> I have implemented something similar now in the feature/opengl-preparation
> branch for windows as preparation for the glyphy work (which is expected to
> uncover many driver bugs). I'd appreciated if someone would have a look at
> it and comment on the general idea (do we want to use that concept, is
> there something that I missed, ...).
> 
Looks good in general, just of course the devil is in the details -

Ideally, one would either have that within the established libreoffice
xml configuration system (such that system integrators can override
it, lock it down partially, install config-only extensions that tweak
it etc etc) - or have an optional config layer that overrides whatever
special downloaded blacklist there is. See
canvas/source/directx/dx_config.cxx for an existing solution.

Or is the plan to re-use the mozilla blacklist service (and thus we're
bound to their markup)?

> I'd also like to add one more feature to my xml files to be able to
> specify selected features that should be disabled. So it would be
> possibly to disable OpenGL text rendering while keeping the other
> OpenGL features available.
> 
That's actually pretty cool. And maybe also a way to override driver
info outputs? If you look into the DirectX stuff I did, there's one
entry to override the driver output for max texture sizes (which some
drivers simply lie about, to pass game engine checks I presume).

> Please note that the automatic update is not yet implemented as I
> have no URL on a TDF server yet.
> 
I guess the harder part here is to make that tamper-resistant (ssl,
certificate pinning, that sort of stuff).

My 2 cents,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150605/164b817c/attachment.sig>


More information about the LibreOffice mailing list