RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    sdltrs: display of typed characters lags keyboard, sometimes permanently by one character

    Scheduled Pinned Locked Moved Help and Support
    sdltrsdisplay
    37 Posts 4 Posters 3.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      JenGun @mitu
      last edited by

      @mitu Thanks for testing and adding sdl2trs to RetroPie! :-)

      My temporary workaround that I found was to force trs_sdl_flush to redraw, by ignoring the drawnRectCount check (which seems to work also, but obviously not correct) and my next step was to investigate why the check fails - in some cases - with KMSDRM.

      That was also my first try, but the emulator screen was not redrawn after leaving the TextGUI. It will also burn some CPU cycles ... ;-)

      Sometimes the screen is not updated in Wayland after resizing, but for now the patch is committed: https://gitlab.com/jengun/sdltrs/-/commit/a817f5e817db7166a4654fa735a4abb848534a45

      N 1 Reply Last reply Reply Quote 1
      • N
        n2185x @JenGun
        last edited by

        @JenGun Thanks very much for showing up with a fix. This is excellent.

        It does raise a question, however: does the change actually qualify as a fix to a bug in sdl2trs, or is this a workaround to a bug that is elsewhere?

        I think it's at least somewhat important. If you read my comments above, you'll see that a similar issue occurs with respect to the hatari gui. This suggests that the real bug is downstream of sdl2trs. It might be in SDL itself, or it might even be downstream of that. No idea. As long as the fix here is benign then it's all good, but if there's any way to use this to discover where the real bug is, it might be worth pursuing.

        Thanks again for the fix, it's greatly appreciated!

        J 1 Reply Last reply Reply Quote 0
        • J
          JenGun @n2185x
          last edited by JenGun

          @n2185x

          It does raise a question, however: does the change actually qualify as a fix to a bug in sdl2trs, or is this a workaround to a bug that is elsewhere?

          Good question ... I would cautiously refer to it as a "workaround": the error only seems to occur on a few systems and why RenderClear fixes it is not entirely clear to me ... maybe this will flush the render command queue ...

          Something similar happens here on another machine: the SDL window turns completely white after a few seconds. An old version (SDL 2.0.9) fixes the problem ... with newer versions a superfluous SDL_RenderDrawPoint is needed after SDL_UpdateTexture ...

          In hatari the RenderClear command is also "missing", so the fix might also apply:

          diff --git a/src/screen.c b/src/screen.c
          index 32765a48..a609ca34 100644
          --- a/src/screen.c
          +++ b/src/screen.c
          @@ -115,6 +115,7 @@ void SDL_UpdateRects(SDL_Surface *screen, int numrects, SDL_Rect *rects)
                  if (bUseSdlRenderer)
                  {
                          SDL_UpdateTexture(sdlTexture, NULL, screen->pixels, screen->pitch);
          +               SDL_RenderClear(sdlRenderer);
                          SDL_RenderCopy(sdlRenderer, sdlTexture, NULL, NULL);
                          SDL_RenderPresent(sdlRenderer);
                  }
          
          1 Reply Last reply Reply Quote 1
          • mituM
            mitu Global Moderator
            last edited by

            @JenGun this does seem to improve things, at least for the Hatari menu. For the record, RetroPie includes libSDL2 2.0.10.

            J 1 Reply Last reply Reply Quote 0
            • J
              JenGun @mitu
              last edited by

              @mitu It makes the SDL GUI work in Wayland. Replacing SDL_RenderClear with SDL_RenderDrawPoint also seems to fix the issue ...

              J 1 Reply Last reply Reply Quote 0
              • J
                JenGun @JenGun
                last edited by JenGun

                The issue in hatari is also fixed upstream:
                https://github.com/hatari/hatari/commit/191a35fe24b340be143e9a368698123cdf0280b7

                mituM 1 Reply Last reply Reply Quote 1
                • mituM
                  mitu Global Moderator @JenGun
                  last edited by

                  @JenGun Thank you for submitting the patch. We may have to include it locally before a new Hatari release.

                  BuZzB J 2 Replies Last reply Reply Quote 0
                  • BuZzB
                    BuZz administrators @mitu
                    last edited by BuZz

                    @mitu the last release was some time ago (2019 afair) so I was going to maybe try out git HEAD version. But maybe a new release will be out soon also and we can just do a patch.

                    To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                    J 1 Reply Last reply Reply Quote 0
                    • J
                      JenGun @mitu
                      last edited by JenGun

                      @mitu Sorry, the URL was malformed. They use SDL_RenderClear only for hardware accelerated cards to avoid the problem. If the Renderer falls back to SW rendering (for whatever reason), it will break again ...

                      1 Reply Last reply Reply Quote 0
                      • J
                        JenGun @BuZz
                        last edited by

                        @BuZz

                        But maybe a new release will be out soon also and we can just do a patch.

                        Seems they are preparing to release version 2.3 ...

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post

                        Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                        Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.