-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raspberry Pi 5 - KMSDRM driver / garbage displayed when drawing to framebuffer (no X11 / Wayland) - reverting to ATOMIC kmsdrm driver commit range works #8579
Comments
I'll see if I can take the merged kmsdrm code I did awhile ago and get it working again. Putting this in the 2.30.0 milestone since that's going to be most urgent for Pi5 users and has a conveniently-soon deadline. |
@icculus I'm not sure there's an issue with the SDL2 version. FWIW, RetroPie uses SDL2 under KMS/DRM almost exclusively (the front-end, EmulationStation, is a SDL2 app using OpenGL/GLES) and we haven't got complaints from users on latest RaspiOS & Pi5 trying out RetroPie. The version we use distribute right now is 2.26.3, but I don't think anything changed w.r.t. KMS/DRM on the SDL2 branch. @tekker are you sure you're getting this errors with the MESA distributed with RaspiOS ? Which SDL versions are you testing ? |
@vanfanel Apologies, I don't have my pi5 for the next week and unfortunately can't test the fixes of the last 2 days. Regarding whether this is a SDL2 problem - from memory glmark2-es2 master built against MESA has the same result (garbage displayed I think) whereas current kmscube master runs correctly. What I noticed was that for a brief fraction of a second after killing the test executable (ie. testdraw2), just before returning to kms console, the correct image was displayed onscreen. @cmitu This was tested against current SDL master at 19/11/23. After testing latest SDL master, tested latest release version with same result. I avoided testing on RetroPie / RaspiOS, this was tested using a set of docker images running on latest LibreELEC nightly images for RPI5 and disabling all Kodi systemd so that I have direct access to DRM - apologies I can't send a copy of the docker files to reproduce as I don't have the Pi5 with me this week. This approach was based on minimal modifications from working Docker KMSDRM libdrm/ligglvnd/mesa/SDL2 build for Pi4 on LibreELEC nightly with Kodi systemd disabled. SDL master was built using:
@icculus I did confirm this issue was occurring with latest libdrm git and using mesa distributed with RpiOS built via
|
This is exactly the same issue I'm having with KMS driver trying to run Dosbox from framebuffer on Raspberry Pi 5. I compiled Dosbox (3 versions) in Raspberry Pi 4 with Bookworm Lite and run from console in framwbuffer, everything worked 100% but as soon as I moved microSD to Raspberry Pi 5 and did run Dosbox, all i got is a white garbage screen with a mouse pointer. Then trying to exiting from DosBox caused for half a second to see the buffer correctly before to come back to command line. |
@appnjoy Please test against latest MESA Git code, there have been fixes for Wayland / KMSDRM on the Pi5 in the last few days. |
@vanfanel Tested against latest git mesa / libdrm etc, with similar issues - garbage displayed looks a lot different (looks a bit like white-ish noise) than previous mesa build, with the same effect of correct image displaying briefly on exit . @appnjoy I can verify that the cursor is displayed OK on some tests as well, and the buffer displaying for a fraction of a second when exiting. The SDL automation test produces errors along these lines (same as previous mesa latest git)
EDIT: This probably should be ignored as these automation tests fail on Pi4 as well (video_setWindowCenteredOnDisplay), maybe due to no WM |
For reference, here is the Dockerfile I have been using for testing RPI5 KMSDRM. The mesa git upstream is commented out to test with current Raspi OS package'd mesa in this version.
which is built using
and run with
The visual artificacts are the same as in the above issue at BlitterStudio/amiberry#1189 |
Unsure if it's related, but hoping it helps as I was the one submitting the issue referenced above: the artifacts didn't present themselves when launching the application from the terminal. They only manifested themselves when launching the application from specific code paths (that used to work in previous scenarios) and that we're troubleshooting there. I do confirm that the mouse pointer renders correctly, and after back and forth in recompiling code and updating dependencies I also get the "white-ish noise", as you describe. Check if the same. See video. 2023-11-29.11-46-43.PIMG_1918.movOnce again, unsure where the issue lies, but thought I'd share for everyone to be on the same page and decide whether this is relevant to the topic or not. |
-- Final update for now: this was found to be related to VSync, in the other thread |
I can confirm that starting from scratch with fresh Raspbian OS install (ie. not using Docker at all), the same issue (garbage on framebuffer with KMSDRM only when not using ATOMIC glmark2-es2-drm, SDL drawchessboard etc) is present. This is using current mesa as distributed with Raspbian, I have yet to test with Mesa upstream in this environment. Using the same build scripts as taken from Dockerfile in this issue. This issue is specific to KMSDRM only (ie. Wayland / Vulkan have no problems at all). It's definitely not a SDL issue, only created the issue here due to the set of commits for Atomic modesetting in SDL which vanfanel created avoids the framebuffer corruption. |
Hello I have similar issues with a KIVy application as well. I recently upgraded one of my Pis to to bookworm and in the process also had to update the Kivy GUI to run with python-3.11. Since the distribution includes the kivy packageI just simply installed it, which also pulled in the SDL dependency (2.26.5+dfsg-1 in this case). I started my GUI application and the whole screen was garbled. Then I remembered that I build SDL manually ages ago when I first started developping the app (2.0.10). I installed this version in /usr/local and then compiled an older version of kivy linking against that. After that the application started working again without any issues. I can try and bisect of when the breakage happened for me, but maybe someone can give me some ideas at which version I should start. |
You can probably start bisecting on major releases. They should be backwards compatible, so you can just step through newer versions until it breaks. |
I started doing this..
Im now bisecting between 2.0.16 and 2.0.14 |
A simple revert was not possible. It tried to revert this commit in 2.0.16 but it did not completely work (the screen froze). The display looked fine though before it froze. |
Ok there are two many changes and for me a simple revert is indeed not possible. That said the commit which enables async flip support definitely breaks it for me, while the commit before works fine. |
I found an easier way for testing. SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c Line 961 in 0582133
So it seems that SDL is not the problem, but the async pageflip support for my setup is not working. With older SDL versions it just does not happen because they do not support it. |
@slouken This is, indeed, a MESA, libDRM or kernel problem, regarding |
@vanfanel for your information I can reproduce this on a rpi4, just saw that I did not mention this earlier. |
@maru-sama Hadn't seen that! So, when did SDL2(KMS/DRM) break on the Pi4 and 5? I haven't used anything on KMS/DRM for the last year or so. |
I updated to bookworm which installed a new Sdl version that enables async page flip. This breaks my kivy application I have running at home. If I hardcode no async page support in the Sdl lib it works fine. |
@maru-sama Ok, this is a MESA problem, I have modified my report (I don't have a Pi4 here to test), so let's see what they find out. |
It's not a SDL problem, Dosbox-SVN, DosBox-ECE use SDL1 and DosBox'X SDL2, all of them work w/out any problem on Raspberry Pi 4 with Bookworm and KMS driver, I had garbage problem only on Raspberry Pi 5. |
@appnjoy Garbage on framebuffer only appeared on Pi5 for me as well. |
@maru-sama Against current SDL master and current MESA master, the garbage framebuffer issue is resolved for me with the async pageflip modifucation to SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c. 👍 This is on Pi 5. I am limiting testing to SDL demos, ie. testdraw, testgles2, testsprite, testyuv. In Pi5, with asyncpageflip=false, verything looks reasonably OK in KMSDRM except for maybe some minor tearing on testgles2 demo. Demos still work fine in Vulkan, Wayland. These do also work on Pi4 latest mesa / sdl master for me (without needing async pageflip disabled in the SDL_kmsdrmvideo), except for superfast cube (thousands of FPS) with testgles2, not sure what is causing that. EDIT: @maru-sama Disabling asyncpageflip resolves this issue as well in Pi 4. |
The same issue with framebuffer corruption against current MESA using KMSDRM can be seen with glmark2 (https://github.com/glmark2/glmark2) Following @maru-sama changes for SDL, disabling async page flip in glmark2 source resolves the framebuffer corruption issue, glmark2-es2-drm now displays correctly on RPI 5. |
@tekker I could replicate that on my Pi5, and passed that information to the MESA people. Thanks a lot for not only reporting the issue but going down to the cause! I am sure it will be fixed soon. |
No worries @vanfanel thank you for all your effort :) |
Happening with pygame using the kmsdrm driver on a raspberry pi 5 using the lite os (no display environment) as well! |
Okay, we're all in agreement this isn't an SDL issue, so I'm going to close this unless new information comes up that says otherwise. Thanks to everyone that researched this so thoroughly! |
In case anyone's looking for manually patched libsdl2 packages with @maru-sama's hardcoded fix, here they are. Made pygame work perfectly for me perfectly on a Raspberry Pi 5 using the KMSDRM driver. Included packages are:
|
Thank you very much for sharing this :) Unfortunately I solve the problem halfway, just for Dosbox-X (compiled against SDL2) because I have the same problem with Dosbox-SVN and Dosbox-ECE on Raspberry Pi 5 compiled against SDL1. Is there any patched version of SDL1 that fix the issue? Thanks |
@vanfanel, what's the implication of turning off async page flip? Is this something we can/should do for the next SDL release? |
@icculus I am not interested on tearing, so yeah, go for it, disable async pageflip, nothing worth will be lost. |
I believe this problem is no longer reproducible when using kernel 6.7 [1]. [1] https://github.com/raspberrypi/linux/tree/rpi-6.7.y |
Since there's an upstream fix coming, I'm going to go ahead and mark this as closed. If anybody runs across this, there are packages built with the workaround available above. |
Hi, SDL kmsdrm driver displays garbage when drawing to rpi5 framebuffer (testing without X11 or Wayland). When compiling against either current builds of libdrm / mesa git or against the version in the Raspberry Pi 5 OS distributed with the board (Bookworm). While SDL (latest git version) compiles correctly without errors, there are a small number of automation test failures.
Running the test binaries testdraw, testgles2 etc display garbage however when exiting the app for a fraction of a second the actual correct frame is displayed. The testvulkan demo however works correctly with KMSDRM.
Using @vanfanel commits at commit [KMS/DRM] Small readability changes., the drawing routines complete correctly and everything seems to work OK, including testgles2, testdraw etc.
I don't have much experience with SDL or DRM (or graphics subsystem) but looks like using the ATOMIC modesetting & use of planes etc may be needed for PI5 compatibility (this is the approach kmscube uses, which displays correctly on Pi5).
The text was updated successfully, but these errors were encountered: