Raspberry Pi OS Bookworm Released

Div1nus

@mitu said in Raspberry Pi OS Bookworm Released:

You've modified config.txt and removed the KMS overlay, but that results in an unsupported configuration/platform for Bookworm

If I use fake KMS instead of KMS, then in theory everything should work?
Just KMS doesn't allow my LCD screen to work.
And if it doesn't work out to compile with FKMS, is it possible to compile and install everything with KMS, and then switch to FKMS?
In any case, now I know exactly what the problem is. Thank you, I will try both ways and write about the result.

mitu

@Div1nus said in Raspberry Pi OS Bookworm Released:

Just KMS doesn't allow my LCD screen to work.

Are you sure ? KMS is the only supported way forward. FKMS doesn't offer you anything extra over KMS since - as said before - any old GPU libraries are no longer present in the OS.

Div1nus

@mitu Yes, I don't know why, but if "dtoverlay=vc4-kms-v3d" is enabled, nothing is displayed on the screen, only the backlight is on. Even though it seems all the necessary DPI parameters are specified. The screen only starts working if I comment out #dtoverlay=vc4-kms-v3d or if I use dtoverlay=vc4-fkms-v3d, but I need a 90-degree rotation, otherwise, the screen works vertically, and with fkms, the parameters display_rotate=1 and display_lcd_rotate=1 don't result in the screen rotating. However, I will try to experiment, because I just transferred the screen settings from the config.txt that came with the console purchase. And KMS was also commented out there... Maybe this is some kind of specific problem with the Chinese screen...

mitu

@Div1nus Take a look at this RPF topic - https://forums.raspberrypi.com/viewtopic.php?t=329872 - to see how you can configure such panel using the KMS overlays.

Div1nus

@mitu OMG! Thank you very much! Now I have a full KMS!

It was a little tricky, but I was able to convert my old parameters:

framebuffer_width=800
framebuffer_height=480
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=0x050227
dpi_timings=480 0 13 3 32 800 0 40 48 88 0 0 0 60 0 32000000 6
display_rotate=1
display_lcd_rotate=1
extra_transpose_buffer=2

In new:

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-dpi-generic,rotate=90,hactive=480,hfp=13,hsync=3,hbp=32
dtparam=vactive=800,vfp=40,vsync=48,vbp=88
dtparam=clock-frequency=32000000,bgr888
max_framebuffers=2

If anyone has the same GP430 console or DPI display with:
dpi_output_format=0x050227
dpi_timings=480 0 13 3 32 800 0 40 48 88 0 0 0 60 0 32000000 6

You can safely use the new parameters for kms, just replace the old parameters, they are no longer needed, with new ones, which are even more compact.

If you have a problem with colors and you don’t know how to correctly convert “dpi_output_format”, I haven’t really figured it out, just use the selection method.
Here is the list: rgb565, rgb565-padhi, bgr666, bgr666-padhi, rgb666-padhi, bgr888, rgb888.
These seem to be all the available options.

If your display doesn't require 90 degree rotation, remove "rotate=90".

And swap width and height, 480 and 800 in my example, if you have a vertical, not horizontal screen.

Documentation on the parameters is also available here: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html
If anyone needs it, search in the page using the keyword "vc4-kms-dpi-generic".

UPD:
After updating the kernel via rpi_update, rotation=90 stopped working no matter where I set it, so I went back to adding the parameter "fbcon=rotate:1" to the end of cmdline.txt.
In the emulationstation autostart .sh: --screenrotate 1 --screensize 800 480 #auto
In the retroarch.cfg add video_allow_rotate = "true" and video_rotation = "1".

mitu

@Div1nus said in Raspberry Pi OS Bookworm Released:

After updating the kernel via rpi_update, rotation=90 stopped working no matter where I set it, so I went back to adding the parameter "fbcon=rotate:1" to the end of cmdline.txt

Don't use rpi-update unless you want to test things - it shouldn't be used for normal updates. Normal kernel updates are automatically performed if you're upgrading via apt (apt update && apt full-upgrade).

Div1nus

@mitu You're right, it's just my habit, I always want to update everything to the latest version, no matter what it is. And this time it created another problem, you need to rotate cmd, ES and retroarch separately.

And doesn't this mean that the "rotation=" parameter may disappear in new versions?

mitu

You're right, it's just my habit, I always want to update everything to the latest version ...

rpi-update is NOT an update tool

And doesn't this mean that the "rotation=" parameter may disappear in new versions?

Wait until the next stable kernel version comes along and check to see if the parameter is still not working. If that's the case, check the documentation for the overlay you're using - it could have been renamed. If the parameter is valid, but not working, then open a topic in the Raspberry Pi forums and provide the configuration you're trying and it's not working.

rhino

Hi. I've just installed core packages on arm64 version of Pi OS. All went good but for some reason the script downgraded SDL2 package and put it on hold:

libsdl2-2.0-0:
  Installed: 2.26.3+1rpi
  Candidate: 2.26.5+dfsg-1
  Version table:
     2.26.5+dfsg-1 500
        500 http://deb.debian.org/debian bookworm/main arm64 Packages
 *** 2.26.3+1rpi 100
        100 /var/lib/dpkg/status

Is the version in bookworm not suitable for use in retropie? I noticed that it's linked a bit differently:

Version: 2.26.5+dfsg-1
Depends: libasound2 (>= 1.0.27), libc6 (>= 2.34), libdecor-0-0 (>= 0.1.0), libdrm2 (>= 2.4.47), libgbm1 (>= 8.1~0), libpulse0 (>= 0.99.1), libsamplerate0 (>= 0.1.7), libwayland-client0 (>= 1.20.0), libwayland-cursor0 (>= 1.18), libwayland-egl1 (>= 1.18), libx11-6 (>= 2:1.2.99.901), libxcursor1 (>> 1.1.2), libxext6, libxfixes3 (>= 1:5.0), libxi6 (>= 2:1.6.99.1), libxkbcommon0 (>= 0.5.0), libxrandr2 (>= 2:1.2.99.3), libxss1

Version: 2.26.3+1rpi
Depends: libc6 (>= 2.34), libudev1, libdbus-1-3

mitu

@rhino said in Raspberry Pi OS Bookworm Released:

Is the version in bookworm not suitable for use in retropie? I noticed that it's linked a bit differently:

On a Pi (and a few other SBC platforms) RetroPie has always compiled its own version of SDL and set the package(s) on hold to prevent overwriting.

rhino

@mitu Ok that is fine but I wanted to know what's the reason for it and whether it's still valid.

mitu

@rhino said in Raspberry Pi OS Bookworm Released:

.. what's the reason for it and whether it's still valid.

The reason is we have a few SDL patches specific to RetroPie which we maintain, so we have a separate SDL package. And yes, it's still valid. We update the version of our patches along with SDL, so at some point it's not going to be an isssue when the SDL version will be bumped in our package.

rhino

@mitu This is very interesting can you please elaborate what exactly is being patched in retropie version? The version number is not a problem but the fact that it's linked so differently (possibly patches themselves) is likely to cause problems with system software. E.g. mpv and VLC are no longer capable to play movies in the console with the replaced lib. Is there a solution to this?

mitu

@rhino said in Raspberry Pi OS Bookworm Released:

E.g. mpv and VLC are no longer capable to play movies in the console with the replaced lib. Is there a solution to this?

I don't think that's an issue caused by SDL. You can find the patches included in RetroPie's SDL in the Github repository here.

rhino

@mitu Ups sorry turns out it was just me messing up my system. Both players continue to work without problems.

You can find the patches included in RetroPie's SDL in the Github repository here.

Ok so just a handful of commits at the top?

https://github.com/RetroPie/SDL/compare/adf31f6ec0be0f9ba562889398f71172c7941023...retropie-2.26.3