Mode setting & EGL

Benjamin Herrenschmidt benh at kernel.crashing.org
Tue Mar 15 20:35:47 PST 2005


On Tue, 2005-03-15 at 23:07 -0500, Adam Jackson wrote:
> On Tuesday 15 March 2005 22:32, Benjamin Herrenschmidt wrote:
> > Hi !
> >
> > I just subscribed to the list and in the middle of reading the archives.
> > Just a few quick commentes/notes about the mode setting stuff from what
> > I've read. Maybe just stuffs I've overlooked though, I haven't had time
> > to read the EGL spec yet.
> >
> >  - Mode setting has an impact on data cached in fb memory. It can be
> > (and will be) destructive. See the (long) thread going on on x.org &
> > fbdev lists for details.
> >
> >  - Ideally, mode setting should be implemented in a separate library on
> > top of fbdev ioctl's and drm, and EGL using that library, no ?
> 
> Correct, for the DRI drivers at least.  We want EGL to have a consistent way 
> to specify a screen surface's attributes, from the _application_'s 
> perspective.  The EGL implementation is just going to turn around and hand 
> the request to the userspace driver component anyway.  So the issue is making 
> sure that the interface provided by this notional libmodeset is sufficient 
> for what an EGL app wants to do.

Which is why I suggest we design both at the same time...
 
> I really don't care _how_ the fbdev layer implements all this.  I just want 
> enough feedback to know if a certain attribute is absolutely not possible to 
> expose, so we don't write something unimplementable into the extension spec.  
> If the card can't tell me which monitor is painted pink and which one is 
> painted green, then we need to not let applications select mode based on 
> monitor paint scheme.

Agreed, the implementation details are irrelevant, except when
implementation issues limit what the API can do (like the problems I
described with locking issues, offscreen memory context (loss of
textures) etc...). Can all of that be hidden behind the EGL API ?

Ben.




More information about the dri-egl mailing list