kernel modesetting progress report....
Alex Deucher
alexdeucher at gmail.com
Thu Feb 28 15:21:55 PST 2008
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
>
More information about the xorg
mailing list