From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 0/8] Add DRIimage-based DRI3/Present loader Date: Tue, 05 Nov 2013 12:04:32 -0800 Message-ID: <871u2uhay7.fsf@eliezer.anholt.net> References: <1383618208-21310-1-git-send-email-keithp@keithp.com> <8661s6kdjd.fsf@miki.keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1394503619==" Return-path: In-Reply-To: <8661s6kdjd.fsf@miki.keithp.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mesa-dev-bounces@lists.freedesktop.org Errors-To: mesa-dev-bounces@lists.freedesktop.org To: Keith Packard , mesa-dev@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1394503619== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Keith Packard writes: > Keith Packard 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. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSeU9QAAoJELXWKTbR/J7os44P/jw8TgcILTxBFkOPXKquGgkR xfOcmybFjVzmXMaQ7YuTjH+2UzfIwMHntKkvVnVHGTpEaljwqGqNdOdVFjWmRZqC 3j/cHAo/L2nrGYnuBDloVJSc04blHyyc2+rEpTVDI/b0H2qM7K/tiHuTNyPfQ/SU 04MSPjJXtH72/qa+Aoyo3w7oT2ae3cFQHocMLsCUhkfZl97ZoQ4Njyhvjp44pXIv rVVEoCORCiPRHhJTf01ASxgFKZ5gQiV7c2ZCAH9mRYvRL6vtGp/isiAEQefDQd6c JAMzNMwQkVKSgAfsgJto7hRBZrcgB6HVk2rtl4aHEOTp9iGS2UXVI+x+cZVNEMLd 4xRR6xuGe7mKGa2TgflZxaHywTaNKrlrcf2u8KdXasn2F1WgHwSETms6t/p41rTz Xh/ME2Fr/JuLWpnVzDQ6bpC6Od02aa7bH8CWge/U1KsZv63xGK7ochHcwGjD8K9I Zo29ogvFLH+yVI7mFSt4sIATuYu72f1OJ44NJ30ThfOpAMzP4Okf9pT1bmYBPxY9 g43pjTaa0JsbjT0SXIXXEwd+PKRXmpGZPir5tsI2ADG+Pkf6hAPd7vf5wZlMckhJ GCf9A+vyI9yLp6bU1pjZvQ+oPc03SRss7FoQtngJtEl/2i0xjMxFipIWo7yrWysD A4sB2/fX7/0cRL69duxT =N35n -----END PGP SIGNATURE----- --=-=-=-- --===============1394503619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev --===============1394503619==--