On Sunday, September 5, 2004 8:31 am, Alan Cox 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.
So then this structure would represent a merged driver? That is, you'd have a
driver that attaches to display devices and creates this structure to manage
fb and dri?
Jesse
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
