- especially because we can be promoted to true color 888
make sure we don't select a potentially software implementation
- hopefully fix bug #1482 (EGL ChooseConfig selects software renderer on Android)
If you hide a window on Mutter, for example, the compositor never requests
new frames, which will cause Mesa to block forever in eglSwapBuffers to
satisfy the swap interval.
We now always set the swap interval to 0 and manage this ourselves, handing
the frame to Wayland when it requests a new one, and timing out at 10fps just
to keep apps moving if the compositor wants no frames at all.
My understanding is that other protocols are coming that might improve upon
this solution, but for now it solves the total hang.
Fixes#4335.
These would accidentally get a titlebar because the "borderless" style mask
is zero but the resizable attribute adds a bit. I assume this happens because
you used to need window decoration to resize a window in macOS, but this
changed in later releases.
This only caused problems when recreating a window (you had an
SDL_WINDOW_OPENGL window and tried to create a Metal SDL_Renderer on it, etc).
Fixes#4324.
It doesn't appear to work anymore, and was disabled by default anyhow, since
the needed APIs are forbidden on the Mac App Store.
A better solution to lock the mouse to the window on macOS would still be
welcome. CGAssociateMouseAndMouseCursorPosition() works fine for relative
mouse mode, this was just a question of SDL_SetWindowGrab(). As it stands
now, a grabbed mouse can briefly break out of the window, causing varying
degrees of chaos.
This can give some performance boost, and save some resources, as there's no
reason to keep a copy of an SDL window's contents on the server: most SDL
apps are redrawing completely every frame, and the API allows for expose
events to tell an app a redraw is needed anyhow.
(And compositors are free to ignore this setting if it makes sense to do so,
according to the Xlib docs.)
Reference Issue #3776.
It's already set with ANativeWindow_setGeometry, and eventually set/changed also by eglCreateWindowSurface.
- avoid issues with older device where SurfaceView cycle create/changed/destroy appears broken:
calling create/changed/changed, and leading to "deuqueBuffer failed at server side, error: -19", with black screen.
- re-read the format after egl window surface is created, to report the correct one (sometimes, changed from RGBA8888 to RGB24)
Previous version used 'popen' which required to sanitize user provided text. Not
sanitizing text could cause failure if user provided text included a " or command
injection with `cmd`.
There is an error "E libEGL : validate_display:91 error 3008 (EGL_BAD_DISPLAY)"
that occurs when calling "eglQueryString(display, EGL_VERSION)", with EGL_NO_DISPLAY.
Khronos says "EGL_BAD_DISPLAY is generated if display is not an EGL display connection, unless display is EGL_NO_DISPLAY and name is EGL_EXTENSIONS."
but this was added in SDL with "EGL 1.5 allows querying for client version"
( 56363ebf61 )
In fact:
- it actually doesn't work on Android that has 1.5 egl client
- it works on desktop X11 (using SDL_VIDEO_X11_FORCE_EGL=1)
The commit moves the version call where it's used, eg inside the "if (platform) {"
and checks that "eglGetPlatformDisplay" has been correctly loaded.
This unearthed an unspeakably large amount of bugs in the wl_output enumerator,
notably the fact that the wl_output user pointer was to temporary memory!
This was "fixed" in e862856, and was then pointed out as a leak in 4183211,
which was undone in d9ba204. The busted fix was correct that the malloc was an
issue, but wrong about _why_; SDL_AddVideoDisplay copies by value and does not
reuse the pointer, so generally you want your VideoDisplay to be on the stack,
but of course the callbacks don't allow that, so a malloc was a workaround. But
we can do better and just host our temporary display inside WaylandOutputData
because that will be persistent while also not leaking.
Wait, wasn't I talking about move events? Right, that: wl_surface_listener does
at least give us the ability to know what monitor we're on, even though we have
no idea where we are on the monitor. All we need to do is check the wl_output
against the display list and then push a move event that both indicates the
correct display while also not being _too_ much of a lie (but enough of a lie
to where our event doesn't get discarded as "undefined" or whatever). The index
check for the video display is what spawned the great nightmare you see before
you; aside from the bugfix this is actually a really basic patch.
