kernel modesetting progress report....

[Jesse Barnes]

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?

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

Thanks,
Jesse