On windows, spacebar would be passed as UTF-8 text input, despite the
control key being pressed. On macOS, there already was an explicit
exception for this (command key in this case), on Linux XInput already
handled this case for us.
Note that Alt should still allow text input, for special character
sequences.
Issue also happened in the Text Editor if a text data-block was set.
Latest SteamVR OpenXR updates brought OpenGL support, but only with sRGB
buffers. I think for DirectX it's the same now.
It's not a big issue for us to use sRGB buffers, so that's what I will
do for now. That way we shouldn't need hardcoded exceptions for specific
runtimes that don't transform linear buffers correctly.
Steam just released a SteamVR update with OpenXR Developer Preview
support:
https://steamcommunity.com/games/250820/announcements/detail/2396425843528787270.
Once SteamVR is set up for OpenXR (see link above), it works with
Blender "out of the box", thanks to OpenXR!
We have to apply the sRGB transform workaround for SteamVR though,
otherwise it renders way too dark. Done in the next commit.
Note that AMD users may still only see a pink screen, because the
OpenGL-DirectX compatibility fails. I will check on a fix again.
For SteamVR on Linux we may have to wait for until it supports OpenGL
rendering for OpenXR. Alternatively, we *could* add initial Vulkan
support at Ghost level and use Vulkan<->OpenGL interoperability
extensions, Monado uses these as well.
When closing the File Browser window after making it fullscreen, Blender would
either crash or all windows would disappear, with no obvious way to bring them
back.
The "fix" is to not allow fullscreen for File Browsers (or any future "dialog"
windows), but only maximizing. From what I can tell that's how secondary
windows are supposed to work on macOS. What we previously did seemed like
something macOS doesn't handle cleanly, and I didn't find a simple way to do so
on our side.
With the Oculus runtime, the VR session would freeze when taking off the HMD
and putting it back on. This was caused by the deletion of graphics resources
too early in the OpenXR state machine, at least for Oculus.
The resources will now only be freed once the session is actually destroyed.
Also fixes an issue where it wasn't possible to stop the session via the UI
when the HMD was taken off.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D7635
With the Oculus runtime, the VR session would freeze when taking off the HMD
and putting it back on. This was caused by the deletion of graphics resources
too early in the OpenXR state machine, at least for Oculus.
The resources will now only be freed once the session is actually destroyed.
Also fixes an issue where it wasn't possible to stop the session via the UI
when the HMD was taken off.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D7635
Got added in 1a30e52142 (and tweaked in follow-ups) but shouldn't be needed
anymore with the newer popup based quit dialog.
It prevents Blender from quitting properly in case macOS closed all Blender
windows. This may happen in some corner-cases unfortunately (e.g. T74101) which
would be nice to have addressed at some point. Until then, users shouldn't have
to force-kill Blender to shut it down if they run into this.
Changing the order of include changes broke GHOST_DEBUG,
however it was using defines in a fragile way.
Fix by removing 'GHOST_DEBUG' and use 'WITH_GHOST_DEBUG' which
was already defined by CMake.
Usable with the CMake option 'WITH_GHOST_WAYLAND'
The following functionality is working:
- Building with X11 and Wayland at the same time,
wayland is used when available.
- Keyboard, pointer handling.
- Cursor handling.
- Dedicated off-screen windows.
- Drag & drop.
- Copy & paste.
- Pointer grabbing.
See D6567 for further details.