On Thu, Feb 28, 2008 at 2:36 PM, Jerome Glisse <[EMAIL PROTECTED]> wrote: > On Thu, 28 Feb 2008 16:53:46 +1000 > > "Dave Airlie" <[EMAIL PROTECTED]> wrote: > > > > So just to let people know where kernel modesetting is getting to and > > what I'm up to with it.. > > > > So I really want to ship something in Fedora 9 with kernel modesetting > > in it, whether this is a default or a special boot option for the user > > I won't decide for a while. > > > > But with this in mind I've checked in bunch of changes to the > > modesetting drm to make modesetting optional for i915, you now load > > the i915 module with modeset=1 to enable it. > > I've also created an intel-kernelmode branch which is based on the > > intel-batchbuffer branch, with fairly clean modesetting integration. > > It still needs work to fixup a few features but I'm going to work my > > way through the list. > > (it needs fixes for rotation + video at the moment) > > > > The DDX driver can detect whether modesetting is enabled in the drm > > and does the right thing for each case. > > > > I checked a patch into the server to allow the crtc callback to work, > > I think this breaks ABI with xf86Crtc.c users, need to confirm what > > the proper action for this is. > > > > Dave. > > 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).
I'm guessing a flag system could be used, sorta like the BO flags. There are some things to consider: should we allow driver dependant flags on it or should those be exposed in a driver specific ioctl. Also do we want a offset property? So we can have two framebuffers in one buffer or just not the start of it. > 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. It sounds like its just a convenience. If the driver creates it who owns it? There is also the question of reference on the buffer? Does the driver up the reference if it creates it? > 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). Dumb userspace shouldn't be able to create tiled or none linear framebuffers, so its not realy a problem. I'm sure there are some crazy hardware which doesn't support linear framebuffers rgb buffers, the GameCube/Wii being one(two) of them. This is the dreaded acceleration api in kernel that nobody wants but everybody does anyways. What I mean by that is that all drivers has a function to speed up clearing memory regions and copy memory between vram and agp, it takes very little work to make those general for fill and copy. > Oh and modesetting can refuse to set mode if supplied framebuffer > don't fit conditions. I'm pretty sure the code does this now. > Cheers, > Jerome Glisse Cheers Jakob. PS: Sorry Jerome, silly gmail doesn't reply to all per default. ------------------------------------------------------------------------- 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
