If we get a SDL_SetWindowSize() call right after SDL_SetWindowFullscreen() but
before we've gotten a new configure event from the compositor, the attempt to
set our window size will silently fail (when libdecor is enabled).
Fix this by remembering that we need to commit a new size, so we can do that
in decoration_frame_configure().
This prevents SDL from making an OpenGL context and maybe throwing it away
immediately by default. It will now only do it when trying to request a
window framebuffer directly, or creating an SDL_Renderer with the "software"
backend, which makes that request itself.
The way SDL decides if it should use a "texture framebuffer" needs dramatic
updating, but this solves the immediate problem.
Reference Issue #4624.
First window is created and it triggers and 'EnterNotify' event
which calls SDL_SetMouseFocus() and X11_ShowCursor() while the second
windows hasn't finished to be created (eg window->driverdata isn't set)
Just check for a valid 'driverdata'
GLES2 always has them, and they work without hacks on Emscripten, unlike
client-side arrays.
I cleaned it up slightly, but this patch was mostly written by @bing2008.
Fixes#5258.
The issue is that MS Windows synthesizes a mouse-move event in response
to touch-move events, and those mouse-move events are NOT labeled as
coming from a touch (e.g. GetMouseMessageSource() will not return
SDL_MOUSE_EVENT_SOURCE_TOUCH for those synthesized mouse-move events).
In addition, there seems to be no way to prevent this from happening;
https://gist.github.com/vbfox/1339671 claims to demonstrate a technique
to prevent it, but in my experience, it doesn't work.
Because of this, the "fallthrough" case can't test that the synthesized
mouse-move came from a touch-move, and starts erroneously pressing down
the mouse-button, leading to massive confusion in the client
application.
If a touch-down event is received for an existing touch-ID, that
probably means the operating system lost it, and that the missing
touch-up should be synthesized, to keep the client state coherent.
This caused some weird stuff to happen in the libdecor path, probably because
the window hasn't actually been mapped yet. It ends up calling stuff that
should not yet apply, and so fullscreen in particular would have a really
messed up titlebar.
The good news is, libdecor is good about tracking fullscreen state, so we can
let the callback do this for us. Keep this for xdg_shell because we actually
map the window ourselves, so we know this call is valid for that path.
Pipewire, as of 0.3.22, uses client config files to load modules instead of explicitly specifying them (PW_KEY_CONTEXT_PROFILE_MODULES is deprecated). Use the new method to load the realtime module to boost the audio thread priority.
From e6cc4e7f4b8189be55dd3b0e13e54e59f73d7672 Mon Sep 17 00:00:00 2001
From: X512 <danger_mail@list.ru>
Date: Thu, 30 Jan 2020 04:01:58 +0900
Subject: libsdl2: Remove BDirectWindow, fix OpenGL handling.
* BDirectWindow changed to BWindow.
* Implemented fullscreen.
* Introduced view for non-OpenGL drawing.
* Drawing thread removed, window thread is used instead.
* Use BGLView as OpenGL context. Implement proper context switching and OpenGL
locking. Only one context per window is supported. BGLView should be not
deleted when window is closed, it deleted when deleting context.
GitHub Actions is a 64-bit Ubuntu instance. It was only using the 32-bit
binaries because our buildbot put this on the 32-bit Linux host to spread
the CPU load around more evenly.
when using alternate unwind implementations like LLVM libunwind
this library is not provided yet the libunwind features are fully
implemented in main libunwind, making this hard dependency assumes
a particular libunwind implementation, this patch makes it optional
which makes the builds to work with llvm libunwind
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Ryan C. Gordon
Cameron Gutman
Eric Wasylishen
Ethan Lee
Sam Lantinga
Sylvain
ulatekh
Charlie Birks
Ozkan Sezer
Carl Glave
Frank Praznik
Mathieu Eyraud
kenmays
Khem Raj