Right now scale games by default to 720p even if the screen is 1080p.
This happens when -w/-h is *not* specified.
Instead, don't scale the game by default. This means using a 720p
window when nested (shouldn't change anything), and using the screen's
resolution when embedded.
Tested with radv + radeonsi + glxgears on navi21 to work with DCC (assuming
the nodcc bit is disabled).
This is conservative and will fall back to the legacy path if the modifier
isn't supported. At the same time it also avoids the wird mesa WSI struct
if the modifier is supported.
This avoids needlessly creating buffers for an headless output we won't
use, and will allow us to more easily replace the headless backend with
a custom renderer in the future.
Instead of handling both cases in a single function, split the work of
populating the atomic request in two new functions, and keep the common
bits in drm_prepare.
Shouldn't have any functional change.
drm_can_avoid_composite doesn't merely checks whether we can avoid
composition: it also prepares a pending atomic request. It's always
necessary to call this function before drm_atomic_commit.
Rename the function to make this clearer.
Before the window is mapped, the client can set the initial NET_WM_STATE
directly in the window property. After the window is mapped, the client
must use a client message and shouldn't touch the property anymore.
Sometimes we hide our window and show it again after some time.
SDL_SetRelativeMouseMode doesn't seem to properly cope with this, at
least on my setup.
VUID-VkSwapchainCreateInfoKHR-surface-01270(ERROR / SPEC): msgNum: -1585220531 - Validation Error: [ VUID-VkSwapchainCreateInfoKHR-surface-01270 ] Object 0: handle = 0x628000040100, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xa183744d | vkCreateSwapchainKHR(): pCreateInfo->surface is not known at this time to be supported for presentation by this device. The vkGetPhysicalDeviceSurfaceSupportKHR() must be called beforehand, and it must return VK_TRUE support with this surface for at least one queue family of this device. The Vulkan spec states: surface must be a surface that is supported by the device as determined using vkGetPhysicalDeviceSurfaceSupportKHR (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-VkSwapchainCreateInfoKHR-surface-01270)
VUID-vkCreateInstance-ppEnabledExtensionNames-01388(ERROR / SPEC): msgNum: -437968512 - Validation Error: [ VUID-vkCreateInstance-ppEnabledExtensionNames-01388 ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0xe5e52180 | Missing extension required by the instance extension VK_KHR_external_memory_capabilities: VK_KHR_get_physical_device_properties2. The Vulkan spec states: All required extensions for each extension in the VkInstanceCreateInfo::ppEnabledExtensionNames list must also be present in that list (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkCreateInstance-ppEnabledExtensionNames-01388)
In file included from ../src/steamcompmgr.cpp:74:
src/steamcompmgr.hpp:75:7: warning: private field 'm_hasPlane' is not used [-Wunused-private-field]
bool m_hasPlane;
^
src/steamcompmgr.cpp: In function 'void statsThreadMain()':
src/steamcompmgr.cpp:357:62: error: 'O_WRONLY' was not declared in this scope
357 | statsPipeFD = open( statsThreadPath.c_str(), O_WRONLY );
| ^~~~~~~~
src/steamcompmgr.cpp:357:31: error: 'open' was not declared in this scope; did you mean 'popen'?
357 | statsPipeFD = open( statsThreadPath.c_str(), O_WRONLY );
| ^~~~
| popen
src/steamcompmgr.cpp: In function 'void steamcompmgr_main(int, char**)':
src/steamcompmgr.cpp:2559:61: error: 'O_WRONLY' was not declared in this scope
2559 | readyPipeFD = open( optarg, O_WRONLY );
| ^~~~~~~~
src/steamcompmgr.cpp:2559:47: error: 'open' was not declared in this scope; did you mean 'popen'?
2559 | readyPipeFD = open( optarg, O_WRONLY );
| ^~~~
| popen
Should let people run against Intel and other non-AMD Mesa GPUs.
Also force compute+graphics if vkBasalt is enabled, as it won't support
compute-only rings. Also always composite if vkBasalt is enabled, so it
applies always in embedded.
Calling nice() in the very beginning ensures that Mesa worker threads in
gamescope and Xwayland can properly reduce their priority without us stomping
it later.
Move away from posix_spawn, since there's no easy way (that seems to work)
to keep priority normal for the spawned process and get the right behaviour
for gamescope and Xwayland.
The intermediate fork() lets us simplify the logic for LD_PRELOAD rewriting.
Avoid setting it for our children processes, by spawning them in a new
thread group and setting group-wide priority, which also conveniently
gets Xwayland.
