Re: review of OpenGL blacklist work
Markus Mohrhard wrote: > Can you explain what you had in mind with the config layer idea. > Largely just avoiding duplicated code (no need to xml-parse, do layering etc). > 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. > Well, it's just the principle of least surprise - all standard config deployment/overriding/lockdown mechanisms would then simply work. Also - as always, there'll be at least *one* person wanting to do special magic ... ;) > 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. > Fair enough. Doesn't make group policies / machine-specific settings extra-easy, but I guess it'll work. Cheers, -- Thorsten signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: review of OpenGL blacklist work
On Fri, Jun 5, 2015 at 2:16 PM, Michael Stahl wrote: > On 05.06.2015 13:59, Thorsten Behrens wrote: > > Markus Mohrhard wrote: > >> 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. > > iirc the OpenCL stuff also has some sort of blacklist nowadays, wonder > if all of these should use the same sort of mechanism - that would make > it easier to admin. > > Sadly the OpenCL stuff uses a manual blacklist that has to be maintained by the user. I don't like that solution as at least 99% of the user don't understand how to handle that. For OpenCL we also have the option of running a short test whenever the driver/device changes. That was my original idea for the OpenCL blacklist when it was discussed. Of course we should make sure that if we want we can use the same mechanism for other features as well. Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: review of OpenGL blacklist work
Hey, On Fri, Jun 5, 2015 at 1:59 PM, Thorsten Behrens 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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: review of OpenGL blacklist work
On 05.06.2015 13:59, Thorsten Behrens wrote: > Markus Mohrhard wrote: >> 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. iirc the OpenCL stuff also has some sort of blacklist nowadays, wonder if all of these should use the same sort of mechanism - that would make it easier to admin. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: review of OpenGL blacklist work
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 signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: review of OpenGL blacklist work
Hi, On Fri, Jun 05, 2015 at 05:36:21PM +0800, Matthew J. Francis wrote: > What about setting it up so the blacklist can be packaged > independently of the version of LibreOffice? > > I'm assuming that the format of the data is simple enough that it > should essentially never need to change. You then still need to update it in stable. And what if exactly the version of mesa you *have* to ship with has that bug? Disabling OpenGL in a stable release (read stable as not-changing) when you had it before and it worked in (some) cases? No way... Such auto-update is different for virus definitions or whatever, but... Regards, Rene ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: review of OpenGL blacklist work
Hi, On Fri, Jun 05, 2015 at 04:19:39AM +0200, Markus Mohrhard wrote: >Please note that the automatic update is not yet implemented as I have no >URL on a TDF server yet. > >Is there a need for a similar service on Linux. Mesa is at least as bad as >the Windows OpenGL drivers but I fear that all linux distros would disable >that feature anyway so making it useless. Yes, distros probably will disable the auto-update. As would sysadmins most probably. (Let alone because to make it sane you'd need to update the "real" copy which a) needs root b) changes checksums of installed files=. Regards, Rene ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
review of OpenGL blacklist work
Hey, so as part of my work to integrate glyphy for OpenGL text rendering I finally managed to implement the last missing piece from my earlier blacklist work. Currently we have a blacklist based on the old Mozilla blacklist which has two downsides: 1.) The entries are mostly irrelevant to us (except for the two entries related to my systems). 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). 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, ...). 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. Please note that the automatic update is not yet implemented as I have no URL on a TDF server yet. Is there a need for a similar service on Linux. Mesa is at least as bad as the Windows OpenGL drivers but I fear that all linux distros would disable that feature anyway so making it useless. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
