Optimise the AVX 2 implementation reducing number of operations per block
and also add an AVX-512 implementation used when the CPU supports it at
runtime.
Mostly comes from detecting the case of runs of ASCII printable
characters and using a special fast path for them. Improves benchmarks
as per benchmark.py by 15-30% for text heavy workloads
surfaceHandleEnter() and surfaceHandleLeave() passed the event's output
argument straight to wl_output_get_user_data(). Wayland delivers object
arguments as NULL when the object was destroyed client-side before the
event was dispatched, even for arguments declared non-nullable, so this
segfaults whenever a wl_output global goes away while a window is open.
Easily reproduced with a hardware KVM or a monitor input switch.
Also fixes two pre-existing problems in surfaceHandleLeave():
- The removal loop stopped at monitorsCount - 1, so it never compared the
last entry, and the trailing unconditional
window->wl.monitors[--window->wl.monitorsCount] = NULL
dropped the last monitor whether or not it was the one that was left.
A leave for a monitor not in the list therefore evicted an unrelated
one.
- That same statement ran even when monitorsCount was 0, writing to
monitors[-1] and leaving the count negative.
Both are replaced with the remove_i_from_array() loop already used for
this array in registryHandleGlobalRemove().
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
resetScrollValuators() runs on every LeaveNotify, clearing the initialized
flag of every scroll valuator. handle_xi_motion_event() then treats the next
XI_Motion event as a baseline sample and discards it.
On setups where the X server emits crossing events with mode NotifyGrab
faster than the wheel is turned, every scroll event lands in that branch and
is swallowed, so scrolling does not work at all. This is easy to hit inside a
VMware guest, where the same physical mouse is exposed as several pointer
devices: --debug-input shows a continuous leave/enter cycle and a single
Scroll event for the whole session.
Fix this in two places:
- Do not reset the baseline for crossing events generated by a grab being
activated/released or by the pointer moving to a child window, since the
pointer did not actually leave.
- Keep the baseline value across a reset so the next event can still compute
a delta from it, and only discard the event when the jump is too large to
be a genuine scroll.
Fixes#9846
On X11 glfw_xkb_compile_keymap() gets its state from
xkb_x11_state_new_from_device(), which seeds it with the server's physical
modifier mask. Every other path into that state goes through
glfw_xkb_update_modifiers(), where the permutation is applied, so after a
keymap reload the state held physical modifiers until the next XkbStateNotify
happened to arrive. Any key pressed in that window was encoded with the
modifier on the keycap: with ctrl held across a reload under
`remap_modifiers ctrl:super`, Ctrl+A reached the child as a literal 0x01.
Keymap reloads are routine - switching layout causes one, and so does any
client asking X for a keysym it must bind to a spare keycode.
Re-apply the permutation to the freshly loaded state, after
glfw_xkb_update_masks() has computed the modifier indices it is expressed in.
On Wayland the new state is empty, so this is a no-op there.
