mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-26 04:55:12 +00:00
5abf83f95d
* Update release number to 107.
Public Issues:
* Fix revision date for the `<<VK_AMD_gpu_shader_half_float>>` appendix
(public issue 617).
* Make <<synchronization-pipeline-barriers-subpass-self-dependencies,
subpass self-dependencies>> less restrictive (public issue 777).
* Fix the `<<VK_EXT_full_screen_exclusive>>` dependency on
`<<VK_KHR_win32_surface>>` in `vk.xml` (public pull request 849).
* Remove single-page (`apispec.html`) refpage sub-targets from the
Makefile `allman` target and the build instructions. The target is still
present in the Makefile, but we have not been actively maintaining the
single-page document and do not promise it will work. The full
Specification and the individual API reference pages are what we support
and publish at present (public issue 949).
Internal Issues:
* De-duplicate common valid usage statements shared by multiple commands
or structures by using asciidoctor includes and dynamically assigning
part of the valid usage ID based on which command or structure they're
being applied to (internal issue 779).
* Add reference pages for constructs not part of the formal API, such as
platform calling convention macros, and script changes supporting them
This required suppressing some check_spec_links warning classes in order
to pass CI, until a more sophisticated fix can be done (internal issue
888).
* Change math notation for the elink:VkPrimitiveTopology descriptions to
use short forms `v` and `p` instead of `vertex` and `primitive`,
increasing legibility (internal issue 1611).
* Rewrite generated file includes relative to a globally specified path,
fixing some issues with refpage generation (internal issue 1630).
* Update contributor list for `<<VK_EXT_calibrated_timestamps>>`.
* Fix use of pathlin in `scripts/generator.py` so the script will work on
Windows under Python 3.5 (internal merge request 3107).
* Add missing conditionals around the
<<descriptorsets-accelerationstructure, Acceleration Structure>>
section (internal merge request 3108).
* More script synchronization with OpenXR spec repository (internal merge
request 3109).
* Mark the `<<VK_AMD_gpu_shader_half_float>>` and
`<<VK_AMD_gpu_shader_int16>>` extensions as deprecated in `vk.xml` and
the corresponding extension appendices (internal merge request 3112).
New Extensions:
* `<<VK_EXT_headless_surface>>`
60 lines
2.3 KiB
Plaintext
60 lines
2.3 KiB
Plaintext
[open,refpage='vkAcquireXlibDisplayEXT',desc='Acquire access to a VkDisplayKHR using Xlib',type='protos']
|
|
--
|
|
|
|
To acquire permission to directly access a display in Vulkan from an X11
|
|
server, call:
|
|
|
|
include::{generated}/api/protos/vkAcquireXlibDisplayEXT.txt[]
|
|
|
|
* pname:physicalDevice The physical device the display is on.
|
|
* pname:dpy A connection to the X11 server that currently owns
|
|
pname:display.
|
|
* pname:display The display the caller wishes to control in Vulkan.
|
|
|
|
All permissions necessary to control the display are granted to the Vulkan
|
|
instance associated with pname:physicalDevice until the display is released
|
|
or the X11 connection specified by pname:dpy is terminated.
|
|
Permission to access the display may: be temporarily revoked during periods
|
|
when the X11 server from which control was acquired itself looses access to
|
|
pname:display.
|
|
During such periods, operations which require access to the display must:
|
|
fail with an approriate error code.
|
|
If the X11 server associated with pname:dpy does not own pname:display, or
|
|
if permission to access it has already been acquired by another entity, the
|
|
call must: return the error code ename:VK_ERROR_INITIALIZATION_FAILED.
|
|
|
|
[NOTE]
|
|
.Note
|
|
====
|
|
One example of when an X11 server loses access to a display is when it loses
|
|
ownership of its virtual terminal.
|
|
====
|
|
|
|
include::{generated}/validity/protos/vkAcquireXlibDisplayEXT.txt[]
|
|
--
|
|
|
|
[open,refpage='vkGetRandROutputDisplayEXT',desc='Query the VkDisplayKHR corresponding to an X11 RandR Output',type='protos']
|
|
--
|
|
|
|
When acquiring displays from an X11 server, an application may also wish to
|
|
enumerate and identify them using a native handle rather than a
|
|
sname:VkDisplayKHR handle.
|
|
To determine the sname:VkDisplayKHR handle corresponding to an X11 RandR
|
|
Output, call:
|
|
|
|
include::{generated}/api/protos/vkGetRandROutputDisplayEXT.txt[]
|
|
|
|
* pname:physicalDevice The physical device to query the display handle on.
|
|
* pname:dpy A connection to the X11 server from which pname:rrOutput was
|
|
queried.
|
|
* pname:rrOutput An X11 RandR output ID.
|
|
* pname:pDisplay The corresponding slink:VkDisplayKHR handle will be
|
|
returned here.
|
|
|
|
If there is no slink:VkDisplayKHR corresponding to pname:rrOutput on
|
|
pname:physicalDevice, dlink:VK_NULL_HANDLE must: be returned in
|
|
pname:pDisplay.
|
|
|
|
include::{generated}/validity/protos/vkGetRandROutputDisplayEXT.txt[]
|
|
--
|