kernel modesetting progress report....

[Alex Deucher]

On Thu, Feb 28, 2008 at 5:24 PM, Jerome Glisse <glisse at freedesktop.org> wrote:
> 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>
>
>
>
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  --
>  _______________________________________________
>  Dri-devel mailing list
>  Dri-devel at lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/dri-devel
>