You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way that vkcube is structured today, the choice to use VK_KHR_display to drive a direct-to-display is a cmake option when configuring the build.
if(UNIX AND NOT APPLE) # i.e. Linux
...
set(CUBE_WSI_SELECTION "XCB" CACHE STRING "Select WSI target for vkcube (XCB, XLIB, WAYLAND, DISPLAY)")
This means a separate vkcube binary is required in order to test VK_KHR_display.
It would be better if the choice between windowing system swapchain and VK_KHR_display swapchain was controlled by a runtime switch specified on the command line. This issue requests that the choice of DISPLAY be moved to a command line switch.
Extrapolating, the choice between XCB and XLIB and WAYLAND could also become command-line options; however I am not requesting such a change in this issue. If there is desire to go this extra distance then it can be done in the context of a different gitlab issue.
Further, by placing the DISPLAY support inside of a check for UNIX, this precludes ever exposing VK_KHR_display on Windows or on any other non-UNIX platform. That is short-sighted. A better software architecture would structure the code such that support for DISPLAY is independent of the windowing system choice.
The text was updated successfully, but these errors were encountered:
The way that vkcube is structured today, the choice to use
VK_KHR_display
to drive a direct-to-display is a cmake option when configuring the build.This means a separate vkcube binary is required in order to test
VK_KHR_display
.It would be better if the choice between windowing system swapchain and
VK_KHR_display
swapchain was controlled by a runtime switch specified on the command line. This issue requests that the choice of DISPLAY be moved to a command line switch.Extrapolating, the choice between XCB and XLIB and WAYLAND could also become command-line options; however I am not requesting such a change in this issue. If there is desire to go this extra distance then it can be done in the context of a different gitlab issue.
Further, by placing the DISPLAY support inside of a check for UNIX, this precludes ever exposing VK_KHR_display on Windows or on any other non-UNIX platform. That is short-sighted. A better software architecture would structure the code such that support for DISPLAY is independent of the windowing system choice.
The text was updated successfully, but these errors were encountered: