[Release] SDL2 with screen rotation

[AreaScout]

Ported SDL2 with internal screen rotation

Hi all

I have successfully ported SDL2, the screen will be automatically rotated and a screen resolution of 480x320 will be reported to the underlying application so you don't need modified PPSSPP or Emulationstation anymore.
There are tons of free games to find on github and probably some good emulators using SDL2, there are also some good open source GUI's (nanoguisdl) which supports SDL2 too, so here we go have fun with it.

IMG_3601.png (864.95 KiB) Viewed 36775 times

First ! You need the mali GPU driver as deb packages so it wont be overwritten bei mesa libraries

Code: Select all

wget https://oph.mdrjr.net/meveric/pool/go2/libm/libmali-rk/libmali-rk-bifrost-g31-rxp0-gbm_1.7-2+deb10_arm64.deb
wget https://oph.mdrjr.net/meveric/pool/go2/libm/libmali-rk/libmali-rk-dev_1.7-1+deb10_arm64.deb
sudo apt install ./libmali-rk-dev_1.7-1+deb10_arm64.deb ./libmali-rk-bifrost-g31-rxp0-gbm_1.7-2+deb10_arm64.deb

Get the modified SDL2 and install it:

First package are the runtime libraries and second is the development package (headers etc.) in case you are about to compile applications
The SDL2 library will install in /usr/lib/aarch64-linux-gnu and will overwrite any previously installed SDL2 library

Code: Select all

wget https://www.areascout.at/libsdl2_2.0.10_arm64.deb
wget https://www.areascout.at/libsdl2-dev_2.0.10_arm64.deb

sudo apt install ./libsdl2_2.0.10_arm64.deb
sudo apt install ./libsdl2-dev_2.0.10_arm64.deb

You can find the patch used for SDL2 2.0.10 here -> https://www.areascout.at/go2_go3_rotate.patch

The patch used for SDL2 2.0.12 you can find here -> https://github.com/AreaScout/SDL/commit ... 4180.patch

If you need the test programs for SDL2 (controllermap etc.), they are found inside the libsdl2-dev package, please do this:

Code: Select all

cd /usr/share/doc/libsdl2-dev/examples/
tar xvf examples.tar.gz
cd test
gcc controllermap.c -o controllermap -lSDL2 -lSDL2_test -lGLESv2 -I /usr/include/SDL2/
controllermap 0 > gamecontrollerdb.txt

That's all, have fun

[shanti]

Really cool! do you think you could also share the source code? or at least the patch ?

[cjv123]

I did it your way, sdl worked！！

[npaladin2000]

Great! Can you provide sources for the distributions that are buildroot-based also?

[AreaScout]

@shanti @npaladin2000

Yes, I will share the source code, I do have to check some things before (linking and some tests), maybe tomorrow

RG

[PaulF8080]

Ported SDL2 with internal screen rotation

Hi all

I have successfully ported SDL2 with internal screen rotation so you don't need modified PPSSPP or Emulationstation anymore SDL2 will report a screen resolution of 480x320 as stated already in another thread.
There are tons of free games to find on github and probably some good emulators using SDL2, there are also some good open source GUI's (nanoguisdl) which supports SDL2 too, so here we go have fun with it.

Great work. 1200+ posts is impressive. I read that the stock Nintendo 64 emulator uses SDL2. Is that true? Does the Mali driver speed it up?

[cjv123]

SDL2 works fine, but what about SDL1

[AreaScout]

@PaulF8080

Sure it will speedup, SDL2 supports OpenGLES1/2 which Mali also does

@cjv123

SDL1.x does not have a KMS/DRM video backend, it supports fbdev and X11 mainly, the easiest way would be to port a SDL1.x application over to SDL2.x, but still those games/applications are using sometimes pure OpenGL rendering which our driver is not capable of, meveric is working on an super cool image which runs with X11 drivers and so SDL1.x could run on that with some tricks (GL to ES converter library gl4es) it could even be hardware accelerated, same could work if you port it from SDL1.x to SDL2.x and using gl4es but that strongly depends on the game and how it is programmed.

RG

[AreaScout]

@all

Sorry for anyone waiting, I had to fix a screen tearing issue, tomorrow I will release source and build instruction, it's to late for me today

RG

[PaulF8080]

I did your 4 packages and it had a lot of not needed files. It removed "/usr/include/SDL2/SDL_image.h".

I did "sudo apt-get install libsdl2-image-dev" to restore it. I should have done that after your packages anyway.

You fixed my problem on the stock image. Apparently it was failing trying to use the mesa driver. See the" SDL not working" thread.

thanks

[AreaScout]

Building modified SDL2 from source instructions:

Install GPU development headers and library:

Code: Select all

wget https://oph.mdrjr.net/meveric/pool/go2/libm/libmali-rk/libmali-rk-bifrost-g31-rxp0-gbm_1.7-2+deb10_arm64.deb
wget https://oph.mdrjr.net/meveric/pool/go2/libm/libmali-rk/libmali-rk-dev_1.7-1+deb10_arm64.deb
sudo apt install ./libmali-rk-dev_1.7-1+deb10_arm64.deb ./libmali-rk-bifrost-g31-rxp0-gbm_1.7-2+deb10_arm64.deb

Install other development headers and build tools:

Code: Select all

sudo apt-get install libx11-dev libsm-dev libxext-dev git cmake mercurial libudev-dev libdrm-dev zlib1g-dev pkg-config libasound2-dev libfreetype6-dev libx11-xcb1 libxcb-dri2-0

Checkout the source and build SDL2 with KMSDRM support:

Code: Select all

cd ~
git clone https://github.com/AreaScout/SDL.git
cd SDL
./autogen.sh
./configure --disable-video-opengl --enable-video-kmsdrm
make -j3
sudo make install

Testing with PPSSPP daily build:

IMG_3601.png (864.95 KiB) Viewed 36110 times

We have to revert two commits which are slowing down PPSSPP a lot (0f74a19 & 857e0bb)

Code: Select all

cd ~
git clone https://github.com/hrydgard/ppsspp.git --recursive
cd ppsspp/ffmpeg
./linux_arm64.sh
cd ..
git revert 0f74a19 -m 1
git revert 857e0bb -m 1
mkdir build && cd build
cmake -DUSING_EGL=OFF -DUSING_GLES2=ON -DUSE_FFMPEG=YES -DUSE_SYSTEM_FFMPEG=NO ../.
make -j3
strip PPSSPPSDL

It could be that you already have SDL2 installed from the ubuntu repositories, as sudo make install copies the binaries to /usr/local/lib and the debian installer to /usr/lib/aarch64-linux-gnu you have to overwrite any SDL2 library which is already on the system (the quick and dirty way)

sudo cp /usr/local/lib/libSDL2.so /usr/lib/aarch64-linux-gnu/libSDL2.so

Now you should be able to start PPSSPP with
./PPSSPPSDL

P.S.:For PPSSPP you really should enable CPU, GPU and memory governor to performance -> i.e Ghost'n Goblins is able to render in 3x PSP resolution

Code: Select all

echo performance > /sys/devices/platform/ff400000.gpu/devfreq/ff400000.gpu/governor
echo performance > /sys/devices/platform/dmc/devfreq/dmc/governor
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

RG and have fun

[crashoverride]

Sadly it still has some screen tearing here and there

After looking at the code, it appears there is only a single output buffer
https://github.com/AreaScout/SDL/blob/0 ... deo.c#L274

This would mean that the single buffer is both being displayed and updated while waiting for the next VSYNC. You will need to create and manage multiple target buffers to avoid tearing.

[AreaScout]

@crashoverride

No, I still have the GBM bo as front and back buffer (480x320) where EGL/GLES draws in, while the front buffer is decoupled from the display and my DRM_IOCTL_MODE_CREATE_DUMB buffer (320x480) is bound to the display instead, so I have to watch out and blit in the same moment the vsync happens from the front to my own buffer (320x480), but somehow sometimes it makes problems, maybe the blit takes too much time, it is sync for some time then it get's out of sync, It is much better in SDL2.0.12 than in SDL2.0.10 because there was a fix lately KMSDRM_gbm_surface_lock_front_buffer was called twice for a single swap, this was fixed 3 weeks ago. Maybe I try to thread things ...

RG

[crashoverride]

Mali's GBM implementation is internally triple buffered. You can lock three surface before you run out. Normally, a surface is locked and associated with a DRM framebuffer object for display. The buffer remains locked until another buffer+framebuffer is locked and displayed. Then the previous buffer is released.

When using only a single buffer+framebuffer, the contents of the buffer is always displayed. This makes updates to it visible as tearing. Therefore, there is a need to double or triple buffer it just as GBM does with its buffer. You can see an example of this behavior in libgo2.

[shanti]

Checkout the source and build SDL2 with KMSDRM support:

Code: Select all

cd ~
git clone https://github.com/AreaScout/SDL.git
cd SDL
./autogen.sh
./configure --disable-video-opengl --enable-video-kmsdrm
make -j3
sudo make install

Thanks for sharing the code I can cross-compile it and it seems to work fine, I ran some apps that were not rotated before and now screen is rotated and everything seems to work as expected except I don't get any game-pad input on any application that uses SDL. I was using 2.0.9 before without this issue, do you know what could be the cause to this?

When I build it I can see the module "joystick" being detected and built. I made sure the gamepad is working with evtest, but not even a gamepad I connect to USB works on with this SDL version.

Code: Select all

Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly

if I run any other app that does not depend on SDL the gamepad works as expected.

Am I missing something very obvious ?

Thanks!
Shanti!

EDIT: unfortunately for me the commit that changed how KMSDRM is used is the one that breaks gamepad :/

Code: Select all

4f92082f7265f1c29729fe95ad744e833c4dbe0d

I have no idea why, I assume its the changes to the mouse but any other version compiled before this one gamepad works fine

[AreaScout]

@shanti

SDL 2.0.12 changes the default behavior to use the button label rather than the button position as most other software does, to get the old behavior back set the environment variable SDL_GAMECONTROLLER_USE_BUTTON_LABELS to 0

or

cd into /SDL/test and do a

Code: Select all

./configure
make-j3
./controllermap 0 > gamecontrollerdb.txt

and remap your Go2 controller, any application which is build on SDL2 will read that gamecontrollerdb.txt if it's found beside the binary, you should connect a keyboard to skip buttons by pressing space which are not found on your Go2, I was playing PPSSPP games yesterday with the new behavior of SDL2 inputs and a new button mapping

IMG_3603_.png (1.08 MiB) Viewed 35819 times

RG

[shanti]

@shanti

SDL 2.0.12 changes the default behavior to use the button label rather than the button position as most other software does, to get the old behavior back set the environment variable SDL_GAMECONTROLLER_USE_BUTTON_LABELS to 0

or

cd into /SDL/test and do a

Code: Select all

./configure
make-j3
./controllermap 0 > gamecontrollerdb.txt

and remap your Go2 controller, any application which is build on SDL2 will read that gamecontrollerdb.txt if it's found beside the binary, you should connect a keyboard to skip buttons by pressing space which are not found on your Go2, I was playing PPSSPP games yesterday with the new behavior of SDL2 inputs and a new button mapping
RG

Unfortunately this seems to be another issue, no matter what env I set or even if I use the gamecontrollerdb.txt it just doesn't work, but if I build the commit before https://github.com/AreaScout/SDL/commit ... 833c4dbe0d gamepad works like a charm, anything after that and it breaks. Unfortunately for me, your patch is based on that exact commit :/

anyways I will keep investigating.

EDIT: Can you try emulationstation?

Thanks

[AreaScout]

@shanti

Interesting, I don't see why this commit should break any input, here is the patch which is applying before the commit

RG

[shanti]

@shanti

Interesting, I don't see why this commit should break any input, here is the patch which is applying before the commit

RG

THANK YOU! That works

[AreaScout]

@crash

Still I don't get it why sometimes it runs out of sync but it is like it is, it waits for the vsync and then updates the buffer but the blit does not take precisely in place as it looks, I think I will find a solution, I use the same method in moonlight-embedded both SDL2 and RK video backend and on moonlight-qt which I have to say is the coolest thing I have used so far on the Go2 -> unbelievable cool and they DO work without tearing, I think it has something to do with triple buffering I am new to that stuff

RG

[kavag]

Very nice! Is the PSP performance better compared to the stock image?

[shanti]

@crash

Still I don't get it why sometimes it runs out of sync but it is like it is, it waits for the vsync and then updates the buffer but the blit does not take precisely in place as it looks, I think I will find a solution, I use the same method in moonlight-embedded both SDL2 and RK video backend and on moonlight-qt which I have to say is the coolest thing I have used so far on the Go2 -> unbelievable cool and they DO work without tearing, I think it has something to do with triple buffering I am new to that stuff

RG

I am not that familiar with this, but on the commit I pointed out they are saying they removed triple buffering, could this be related to what crash was talking about?

[crashoverride]

Its probably going to be easier if I just patch it than explain it.

All KMS/GBM programs do effectively the same thing. They lock a GBM buffer, associate a DRM framebuffer with it so it can be displayed, and tell DRM to display it. In SDL, this happens here:
https://github.com/AreaScout/SDL/blob/0 ... gles.c#L64

Its important to note that you do not have anything to display until you have told EGL to swap the surface. The RGA blit takes place prior to having a valid frame to display:
https://github.com/AreaScout/SDL/blob/0 ... les.c#L108

After the EGL swap (makes EGL's backbuffer the front buffer), the new EGL front buffer is locked so that it can not be re-used by EGL for drawing:
https://github.com/AreaScout/SDL/blob/0 ... les.c#L114

With the buffer locked, its contents are now valid and can be displayed. This is where the blit/rotation should take place. The locked buffer's associated DRM framebuffer is then displayed by DRM:
https://github.com/AreaScout/SDL/blob/0 ... les.c#L140

This buffer remains locked and unusable for entire duration of display. It is not unlocked until a different buffer has taken its place. Note that this does not occur until the next swap:
https://github.com/AreaScout/SDL/blob/0 ... les.c#L100

---

Since the GBM buffers are no longer being directly displayed (they are blit/rotated to a new surface), the logic must be changed. As stated before, with only a single buffer for the blit/roation, that buffer will ALWAYS be displayed so any updates that occur to it are visible if they do not occur in the vertical blanking interval. The solution is to create 2 or more buffers for blit/rotation and then: 1) EGL swap, 2) lock the GBM buffer, 3) blit/rotate to an unused dumb buffer, 4) immediately release the GBM buffer, and 5) display the dumb buffer. When the next frame comes around, grab a free dumb buffer (remember the previous one is still being displayed), repeat the above blit/rotate procedure, and display it. Now that a new dumb buffer is being displayed, the previous one can be reused.

---

I should note there is another issue that further complicates this. On a PC, when DRM is told to flip a buffer, it usually does not block. On the GO Advance, its KMS/DRM driver will block until after VSYNC has occurred. Using the "atomic" API is the only way to guarantee frame blocking behavior in KMS/DRM.

[AreaScout]

@kavag

I did not compare them speedwise, the most different I can tell is that the setup dialog has different dimension (2x) and therefore you can fully browse the menu

@shanti

No he said he left them in https://bugzilla.libsdl.org/show_bug.cgi?id=4966, but I can't see triple buffering anywhere ...

@crash

Thank you for explaining a good part of that I already know you brought me to an idea but I think I can test this on Saturday at earliest

RG

[shanti]

@shanti

No he said he left them in https://bugzilla.libsdl.org/show_bug.cgi?id=4966, but I can't see triple buffering anywhere ...

the patch notes say this:

* 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.

And the patch does remove a bunch of code, but again, I am not familiar with it so not sure if its tripe buffering or other stuff

but yeah he then says he left them in.

"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."

so who knows :/

Maybe you could try your patch before that commit (the one you posted for me) and see if the tearing is also there.

[crashoverride]

Its probably going to be easier if I just patch it than explain it

Here is the fix as previously described:
https://github.com/OtherCrashOverride/s ... 10f2183c15

There is some commit "noise". Only 3 files were actually modified:
src/video/kmsdrm/SDL_kmsdrmopengles.c
src/video/kmsdrm/SDL_kmsdrmvideo.c
src/video/kmsdrm/SDL_kmsdrmvideo.h

[inolen]

Hey shanti ,

Regarding triple buffering - I had originally misread the code and misspoke, in the end it still functions the same before and after my change.

The primary goal of that change was a.) adding support for dynamic modesetting and b.) making the code aware of multiple surfaces. In redream we create two windows in order to have two GL contexts so we needed to support that. I'm going to take a look at the joystick issues in a second.

AreaScout, thanks for this patch! I had it on my TODO list to handle but was having a hard time prioritizing it given that the Go isn't currently a supported platform for us (I had been testing various fixes to support it with krisvek over DM however).

Are you planning on upstreaming this soon?

[shanti]

I have tested all of these patches and I have not seen any screen tearing yet, I also applied a fix for the gamepad and it is now working on the latest SDL (found here) https://bugzilla.libsdl.org/show_bug.cgi?id=4966

Rotationg works beautifully! except for one game (VVVVVV), but I assume that is more with the game that with anything else.

Thanks @areascout and @crashoverride for the work!

[AreaScout]

Special thanks to all involved and to those who have teamed up all guys to came here in this forum thread - I mean that was teamwork !! I am impressed

Thanks for the code crashoverride now I understand it, the GPU kernel driver just needs three different buffers to handle tearing in the right way, right ?

@shanti

Tomorrow I will make a new patch and rebase with master for the input fix

@inolen

Are you really planing to support hw rotation for different SoC's in SDL2 mainline ?

RG

[inolen]

@AreaScout

Not an SDL dev, but there's vendor specific code for the Pi, etc. there already.

If this can be refactored to conditionally perform the rotation for the Go (bonus from me if the librgb was dlopen'd) I can't see why it wouldn't be considered.

[AreaScout]

@inolen

Crashoverride is hoarding all platform depended changes on Github https://github.com/OtherCrashOverride?tab=repositories, I don't think that there is a plan to upstream all of this, but SDL2 would make sense in theory, I can make a runtime detection for the Go2 (as you said dlopen found or not) or a build time detection of course.

@all

Later today I will release new SDL2.0.10 deb packages with the latest fixes for tearing, tearing was only visible on extensive GPU demanding applications (i.e PPSSPP) however I am super happy for the help from crash and want to provide packages for those who doesn't want to build SDL2 from source, for those of you who want to use 2.0.12 from the repositories with latest changes please wait a couple of days because there is a fix for inputs that I want to wait for and rebase on it

RG

[inolen]

Understood regarding the project-specific changes for projects which are rolling their own context creation, etc. Given SDL's purpose I believe these changes make sense there (especially given that they don't look invasive from a glance).

Redream statically links SDL2 which is why I advocate for dlopen (and many of SDL's dependencies do this). I don't have a Go, but if you get a change together I'd be glad to sanity check everything works well on other platforms still.

[shanti]

Later today I will release new SDL2.0.10 deb packages with the latest fixes for tearing, tearing was only visible on extensive GPU demanding applications (i.e PPSSPP) however I am super happy for the help from crash and want to provide packages for those who doesn't want to build SDL2 from source, for those of you who want to use 2.0.12 from the repositories with latest changes please wait a couple of days because there is a fix for inputs that I want to wait for and rebase on it

RG

I've been trying to also add the tearing fix to the patch you provided (thanks again) although I was able to add the changes that crashoverride provided, I get no video (also no error) when I run any SDL app, I want to keep using this older version as some games I use do not seem to work on the newish 2.0.10+ versions (mainly VVVVVV), do you think you could look at the patch I made and see what I am doing wrong? I am not much of a SDL developer so I am sure its something very stupid.

https://pastebin.com/RPrh07mR

Thanks! and sorry for the bother

[AreaScout]

@inolen

I have to think about it because the librga is not only used on Go2 RK3326, it is working also on other RK SoC's so there should be a configurable value for what rotation the user want's to have a.s.o, the changes we are using are small and it's easy for us to rebase on master but it looks that SDL2.0.10 will stay a good while in Ubuntu. We will see

@all

I have re-uploaded the libsdl2 package with tearing fixes inside, if you already installed it, please reinstall it new with:

Code: Select all

wget https://www.areascout.at/libsdl2-2.0-0_2.0.10+dfsg1-1ubuntu1_arm64.deb

sudo apt install ./libsdl2-2.0-0_2.0.10+dfsg1-1ubuntu1_arm64.deb --reinstall

If not follow the first post (install mali development headers + library)

@shanti

You probably missed this ?

Code: Select all

diff -r 0f7577d28c6c src/video/kmsdrm/SDL_kmsdrmopengles.c
--- a/src/video/kmsdrm/SDL_kmsdrmopengles.c	Wed Jan 01 08:13:40 2020 -0800
+++ b/src/video/kmsdrm/SDL_kmsdrmopengles.c	Sat Mar 07 12:25:44 2020 +0100
@@ -33,6 +33,9 @@
 #define EGL_PLATFORM_GBM_MESA 0x31D7
 #endif

+extern rga_info_t src_info;
+extern rga_info_t dst_info;
+
 /* EGL implementation of SDL OpenGL support */

 int
@@ -60,7 +63,7 @@
         return SDL_FALSE;
     }

-    fb_info = KMSDRM_FBFromBO(_this, wdata->crtc_bo);
+    fb_info = KMSDRM_FBFromBO(_this, vdata->rga_buffers[vdata->rga_buffer_index]);
     if (fb_info == NULL) {
         return SDL_FALSE;
     }

RG

[shanti]

@shanti

You probably missed this ?

Code: Select all

diff -r 0f7577d28c6c src/video/kmsdrm/SDL_kmsdrmopengles.c
--- a/src/video/kmsdrm/SDL_kmsdrmopengles.c	Wed Jan 01 08:13:40 2020 -0800
+++ b/src/video/kmsdrm/SDL_kmsdrmopengles.c	Sat Mar 07 12:25:44 2020 +0100
@@ -33,6 +33,9 @@
 #define EGL_PLATFORM_GBM_MESA 0x31D7
 #endif

+extern rga_info_t src_info;
+extern rga_info_t dst_info;
+
 /* EGL implementation of SDL OpenGL support */

 int
@@ -60,7 +63,7 @@
         return SDL_FALSE;
     }

-    fb_info = KMSDRM_FBFromBO(_this, wdata->crtc_bo);
+    fb_info = KMSDRM_FBFromBO(_this, vdata->rga_buffers[vdata->rga_buffer_index]);
     if (fb_info == NULL) {
         return SDL_FALSE;
     }

RG

*facepalm* This is why I shouldn't be looking at the screen with a cold :/ that was it! thank you!

[crashoverride]

the GPU kernel driver just needs three different buffers to handle tearing in the right way, right ?

The main issue, as previously described, is that with only a single RGA buffer, it is always displayed. Updates that occur outside the vertical blanking interval are visible (single buffered instead of double/triple buffered). This occurs regardless of whether the source is a GPU buffer.

[AreaScout]

@crash

That is what every book, teacher, wise man, internet page and wikipedia is telling about that, but the three buffers are not solving the tearing itself they are just counted round per round there is no real triple buffering done where we placed the code, this three buffers still contain frames/pictures with tearing, as far as I can tell the video output processor (VOP) or GPU has some let's say higher level hardware accelerated process to eliminate tearing and we just provide buffers for this process after we gave the frames to the VOP (or still GPU HW) they are processed and no tearing is left. This 'higher level' picture processing is started if drmModeSetCrtc is called at least once, if this is NOT called even with our three buffers the tearing would be visible.

You can test this by adding our patch to that revision https://github.com/bminor/SDL/blob/13a5 ... opengles.c and tearing will still be there. This is at least my conclusion

RG

[crashoverride]

"Tearing" is any update to the display that occurs while its in the process of being "scanned out" to the display. This can be updates to the framebuffer memory or updates to the display controller. To avoid "tearing" it is necessary to ensure updates only occur during the vertical blanking interval.

There is no higher level processing in the VOP or GPU to prevent tearing. The only "magic" is A) waiting for the vertical blanking interval to occur before updating the display, and B) ensure any and all updates are complete before the start of the next active display interval.

The SDL code does the following:
1) Copy and rotate the GPU rendered frame using RGA.
https://github.com/OtherCrashOverride/s ... c#L98-L119

2) Assuming this is not the first frame, tell the Linux kernel to display the RGA buffer at the next vertical blanking interval. This is asynchronous and execution continues immediately without waiting.
https://github.com/OtherCrashOverride/s ... les.c#L143

3) When the next frame is to be displayed, wait for the previous one that was scheduled to be displayed. This is synchronous and halts code execution until a vsync has occurred and the previous frame is displayed.
https://github.com/OtherCrashOverride/s ... gles.c#L84

4) The process from #1 above repeats using a different framebuffer each time. This is what prevents tearing since an active/displayed buffer is never used.

This meets the previously stated criteria in that A) a different buffer is written to leaving the currently displayed buffer unmodified, and B) KMSDRM_WaitPageFlip ensures the display controller update occurs and completes during the vertical blanking interval.

[edit]
I should also note that the above rendering technique used by SDL forces it to be double buffered. This is a performance killer since the main thread has to wait for the completion of the previous frame before continuing. The rendering technique used in libgo2 allows for true triple buffering: one frame is currently displayed, one frame is scheduled to be displayed, and one frame is being drawn/updated.

[maker_gamer]

Out of curiosity, who manages the http://deb.odroid.in/go2 repository? HardKernel @odroid, @crashoverride, @joy ?

A small request / proposal: can someone place sdl-go2 package (and sources for all) in the http://deb.odroid.in/go2 repository?
Of course there is dependency hell, so shouldn't sdl-go2 be placed in the go2 repo with the standard sdl2 package name so installing prboom, quake and other sdl2 ports will be happy?

In addition, although the sources are available via github, it would be nice to have the sources packages availble to match the binaries via a repo install. Though not as current as GitHub, folks would know if they compile anything using those sources it would work using the installed binaries.

I'm sure other besides myself want to try some porting & native compiles. Not being a hardcore C programmer, I want to make sure the Go Advance is stable firstly.

Making the following update to the System Image would set the go2 repo package as having priority -- making sure its sdl2 has precedence.

Code: Select all

# set standard ubuntu repos, remove go2 repo
echo 'deb http://ports.ubuntu.com/ubuntu-ports bionic main universe
deb http://ports.ubuntu.com/ubuntu-ports bionic-updates main universe
deb http://ports.ubuntu.com/ubuntu-ports bionic-security main universe' > /etc/apt/sources.list

# move Go Advance repo to separate managed list
echo 'deb http://deb.odroid.in/go2 bionic main
deb-src http://deb.odroid.in/go2 bionic main' > /etc/apt/sources.list.d/go2.list

# then pin Go Advance repo to have a higher priority
echo 'Package: *
Pin: release n=bionic
Pin-Priority: 900' > /etc/apt/preferences.d/go2-bionic-pin-900

Thank you for considering this. Cheers, M.

[crashoverride]

Out of curiosity, who manages the http://deb.odroid.in/go2 repository? HardKernel @odroid, @crashoverride, @joy ?

I know its not me.

There is an issue to resolve before SDL can be placed in a repo. SDL has a dependency on 2 other packages: libmali and librga. It will be necessary to ensure that the packaged version of SDL uses the correct dependencies. Currently, they are pulled from @meveric 's Debian repo. However, as part of the next update, I will be packaging them for Ubuntu. The package names and contents currently used are different from the packages I will provide.

[AreaScout]

There is an issue to resolve before SDL can be placed in a repo. SDL has a dependency on 2 other packages: libmali and librga. It will be necessary to ensure that the packaged version of SDL uses the correct dependencies.

That's super easy I can do that, I also can do the librga package, we already have a working mali package we do not have to reinvent the wheel on that, it's working very well, meveric has a lot of experience on packaging

RG

[cjv123]

@AreaScout

Does this affect other non-sdl software

[AreaScout]

@cjv123

No, it doesn't

RG

[jdorigao]

For knowledge!
Has anyone made these changes to version sdl2 2.0.12?

[AreaScout]

@jdorigao

Sure, deb package is 2.0.10 but source code is for 2.0.12, look here viewtopic.php?f=194&p=288900#p284753

RG

[jdorigao]

@AreaScout

Thank you!

We recently updated the sdl2 bo Batocera and I needed to update the patch and found what I needed in your git.

https://github.com/AreaScout/SDL/commit ... 3b254b0df7
https://github.com/batocera-linux/batoc ... /pull/1533

[PaulF8080]

I'm going to ask a stupid question. Why did you add the /dev/dri interface to SDL2? I'm trying to figure out SDL2 and it has renderers like OpenGL that use the GPU and the /dev/fb interface. What am I missing? All I wanted to do was move to SDL2 on an app and a simple thing has gone way over my head.

[crashoverride]

Why did you add the /dev/dri interface to SDL2?

The interface was added by SDL2. It is only modified to provide rotation transparently. The SDL2 behavior and API are otherwise unchanged.

[PaulF8080]

Why did you add the /dev/dri interface to SDL2?

The interface was added by SDL2. It is only modified to provide rotation transparently. The SDL2 behavior and API are otherwise unchanged.

Ahh. One missing piece. Thanks.

What do mean by "provide rotation transparently"? Do you swap X and Y widths?

I run from the serial debug console using the sdl in the first post above:

Code: Select all

#include "SDL.h"
int main(int argc, char* argv[])
{
    SDL_DisplayMode current;
    SDL_Init(SDL_INIT_VIDEO);
    int should_be_zero = SDL_GetCurrentDisplayMode(0, &current);
    if(should_be_zero != 0){
      // In case of error...
      SDL_Log("Could not get display mode for video display #%d: %s", 0, SDL_GetError());
      SDL_Quit();
    }
    Uint32 f = current.format;
    SDL_Log("Display #0\tbpp %i\t%s\t%i x %i",
    SDL_BITSPERPIXEL(f), SDL_GetPixelFormatName(f), current.w, current.h);
    SDL_Quit();
    return 0;
}

and get X and Y

Code: Select all

 ./display0mode 
librga:RGA_GET_VERSION:4.00,4.000000
ctx=0x558e2e8ea0,ctx->rgaFd=3
Rga built version:version:+2017-09-28 10:12:42
rk-debug mali-ver=rsx-p0-1.0
INFO: Display #0        bpp 32  SDL_PIXELFORMAT_ARGB8888        480 x 320

[crashoverride]

What do mean by "provide rotation transparently"? Do you swap X and Y widths?

It means the display is rotated 90 degrees (portrait to landscape) without any modifications to programs using SDL. The X and Y widths are swapped to reflect this.