On Thu, Feb 28, 2008 at 5:24 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > On Thu, 28 Feb 2008 12:48:55 -0800 > Jesse Barnes <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > > ------------------------------------------------------------------------- > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel >
------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel