[Mesa-dev] [PATCH mesa 2/7] docs/specs: remove upstreamed spec MESA_image_dma_buf_export

[Eric Engestrom]

Spec is now available on Khronos:
https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_image_dma_buf_export.txt

Signed-off-by: Eric Engestrom <eric.engestrom at imgtec.com>
---
 docs/specs/MESA_image_dma_buf_export.txt | 147 -------------------------------
 1 file changed, 147 deletions(-)
 delete mode 100644 docs/specs/MESA_image_dma_buf_export.txt

diff --git a/docs/specs/MESA_image_dma_buf_export.txt b/docs/specs/MESA_image_dma_buf_export.txt
deleted file mode 100644
index cc9497e437d449a56abc..00000000000000000000
--- a/docs/specs/MESA_image_dma_buf_export.txt
+++ /dev/null
@@ -1,147 +0,0 @@
-Name
-
-    MESA_image_dma_buf_export
-
-Name Strings
-
-    EGL_MESA_image_dma_buf_export
-
-Contributors
-
-    Dave Airlie
-
-Contact
-
-    Dave Airlie (airlied 'at' redhat 'dot' com)
-
-Status
-
-    Complete, shipping.
-
-Version
-
-    Version 3, May 5, 2015
-
-Number
-
-    EGL Extension #87
-
-Dependencies
-
-    Requires EGL 1.4 or later.  This extension is written against the
-    wording of the EGL 1.4 specification.
-
-    EGL_KHR_base_image is required.
-
-    The EGL implementation must be running on a Linux kernel supporting the
-    dma_buf buffer sharing mechanism.
-
-Overview
-
-    This extension provides entry points for integrating EGLImage with the
-    dma-buf infrastructure.  The extension allows creating a Linux dma_buf
-    file descriptor or multiple file descriptors, in the case of multi-plane
-    YUV image, from an EGLImage.
-
-    It is designed to provide the complementary functionality to
-    EGL_EXT_image_dma_buf_import.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Types
-
-    This extension uses the 64-bit unsigned integer type EGLuint64KHR
-    first introduced by the EGL_KHR_stream extension, but does not
-    depend on that extension. The typedef may be reproduced separately
-    for this extension, if not already present in eglext.h.
-
-    typedef khronos_uint64_t EGLuint64KHR;
-
-New Procedures and Functions
-
-    EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
-                                  EGLImageKHR image,
-				  int *fourcc,
-				  int *num_planes,
-				  EGLuint64KHR *modifiers);
-
-    EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
-                                        EGLImageKHR image,
-                                        int *fds,
-				        EGLint *strides,
-					EGLint *offsets);
-
-New Tokens
-
-    None
-
-
-Additions to the EGL 1.4 Specification:
-
-    To mirror the import extension, this extension attempts to return
-    enough information to enable an exported dma-buf to be imported
-    via eglCreateImageKHR and EGL_LINUX_DMA_BUF_EXT token.
-
-    Retrieving the information is a two step process, so two APIs
-    are required.
-
-    The first entrypoint
-       EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy,
-                                  EGLImageKHR image,
-				  int *fourcc,
-				  int *num_planes,
-				  EGLuint64KHR *modifiers);
-
-    is used to retrieve the pixel format of the buffer, as specified by
-    drm_fourcc.h, the number of planes in the image and the Linux
-    drm modifiers. <fourcc>, <num_planes> and <modifiers> may be NULL,
-    in which case no value is retrieved.
-
-    The second entrypoint retrieves the dma_buf file descriptors,
-    strides and offsets for the image. The caller should pass
-    arrays sized according to the num_planes values retrieved previously.
-    Passing arrays of the wrong size will have undefined results.
-    If the number of fds is less than the number of planes, then
-    subsequent fd slots should contain -1.
-
-        EGLBoolean eglExportDMABUFImageMESA(EGLDisplay dpy,
-                                         EGLImageKHR image,
-					 int *fds,
-                                         EGLint *strides,
-                                         EGLint *offsets);
-
-    <fds>, <strides>, <offsets> can be NULL if the infomatation isn't
-    required by the caller.
-
-Issues
-
-1. Should the API look more like an attribute getting API?
-
-ANSWER: No, from a user interface pov, having to iterate across calling
-the API up to 12 times using attribs seems like the wrong solution.
-
-2. Should the API take a plane and just get the fd/stride/offset for that
-   plane?
-
-ANSWER: UNKNOWN,this might be just as valid an API.
-
-3. Does ownership of the file descriptor remain with the app?
-
-ANSWER: Yes, the app is responsible for closing any fds retrieved.
-
-4. If number of planes and number of fds differ what should we do?
-
-ANSWER: Return -1 for the secondary slots, as this avoids having
-to dup the fd extra times to make the interface sane.
-
-Revision History
-
-    Version 3, May, 2015
-        Just use the KHR 64-bit type.
-    Version 2, March, 2015
-        Add a query interface (Dave Airlie)
-    Version 1, June 3, 2014
-        Initial draft (Dave Airlie)
-
-- 
Cheers,
  Eric