|
87a86675
|
2020-10-22T16:01:51
|
|
kmsdrm: Always use spaces for indentation. Always use SDL_calloc() for calloc.
|
|
|
0f807fd6
|
2020-09-07T22:54:15
|
|
kmsdrm: use a black dumb buffer for keeping the PRIMARY PLANE occupied when we destroy the KMS buffers, instead of using the TTY buffer, to avoid flickering.
|
|
|
16c04f26
|
2020-08-23T02:58:57
|
|
kmsdrm: Init cursor surface on SetCursor() ONLY. Removal of dynamic modeset because it causes A LOT of problems with some kernel video drivers. Some refactoring and cleanups.
|
|
|
92cb9192
|
2020-08-17T18:35:04
|
|
kmsdrm: move hardware cursor functionality to the ATOMIC interface. Disconnect the display plane from the GBM surface buffers before destroying the GBM surface.
|
|
|
1a5503ce
|
2020-07-28T21:11:25
|
|
kmsdrm: Moved to the ATOMIC KMS/DRM interface for buffer swapping, leaving DRM-legacy behind.
|
|
71e9df99
|
2020-07-19T08:55:01
|
|
Fixed bug 5231 - Fix for hardware cursor: size and alpha-premultiplication.
Manuel Alfayate Corchete
I noticed pt2-clone had problems with it's optional hardware mouse on the KMSDRM backend: cursor had a transparent block around it.
So I was investigating and it seems that a GBM cursor needs it's pixels to be alpha-premultiplied instead of straight-alpha.
A
lso, I was previously relying on "manual testing" for the cursor size, but it's far better to use whatever the DRM driver recommends via drmGetCap(): any working driver should make a size recommendation via drmGetCap(), so that's what we use now. I took this decision because I found out that the AMDGPU driver reported working cursor sizes that would appear garbled on screen, and only the recommended cursor size works.
|
|
|
a8780c6a
|
2020-01-16T20:49:25
|
|
Updated copyright date for 2020
|
|
|
5e13087b
|
2019-01-04T22:01:14
|
|
Updated copyright for 2019
|
|
|
e3cc5b2c
|
2018-01-03T10:03:25
|
|
Updated copyright for 2018
|
|
|
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
|