Keith Packard <keithp@xxxxxxxxxx> writes: > Keith Packard <keithp@xxxxxxxxxx> 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:
pgp7tTT3pBsfm.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
