Vulkan-Docs/doc/specs/vulkan/appendices/VK_EXT_acquire_xlib_display.txt
Jon Leech df88ded281 Change log for September 5, 2017 Vulkan 1.0.60 spec update:
* Bump API patch number and header version number to 60 for this update.

Github Issues:

  * Document that <<queries-timestamps, Timestamp Queries>> can only be
    meaningfully compared when they are written from the same queue (public
    issue 216).
  * Document that the `<extension>` tag `type` attribute is required for
    non-disabled extensions (derived from, but does not close public issue
    354).
  * Clean up registry schema length attribute descriptions to be consistent
    and correct (public issue 555).

Internal Issues:

  * Replace as much of the hand-written extension appendix metadata as
    possible with asciidoc includes generated from corresponding attributes
    of +vk.xml+, and enhance the style guide to match. This avoids
    inconsistencies between +vk.xml+ and the appendices, and produces a more
    uniform style (internal issue 137).
  * Remove the generated extDependency.{py,sh} files from the tree and
    create them dynamically on demand instead, reducing merge conflicts
    (internal issue 713).
  * Add a prototype tool for generating in-place difference markup for
    sections guarded by asciidoc conditionals, and new syntax for open
    blocks to support it (internal issue 833).
  * Remove unnecessary restriction of etext:*SYNC_FD_BIT_KHR external handle
    types to the same physical device in the
    slink:VkPhysicalDeviceIDPropertiesKHR,
    flink:VkImportMemoryWin32HandleInfoKHR,
    slink:VkImportFenceWin32HandleInfoKHR, slink:VkImportFenceFdInfoKHR,
    slink:VkImportSemaphoreWin32HandleInfoKHR,
    slink:VkImportSemaphoreFdInfoKHR
    <<external-memory-handle-types-compatibility, External memory handle
    types compatibility>>, <<external-semaphore-handle-types-compatibility,
    External semaphore handle types compatibility>>, and
    <<external-fence-handle-types-compatibility, External fence handle types
    compatibility>> sections (internal issue 956).

Other Issues:

  * Remove dependency of +VK_KHX_device_group+ on +VK_KHR_swapchain+ (there
    is an interaction, but not a strict dependency), and add a new
    `extension` attribute to the `<require` XML tag to allow classifying a
    subset of interfaces of an extension as requiring another extension.
    Update the registry schema and documentation accordingly.

New Extensions:

  * `VK_AMD_shader_fragment_mask` (and related `GL_AMD_shader_fragment_mask`
    GLSL extension)
  * `VK_EXT_sample_locations`
  * `VK_EXT_validation_cache`
2017-09-04 03:06:55 -07:00

66 lines
1.7 KiB
Plaintext

include::meta/VK_EXT_acquire_xlib_display.txt[]
*Last Modified Date*::
2016-12-13
*IP Status*::
No known IP claims.
*Contributors*::
- Dave Airlie, Red Hat
- Pierre Boudier, NVIDIA
- James Jones, NVIDIA
- Damien Leone, NVIDIA
- Pierre-Loup Griffais, Valve
- Liam Middlebrook, NVIDIA
- Daniel Vetter, Intel
This extension allows an application to take exclusive control on a display
currently associated with an X11 screen.
When control is acquired, the display will be deassociated from the X11
screen until control is released or the specified display connection is
closed.
Essentially, the X11 screen will behave as if the monitor has been unplugged
until control is released.
=== New Enum Constants
None.
=== New Enums
None.
=== New Structures
None.
=== New Functions
* flink:vkAcquireXlibDisplayEXT
* flink:vkGetRandROutputDisplayEXT
=== Issues
1) Should flink:vkAcquireXlibDisplayEXT take an RandR display ID, or a
Vulkan display handle as input?
*RESOLVED*: A Vulkan display handle.
Otherwise there would be no way to specify handles to displays that had been
"`blacklisted`" or prevented from being included in the X11 display list by
some native platform or vendor-specific mechanism.
2) How does an application figure out which RandR display corresponds to a
Vulkan display?
*RESOLVED*: A new function, flink:vkGetRandROutputDisplayEXT, is introduced
for this purpose.
3) Should flink:vkGetRandROutputDisplayEXT be part of this extension, or a
general Vulkan + RandR or Vulkan + Xlib extension?
*RESOLVED*: To avoid yet another extension, include it in this extension.
=== Version History
* Revision 1, 2016-12-13 (James Jones)
- Initial draft