[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: ideas to potentially share some effort
From:       Benoit Jacob <jacob.benoit.1 () gmail ! com>
Date:       2010-12-16 0:06:32
Message-ID: AANLkTi=16Dajend58PiQxU=pc0sdBpdCiSyqXdoNm5z1 () mail ! gmail ! com
[Download RAW message or body]

2010/12/14 Martin Gräßlin <kde@martin-graesslin.com>:
> 
> ----- Ursprüngliche Mitteilung -----
> > Hi Martin,
> > Thanks for the answers,
> > 
> > 2010/12/14 Martin Gräßlin <kde@martin-graesslin.com>:
> > > > 1. What I'd like to get from you
> > > > 
> > > > Do you have a good device / driver blacklist/whitelist ?
> > > No we don't have a blacklist or 4.5 would not have been so painful. We
> > > nowadays have a platform detection [1] which could be of help for you.
> > 
> > Thanks, but it seems that you're getting the graphics card info from
> > glGetString which requires to have a OpenGL context in the first
> > place. In our experience, crashy drivers may crash already when
> > creating a OpenGL context, so we need to find another way. I think we
> > can query X directly for that.
> Yes, a real pain. KWin detects crashes while getting the GLContext and will not \
> allow to activate compositing again. That's something that could work for you too.

Unfortunately, we can't even afford to say that it's OK to crash once,
for security reasons that I explain below:

> > 
> > > > We're
> > > > currently not enabling hardware acceleration by default in Firefox 4
> > > > on X11 because we're scared of the status of drivers (and being a
> > > > browser, we shouldn't risk crashing).
> > > I'd recommend to just enable it by default. The crashes and problems
> > > in the driver stack will never get fixed if apps don't demand the
> > > functionality. Firefox 4 will go into the next distro round which will
> > > require more OpenGL functionality. Both GNOME Shell and Unity depend
> > > on OpenGL. So at least Ubuntu and Fedora will need it. In general it's
> > > not your problem at all. It's the task of the distribution to bundle
> > > the software in a way that it works. They have to ensure that the
> > > drivers are not broken!
> > 
> > Unfortunately, we have to be much more conservative than that, for at
> > least three reasons:
> > - our users are non-technical and value 'just works' above new features
> Well it's the same for us and we have activated GL by default two years ago.

Maybe then it's just that we hit a lot more bugs in GL implementations
than you do, see explanation below about WebGL:

> > - driver bugs may include security issues.
> Same for us. I always wanted to exploit the X crashes...
> > - browsers actually turn crashes into DOS security issues (if e.g. JS
> > may trigger the crash).
> Very unlikely to happen.

So let me explain. We're implementing support for a new web technology
called WebGL. In short, it's OpenGL ES bindings for Javascript. In
practice, that means that malicious Javascript can execute OpenGL
calls specially tailored to trigger/exploit a given driver bug. This
is why:
 1) the security aspect is much more critical in our case
 2) potentially every driver bug can be triggered by javascript.

That's why we need to be super conservative about enabling this kind
of features.

Cheers,
Benoit


> > 
> > > > Having a good
> > > > blacklist/whitelist would allow us to turn opengl features on at
> > > > least certain X11 setups.
> > > If you want to go the easy way, enable for NVIDIA, disable for
> > > anything else. Though that's not nice from an OpenSource developer
> > > point of view.
> > 
> > That's what I was afraid of. Yes, the NVIDIA proprietary driver works
> > for us. I guess that's better than nothing.
> > 
> > Cheers,
> > Benoit
> > _______________________________________________
> > kwin mailing list
> > kwin@kde.org
> > https://mail.kde.org/mailman/listinfo/kwin
> 
> _______________________________________________
> kwin mailing list
> kwin@kde.org
> https://mail.kde.org/mailman/listinfo/kwin
> 
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]