As Wayland doesn't support moving the cursor, draw a cross-hair cursor
at the location used by Blender.
Without this, the cursor was locked at the location where grab started,
making some actions unusable since the cursor location was invisible.
Resolves T77311.
Grab which didn't wrap would lock the cursor, making actions such
as resizing areas lock the cursor in-place.
Confine the cursor to the window instead.
This behavior was also used for X11 when grabbing the cursor was first
supported but could lock the system if Blender froze while grabbing so
it was disabled [0].
For Wayland this shouldn't be a problem as compositors implement grab
in a way that prevents the client from locking the system.
[0]: 3e3d2b7a4c
Shifted flag for buttons changed was incorrectly compared with
unshifted packet flag to determine button press state.
Also fix button tracking storage; button flags are 32 bits whereas the
member variable was 8.
Differential Revision: https://developer.blender.org/D14915
Since [0], using the view navigation gizmo crashed with Wayland.
This only worked previously because GHOST_kGrabWrap was ignored.
Now the previous grab state is disabled before switching to a new
grab state.
[0]: da9e14b0b9
Dragging number buttons wasn't grabbing the cursor and would stop
when the pointer reached the screen edge & wasn't setting the cursor
visible on completion.
Check that lParam is non-NULL in WM_SETTINGCHANGE message handler.
See D14867 for details.
Differential Revision: https://developer.blender.org/D14867
Reviewed by Jesse Yurkovich
Blender will respect Windows "Dark Mode" setting for title bar color.
See D14847 for details.
Differential Revision: https://developer.blender.org/D14847
Reviewed by Ray Molenkamp
When creating a new window from a duplicated area - by shift-dragging
on corner action zones - on the Windows platform the resulting window
is initially unresponsive. This patch fixes this by releasing the parent
window's mouse capture.
See D14085 for more details.
Differential Revision: https://developer.blender.org/D14085
Reviewed by Ray Molenkamp
Windows IME: Fix duplicated initial character when entering numbers
while in Chinese full width character mode.
See D14354 for more details.
Differential Revision: https://developer.blender.org/D14354
Reviewed by Brecht Van Lommel
Mousemove events are sent to windows.
In Windows OS, almost all mousemove events are sent to the window whose
mouse cursor is over.
On MacOS, the window with mousemove events is always the active window.
It doesn't matter if the mouse cursor is inside or outside the window.
So, in order for non-active windows to also have events,
`WM_window_find_under_cursor` is called to find those windows and send
the same events.
The problem is that to find the window, `WM_window_find_under_cursor`
only has the mouse coordinates available, it doesn't differentiate
which monitor these coordinates came from.
So the mouse on one monitor may incorrectly send events to a window on
another monitor.
The solution used is to use a native API on Mac to detect the window
under the cursor.
For Windows and Linux nothing has changed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14197
This fixes T93051, T76405 and maybe others.
Characters like '²', '<' are not recognized in Blender's shortcut keys.
And sometimes simple buttons like {key .} and {key /} on the Windows
keyboard, although the symbol is "known", Blender also doesn't
detect for shortcuts.
For Windows, some of the symbols represented by `VK_OEM_[1-8]` values,
depending on the language, are not mapped by Blender.
On Mac there is a fallback reading the "actual character value of the
'remappable' keys". But sometimes the character is not mapped either.
On Windows, the solution now mimics the Mac and tries to read the button's
character as a fallback.
For unmapped characters ('²', '<', '\''), now another value is chosen as a
substitute.
More "substitutes" may be added over time.
Differential Revision: https://developer.blender.org/D14149
Helps with building against different OpenXR SDK versions (i.e. for
downstream builds that require specific versions), as the extension was
only defined since OpenXR 1.0.22.
This fixes VR pink screen issues when using the DirectX backend, caused
by `wglDXRegisterObjectNV()` failing to register the shared
OpenGL-DirectX render buffer. The issue is mainly present on AMD
graphics, however, there have been reports on NVIDIA as well.
A limited workaround for the SteamVR runtime (AMD only) was provided
in rB82ab2c167844, however this patch provides a more complete solution
that should apply to all OpenXR runtimes. For example, with this patch,
the Windows Mixed Reality runtime that exclusively uses DirectX can now
be used with AMD graphics cards.
Implementation-wise, a `GL_TEXTURE_2D` render target is used as a
fallback for the shared OpenGL-DirectX resource in the case that
registering a render buffer (`GL_RENDERBUFFER`) fails. While using a
texture render target may be less optimal than a render buffer, it
enables proper display in VR using the OpenGL/DirectX interop (tested
on AMD Vega 64).
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14100
When using a RGBA16 (`GL_RGBA16`, `DXGI_FORMAT_R16G16B16A16_UNORM`)
swapchain format with Quest 2, no image is presented to the headset.
This can occur when using the SteamVR runtime with an AMD graphics card
(ex. T95374).
Workaround is to move this format after the Quest 2-compatible RGBA16F
formats in the candidates list so that the RGBA16F formats are chosen
instead.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14024
Crash was caused since the function pointers
`s_xrGetOpenGLGraphicsRequirementsKHR_fn`/
`s_xrGetD3D11GraphicsRequirementsKHR_fn` were static and were not
updated with the correct proc address after being set the first time.
As stated in the OpenXR spec: "function pointers returned by
xrGetInstanceProcAddr using one XrInstance may not be valid when used
with objects related to a different XrInstance".
Although it would seem reasonable that the proc address would not
change if the instance was the same (hence the `static XrInstance s_instance;`),
in testing, repeated calls to `xrGetInstanceProcAddress()`
with the same instance still can result in changes (at least for the
SteamVR runtime) so the workaround is to simply set the function pointers
every time, essentially trivializing their `static` designations.
Reviewed By: Severin
Maniphest Tasks: T94268
Differential Revision: https://developer.blender.org/D14023
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
