commit | aaaa9069a8376c551964835d8aa6ef0c5aa941b6 | [log] [tgz] |
---|---|---|
author | Eric Engestrom <eric.engestrom@imgtec.com> | Fri Mar 16 11:46:24 2018 +0000 |
committer | Eric Engestrom <eric.engestrom@imgtec.com> | Fri Mar 16 11:52:02 2018 +0000 |
tree | 4f57e89412db27d398d0c8f0e3cd51d296578876 | |
parent | 0fa0d37da846998aa838ed2b784a340c28dadff3 [diff] |
Define Wayland native platform types This pushes to Khronos the changes done by Kristian Høgsberg in Mesa commits 04c5cc5b8bec1f34f2405b08fd0d9ed6bd70ea61 "eglplatform.h: Define Wayland native platform types" [1] and c0f8c9911c82c576cdd82dabad4a2370ac53565c "wayland-egl: Update to wayland-egl.h changes, drop struct wl_egl_display" [2]. Note that WL_EGL_PLATFORM is defined by the Wayland EGL implementation, such as the one in the Wayland project [3]. Fixes #42 [1] https://cgit.freedesktop.org/mesa/mesa/commit/?id=04c5cc5b8bec1f34f2405b08fd0d9ed6bd70ea61 [2] https://cgit.freedesktop.org/mesa/mesa/commit/?id=c0f8c9911c82c576cdd82dabad4a2370ac53565c [3] https://cgit.freedesktop.org/wayland/wayland/tree/egl/wayland-egl-core.h#n34
The EGL-Registry repository contains the EGL API and Extension Registry, including specifications, reference pages and reference cards, and the enumerant registry. It is also used as a backing store for the web view of the registry at https://www.khronos.org/registry/egl/ ; commits to the master branch of this repository will be reflected there.
In the past, the EGL registry was maintained in a public Subversion repository. The history in that repository has not been imported to github, but it is still available at https://cvs.khronos.org/svn/repos/registry/trunk/public/egl/ .
Interesting files in this repository include:
EGL enumerants are documented in api/egl.xml . New ranges can be allocated by proposing a pull request to master modifying this file, following the existing examples. Allocate ranges starting at the lowest free values available (search for “Reservable for future use”). Ranges are not officially allocated until your pull request is accepted into master. At that point you can use values from your assigned range for API extensions.
Extension specification documents can be added by proposing a pull request to master, adding the specification .txt file and related changes under extensions/<vendor>/filename.txt. Your pull request must also:
<extension>
examples, search for “Next free extension number”, and use the lowest available extension number).# Validate XML changes make validate # Verify headers build and are legal C make clobber make make tests
Sometimes extension text files contain inappropriate UTF-8 characters. They should be restricted to the ASCII subset of UTF-8 at present. They can be removed using the iconv Linux command-line tool via
iconv -c -f utf-8 -t ascii filename.txt
(see internal Bugzilla issue 16141 for more).
We may transition to an asciidoc-based extension specification format at some point.