Fwd: kernel modesetting progress report....

[Jerome Glisse]

On Thu, 28 Feb 2008 19:12:07 +0100
"Jakob Bornecrantz" <wallbraker at gmail.com> wrote:

> 
>  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 fear that flag system might be to limited for future case we might
have. I would rather have driver specific properites how we do it is
still open question but it needs to be supplied at framebuffer creation
(well at least this what makes more sense to me).
 
> 
>  >  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?

I was thinking to that just for having an easier userspace as the
create framebuffer should check bo size it will have the code necessary
to compute this size.
 
>  >  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.

I am thinking to device which can't have linear framebuffer.
 
>  >  Oh and modesetting can refuse to set mode if supplied framebuffer
>  >  don't fit conditions.
> 
>  I'm pretty sure the code does this now.

Once we have properties like tiling there might be new case where we
should refuse framebuffer (for instance on radeon tiling can't be
activated with some video mode).
 
Cheers,
Jerome Glisse <glisse at freedesktop.org>