kernel modesetting progress report....

[Jerome Glisse]

On Thu, 28 Feb 2008 12:48:55 -0800
Jesse Barnes <jbarnes at virtuousgeek.org> wrote:

> On Thursday, February 28, 2008 5:36 am Jerome Glisse wrote:
> > Dave there is one things that is needed to be redone: frame buffer
> > creation & handling. And i would like we not freeze the API until
> > we had some time to play with it a bit. So i guess my question is
> > does this means modesetting API get freezed or not ?
> >
> > For frame buffer create i believe we need some kind of properties
> > system where userspace can ask for driver specific properties at
> > creation time. Also we need a way to allow to query the actual
> > framebuffer properties (ie one asked at creation might not work
> > and driver can adjust them so userspace have to requery properties
> > to know what have been done).
> 
> What kind of properties did you have in mind?  Why aren't the regular BO 
> flags enough?  Were you thinking of fence register allocation for tiled 
> regions or something?

We already discussed about on IRC and maybe mailing list :) but i believe
the outcome is that we don't touch BO. Yet i feel that we need to have
the framebuffer properties (tiling, compression, weird storage format)
in a driver dependant way somewhere along the framebuffer object and that
userspace should be able to query this properties to know (if userspace
clever enough) how to access the framebuffer or simply to properly
format blit command.

> > I also would like the BO argument to become optional ie if none
> > is supplied it's up to the driver to allocate a BO which fit
> > with the asked properties. Corollary frame buffer creation can
> > fail if supplied BO ain't big enough for the asked framebuffer
> > properties.
> 
> Yeah, that should probably -EINVAL.
> 
> > Finaly i am wondering if we should not provide some way to
> > update & get part of the framebuffer this could be especialy
> > usefull in case of dumb userspace which can't understand
> > framebuffer properties and if we ever have hw which can't have
> > linear framebuffer but need to store it in some strange
> > format (maybe embedded device already fall in this category).
> 
> I guess you're thinking of the types of devices that use shadowfb now 
> then upload the finished framebuffer into banked memory or whatever?

Yes to that kind of device, and others that might appear in the future.

Cheers,
Jerome Glisse <glisse at freedesktop.org>