review of OpenGL blacklist work

[Markus Mohrhard]

Hey,

On Fri, Jun 5, 2015 at 1:59 PM, Thorsten Behrens <thb at documentfoundation.org
> wrote:

> 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)?
>

To some degree. We are limited in the information that the mozilla code
exposes as I will surely not going to touch that code.

Can you explain what you had in mind with the config layer idea. I don't
see the values as I doubt many admins will be able to change it and I had
hoped that it would be enough to provide a config entry that points the
local location of the blacklist. So if a admin really wants to disable
access to it he puts the blacklist in a place where the user can't touch it
and lock the setting.

For most people I see two modes, either you trust TDF and the developers to
some degree and want to avoid crashes and use the update service or you
just use the version that is shipped with the release. Filling the entries
is actually not that easy so I don't believe there are people going to do
that on their own.



>
> > 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).
>

Good point. I'll keep an eye out for it. One more reason that we would need
a crash reporter so we could get a number of information from crashes.


>
> > 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).
>
>
I would start with the same solution that we use for the update check right
now and expand it over time.

Regards,
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150606/1bea9001/attachment.html>