|
bcbaa4ec
|
2020-05-26T16:34:50
|
|
If there isn't a GetGlobalMouseState() implementation, fall back to the normal one.
|
|
|
437577f9
|
2020-05-26T16:29:26
|
|
Fixed bug 5141 - KMSDRM: manage SDL_GetGlobalMouseState()
Manuel Alfayate Corchete
On the KMSDRM backend, there is no such thing as a desktop, yet some programs could (and DO) use SDL_GetGlobalMouseState().
So I think its good idea that, in KMSDRM, it returns the same mouse coordinates anyway as SDL_GetMouseState() would return. There is nothing else it could return, as far as I can understand, since there is no desktop anyway.
This small patch does precisely that.
|
|
|
3e935aec
|
2020-02-09T11:44:22
|
|
Fixed bug 4966 - KMSDRM: Add dynamic modeset support
Anthony Pesch
* Remove triple buffering support. As far as I can tell, this goes against the libdrm API; the EGL implementations themselves control the buffering. Removing it isn't absolutely necessary as it seemingly works on the Pi at least, but I noticed this while doing my work and explained my reasoning in the commit.
* Replace the crtc_ready logic which allocates an extra bo to perform the initial CRTC configuration (which is required before calling drmModePageFlip) with a call to drmModeSetCrtc after the front and back buffers are allocated, avoiding this allocation.
* Standardized the SDL_*Data variable names and null checks to improve readability. Given that there were duplicate fields in each SDL_*Data structure, having generic names such as "data" at times was very confusing.
* Removed unused fields from the SDL_*Data structures and moves all display related fields out of SDL_VideoData and into SDL_DisplayData. Not required since the code only supports a single display right now, but this was helpful in reading and understanding the code initially.
* Implement KMSDRM_GetDisplayModes / KMSDRM_SetDisplayMode to provide dynamic modeset support.
These changes have been tested on a Raspberry Pi 4 and a Dell XPS laptop with an HD 520.
As an update, I went back over the triple buffer changes and left them in. I didn't entirely get the code originally, I had just seen it calling KMSDRM_gbm_surface_lock_front_buffer twice for a single swap and had removed it because I was paranoid of bugs stemming from it while working on the modeset changes.
I've made a few small changes to the logic that had thrown me off originally and rebased the changes:
* The condition wrapping the call to release buffer was incorrect.
* The first call to KMSDRM_gbm_surface_lock_front_buffer has been removed. I don't understand why it existed.
* Added additional comments describing what was going on in the code (as it does fix the buffer release pattern of the original code before it).
|
|
|
a8780c6a
|
2020-01-16T20:49:25
|
|
Updated copyright date for 2020
|
|
|
5e13087b
|
2019-01-04T22:01:14
|
|
Updated copyright for 2019
|
|
|
5febdfce
|
2018-09-24T11:49:25
|
|
Fixed whitespace
|
|
|
e3cc5b2c
|
2018-01-03T10:03:25
|
|
Updated copyright for 2018
|
|
|
47506fe1
|
2017-12-04T20:37:01
|
|
Fixed bug 3974 - Fix SDL_WarpMouseInWindow on both KMSDRM and RaspberryPi drivers
Manuel Alfayate Corchete
This patch fixes SDL_WarpMouseInWindow() in both the KMSDRM and Raspberry Pi graphic backends.
|
|
|
8758b7bf
|
2017-11-24T12:03:28
|
|
Fixed bug 3980 - Fix for KMSDRM driver where cursor would not be shown on some gfx hardware because of unsupported cursor size
Manuel Alfayate Corchete
This fixes a problem with KMSDRM on some graphics hardware where only bigger cursor sizes are supported, such as current Intel gfx. (The kernel-side driver is what limits this: had to look for failing IOCTLs...)
That caused SDL_SetCursor() to fail silently, and we were left with a missing cursor without further explanation.
With this patch, different "standard" sizes are tried and a bigger one is used (with an intermediate and clean buffer only used to write the new cursor to the BO where it will live after) if we get, let's say, 16x16 which is pretty common but our hardware does not support that.
|
|
11717184
|
2017-08-21T17:20:50
|
|
kmsdrm: Cleanup unused headers, rename SDL_kmsdrmevents_c.h -> SDL_kmsdrmevents.h
|
|
|
56363ebf
|
2017-08-02T10:22:48
|
|
Fixed bug 3690 - SDL2 KMS/DRM render context support
Manuel
The attached patch adds support for KMS/DRM context graphics.
It builds with no problem on X86_64 GNU/Linux systems, provided the needed libraries are present, and on ARM GNU/Linux systems that have KMS/DRM support and a GLES2 implementation.
Tested on Raspberry Pi: KMS/DRM is what the Raspberry Pi will use as default in the near future, once the propietary DispmanX API by Broadcom is overtaken by open graphics stack, it's possible to boot current Raspbian system in KMS mode by adding "dtoverlay=vc4-kms-v3d" to config.txt on Raspbian's boot partition.
X86 systems use KMS right away in every current GNU/Linux system.
Simple build instructions:
$./autogen.sh
$./configure --enable-video-kmsdrm
$make
|