From @ozkan: Except for line 2537, all those trailing whitespace are from original code which had left in as-is in case we want to upgrade to a newer version more easily.
Also explicitly reset fullscreen mode when destroying a window, eliminating the need for doing that in SDL_HideWindow(), as that's already taken care of in SDL_OnWindowHidden() normally.
Passing True for owner_events in the XGrabPointer call makes all
XI_RawMotion events appear in the queue twice, with the only difference
between them being the value of XGenericEventCookie::cookie. These have
always been filtered out by a check in the XI_RawMotion handler,
however with a mouse that polls at more than 1 kHz frequency, there
also exist legitimate events that appear indistinguishable from these
duplicated events. These must not be filtered out, otherwise the
pointer may move at an inconsistent speed, appearing like a bad pointer
acceleration implementation.
Change owner_events to False in the XGrabPointer and remove the
duplicate event detection code to fix this.
Signed-off-by: Torge Matthies <openglfreak@googlemail.com>
Setting the cursor clip area to a single pixel prevents the relative mouse motion remote desktop warping from working, so the mouse is never recentered.
Track the current window display ID locally so as not to depend on specific behavior of the video layer, which may change the value at times when it isn't expected.
Track the current window display ID locally so as not to depend on specific behavior of the video layer, which may change the value at times when it isn't expected.
When moving a window programmatically, the move event will be deduplicated due to the window x and y coordinates already being updated, so the window's current display ID needs to be explicitly updated.
Update the target display ID and use SDL_UpdateFullscreenMode() when moving a fullscreen window to handle the case where the target display has an existing fullscreen window.
We get audio artifacts if we don't work at the higher precision, but
this is painful on CPUs that have to use a software fallback for this,
so for now (that is, until we have a better solution), get better output
on amd64 chips, where the cost is less painful.
I don't know if we ever actually hit this in practice, but if this isn't
replacing the whole buffer, it needs to slide the end of the existing padding
over to the start before adding in the new data.
