Fwd: kernel modesetting progress report....

[Jakob Bornecrantz]

On Thu, Feb 28, 2008 at 2:36 PM, Jerome Glisse <glisse at freedesktop.org> wrote:
 > On Thu, 28 Feb 2008 16:53:46 +1000
 >
 > "Dave Airlie" <airlied at gmail.com> 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.