Modulevulkan-3.27GHC2021

Vulkan.Extensions.VK_EXT_acquire_xlib_display

Name

VK_EXT_acquire_xlib_display - instance extension

VK_EXT_acquire_xlib_display

Name String: VK_EXT_acquire_xlib_display

Extension Type

Instance extension

Registered Extension Number

Revision

Ratification Status

Ratified

Extension and Version Dependencies

VK_EXT_direct_mode_display

Contact

James Jones @cubanismo%0A*Here describe the issue or question you have about the VK_EXT_acquire_xlib_display extension*

Other Extension Metadata

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

Description

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 Commands

acquireXlibDisplayEXT

getRandROutputDisplayEXT

New Enum Constants

EXT_ACQUIRE_XLIB_DISPLAY_EXTENSION_NAME

EXT_ACQUIRE_XLIB_DISPLAY_SPEC_VERSION

Issues

1) Should acquireXlibDisplayEXT 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 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, getRandROutputDisplayEXT, is introduced for this purpose.

3) Should getRandROutputDisplayEXT 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

Document Notes

For more information, see the Vulkan Specification.

This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.

5 types
2 values

Packagevulkan-3.27
Exports9
LanguageGHC2021
LicenceBSD-3-Clause
SourceVK_EXT_acquire_xlib_display.hs

valueacquireXlibDisplayEXT

:: MonadIO io
=> PhysicalDevice
physicalDevice The physical device the display is on.
physicalDevice must be a valid PhysicalDevice handle
-> "dpy" ::: Ptr Display
dpy A connection to the X11 server that currently owns display.
dpy must be a valid pointer to a Display value
-> DisplayKHR
display The display the caller wishes to control in Vulkan.
display must be a valid DisplayKHR handle
display must have been created, allocated, or retrieved from physicalDevice
-> io ()

vkAcquireXlibDisplayEXT - Acquire access to a VkDisplayKHR using Xlib

Description

All permissions necessary to control the display are granted to the Vulkan instance associated with physicalDevice until the display is released or the X11 connection specified by dpy is terminated. Permission to access the display may be temporarily revoked during periods when the X11 server from which control was acquired itself loses access to display. During such periods, operations which require access to the display must fail with an appropriate error code. If the X11 server associated with dpy does not own display, or if permission to access it has already been acquired by another entity, the call must return the error code ERROR_INITIALIZATION_FAILED.

One example of when an X11 server loses access to a display is when it loses ownership of its virtual terminal.