Re: [PATCH 0/8] Add DRIimage-based DRI3/Present loader

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1.1: Type: text/plain, Size: 1755 bytes --]

Keith Packard <keithp@keithp.com> writes:

> Keith Packard <keithp@keithp.com> writes:
>
>> This sequence first adds a a couple of new DRIimage extensions to the
>> dri/common, dri/i915 and dri/i965 directories which define a
>> loader-independent API for managing window system operations.
>>
>> The last patch adds a new DRI3000 loader using those new interfaces.
>
> I've figured out that I can also re-use dri2CreateNewScreen2 for the
> image driver bits, as long as I change that function to also look up the
> image loader. That means there are *no* new dri_util functions needed.
>
> To recap, the changes needed to support using the DRIimageExtension
> interfaces for allocating buffers from the driver in the loader are:
>
>     DRIimageDriverExtension
>
>         A proper subset of DRIdri2DriverExtension, which uses
>         the same five functions involved in creating new objects:
>
>            /* Common DRI functions, shared with DRI2 */
>            __DRIcreateNewScreen2        createNewScreen2;
>            __DRIcreateNewDrawable       createNewDrawable;
>            __DRIcreateNewContext        createNewContext;
>            __DRIcreateContextAttribs    createContextAttribs;
>            __DRIgetAPIMask              getAPIMask;

It seems like we could just stick these things in __DRI_CORE as opposed
to having another new extension to look up.  The downside I see there is
bugs in the server, which have patches at xserver-driinterface-versions
of my tree.  (Unfortunately, I'm having a hard time building the server
currently, so no testing yet).  Having a new extension whose name has
nothing to do with the functions in it seems really weird.

Also, apologies for not having done this myself for my CreateNewScreen2
change.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev