Re: New proposed DRM interface design

[Jon Smirl]

Sure you can use this to get around both fbdev and DRM trying to claim
the resource. But it doesn't help at all to fix the problem that fbdev
and DRM are programming the radeon chip in conflicting ways.

Look at the case of two independent users, one logged into each head.
One is running DRI and one fbdev. On every process swap I am going to
have to save graphics state, stop the coprocessor, flush the drawing
queue, etc because fbdev runs the chip in 2D mode and DRM runs it in
3D. It may take longer than a timeslice to flush the graphics queue. 
In a coordinated driver world I can leave the chip in 3D mode and
processes swap without overhead. The coordinated driver can also
manage allocating the VRAM between users.

How is multihead mode setting going to work with separate drivers? Set
head #1 using fbdev and head #2 using DRM? I can't imagine how merged
fb will work in that model. Or am I supposed to teach existing fbdev
how to do merged fb?

Some of the fbdev drivers are starting to attempt acceleration using
3D mode. This is going to be a complete mess when swapping to DRM.

What is so awful about merging the code? I'm the one doing the all of
the work. I intend to use 95% of the code extracted from fbdev without
change. I'm not getting rid of fbdev capability in the merged code,
I'm just coordinating use of the hardware.

On Sun, 05 Sep 2004 16:31:15 +0100, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> The only glue structure you need for most of this is
> 
> struct fb_device
> {
>         struct fb_info *fb;     /* NULL or frame buffer device */
>         struct dri_whatever *dri;  /* As yet not nicely extracted DRI
>                                         object */
>         atomic_t refcnt;
>         void *private
> };
> 
> Right now the drvdata for most PCI/AGP frame buffers is set to the
> fb_info. If that is set to the shared object then you can attach DRI and
> or FB first and they can find and call each others methods.
> 
> It might also need a single lock just to avoid DRI deciding to go away
> while fb is calling dri and the reverse although I think the refcnt is
> easier and cheaper.
> 
> With that in place if X tells DRI "640x480 starting here" then DRI can
> tell fb "640x480 starting here". Similarly fb and dri can find each
> other for acceleration and the kernel can become a DRI client for
> console acceleration.
> 
> Once you have this object you can start attaching memory managers and
> mode setup pointers to the shared structure so that they live
> independantly.
> 
> 



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/