[Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader
eric at anholt.net
Tue Nov 5 12:04:32 PST 2013
Keith Packard <keithp at keithp.com> writes:
> Keith Packard <keithp at 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:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the mesa-dev