Difference between revisions of "About RGB-Pi and Raspberry Pi4"

From RGB-Pi Wiki
Jump to: navigation, search
(Created page with "==RGB-Pi Statement of Direction - Raspberry Pi4== As many of you are asking whether the RGB-Pi devices will be supporting the latest Raspberry Pi4 models, we wanted to clarif...")
 
Line 1: Line 1:
−
==RGB-Pi Statement of Direction - Raspberry Pi4==
+
==RGB-Pi in Raspberry Pi4 and Beyond==
  
 
As many of you are asking whether the RGB-Pi devices will be supporting the latest Raspberry Pi4 models, we wanted to clarify some points here:
 
As many of you are asking whether the RGB-Pi devices will be supporting the latest Raspberry Pi4 models, we wanted to clarify some points here:
−
* From the GPIO specifications point of view, all current RGB-Pi devices are 100% compatible with Raspberry Pi4.
+
* From the GPIO specification point of view, all current RGB-Pi devices are 100% compatible with Raspberry Pi4.
−
* From the software perspective, we have stomped to a big wall that prevents us from making the different system timings work.
+
* From the software perspective, the introduction of the new VideoCore6 and FKMS/KMS video drivers are preventing us using from using the current on the fly resolution mode switch.  
  
−
==Tests & Tech Facts==
+
==About Raspberry Video Drivers==
  
−
After several days of work, we had success on porting our frontend to the Pi4. The problems arose when testing the games, at that point we faced some issues on executing Retroarch (the system hanged with a lovely black screen). After some research, with found out that the problem was caused by the dynamic timing mechanism, that it is now not operative due to the move from the old vc4 graphic chip to the new vc6 which uses a new video driver.
+
* Legacy - up to Pi3, Raspberry used a custom video driver that communicated directly to the firmware (which only had a custom implementation of OpenGL ES) and had direct access to the framebuffer. This is now legacy and not fully supported in Pi4 anymore.
 +
* FKMS (Fake/Firmware KMS) - uses the custom Dispmanx API to communicate with the firmware. It is the new default driver for Pi4 and does not support the use of framebuffer changes via fbset, tvservice or vcgencmd commands.
 +
* KMS - the kernel communicates directly to the hardware registers bypassing the firmware. As of today, this is the standard industry driver and the one that will become the default driver in all future Pi models once its development is fully finished.
  
−
A brief explanation on the different graphic drivers on Raspberry Pi:
+
==Issues==
−
* Legacy - up to Pi3, Raspberry used a custom video driver that communicated directly to the firmware (which only had a custom implementation of OpenGL ES) and had direct access to the framebuffer. This is now legacy and not fully supported in Pi4 anymore (you lose 3D acceleration/OpenGL among others).
 
−
* FKMS (Fake/Firmware KMS) - uses the custom Dispmanx API to communicate with the firmware. It is the new default driver for Pi4 and does not manage well the framebuffer via fbset or tvservice commands.
 
−
* KMS - the kernel communicates directly to the hardware registers bypassing the firmware.
 
  
−
==Current Tech Scenario==
+
===Frontend===
 +
 
 +
* The current frontend makes use of Pygame SDL1 and surface objects. Since the release of Pygame SDL2, the current UI performs terrible due to unknown reasons. This results in the UI barely running at 4 FPS and 100% of CPU use.
 +
* The ALSA audio drivers have been changed to make some of the internal virtual devices comply with the standard naming and configuration, resulting in some current audio features like EQ broken.
 +
* Raspberry USB PCI hub descriptors and sorting has also changed resulting in controller ordering not matching with Retroarch anymore.
 +
 
 +
===Device Tree Overlay .dtbo===
 +
 
 +
* The current device descriptor is not compatible/working anymore in KMS/DRI mode
 +
 
 +
===Video Driver and Timings===
  
 
* As stated by Raspberry Pi engineers, a full KMS driver for Pi4 is being worked on by a subcontractor, and will be mainlined in the future.
 
* As stated by Raspberry Pi engineers, a full KMS driver for Pi4 is being worked on by a subcontractor, and will be mainlined in the future.
 
* Pi4 still has the same DPI, DSI, and VEC blocks. The HVS and HDMI blocks have significant updates, and the pixel valve routing has been changed.
 
* Pi4 still has the same DPI, DSI, and VEC blocks. The HVS and HDMI blocks have significant updates, and the pixel valve routing has been changed.
−
* The I2C block connected to the HDMI ports is different from previous versions, which is the most likely reason not to get any usable modes if you try enabling it.
+
* The I2C block connected to the HDMI ports is different from previous versions.
−
* Disabling FKMS  driver in Pi4 results in the following issues:
+
* Using the old legacy driver in Pi4 results in the following issues:
 
** fbset only works in 32 bit depth mode
 
** fbset only works in 32 bit depth mode
 
** fbset is not able to properly change the framebuffer size, hanging or setting a virtual resolution instead
 
** fbset is not able to properly change the framebuffer size, hanging or setting a virtual resolution instead
−
** tvservice only works with composite and HDMI
+
** tvservice/vcgencmd only works with composite and HDMI
 +
* Using the new KMS video driver results in the following issues:
 +
** Custom timings (drm modes) are not supported when using GPIO DPI
 +
** When using DPI, there is not edid information available
 +
** Neither tvservice nor vcgencmd are supported by any means
 +
 
 +
===Additional Misc. Blocking Issues===
 +
 
 +
* SDL2 version provided by Raspbian not being compatible with SDL2 in CLI with no X
 +
* Image formats and True Type font modules not supported in SDL2 Pi version
 +
* Changes in config.txt
 +
 
 +
==Current Status==
 +
 
 +
===Frontend===
 +
 
 +
* A new fully refactored UI based on Sprites is being developed. Current pre-Alpha is working properly in both SDL1 software render, and SDL2 hardware accelerated mode. There is a bug in Pygame SDL2 that prevents us from reinit the video while the frontend is running that is already addressed by Pygame development team. Since Pygame SDL2 still has issues with software rendering, we will continue using the current Pygame SDL1 in soft. mode until the patch arrives and we can migrate to the new SDL2 hard. accel. version.
 +
* All issues with ALSA audio have been resolved.
 +
* USB ordering engine have been updated, so it is working properly again. When the migration to SDL2 is feasible, a refactor of this module will be required due to changes in the way SDL2 works with joysticks as compared with SDL1.
 +
 
 +
===Device Tree Overlay .dtbo===
 +
 
 +
* A new universal custom .dtbo has been created to support all DPI RGB addons. The same is already working properly in KMS mode.
 +
 
 +
===Video Driver and Timings===
 +
 
 +
* KMS driver is almost complete and working properly in Raspberry Pi4.
 +
* Retroarch is now also working properly with KMS video driver.
 +
* A new custom kernel module has been created to provide a bridge between KMS and DPI, and also provide a full timing database (due to edid lack).
 +
* A new kernel patch has been created to support interlaced (480i) resolutions.
 +
* A new feature was introduced in Retroarch to support manual video mode switch via special configuration file.
 +
 
 +
===Additional Misc. Blocking Issues===
  
−
==Conclusions==
+
* Retropie SDL2 compilation is now fully working in pure CLI mode.
 +
* We now only use sprite based fonts and indexed BMP image formats so no more compatibility or performance issues will be faced in this regard in the future.
 +
* All config.txt issues were addressed.
  
−
* We must wait some time until all these changes be mainlined in the Raspberry kernel drivers.
+
==Final Words==
−
* Even if KMS works as expected, we will be forced to create a brand new RGB-Pi dtbo containig all available timings in advance.
 
−
* It is probable that timing changes won't be feasible from CLI (no X) anymore but using xrandr over X env, which would leade us to use a Xorg layer and create a new UI based on whatever is required at that point.
 
  
−
So, unfortunately, do not expect anything on Raspberry Pi4 in the short/medium term.
+
A lot of work and improvements have been done and still much more is still pending, but the current status looks promising.
 +
Do note that we are in direct discussions with many of top people in the scene for making all this things a reality in the mid term. Some of the people involved are Cpasjuste, Alphanu, Substring, Calamity, robertpfeiffer, digitalLumberjact and of course me (rTomas) and aTg from RGB-Pi team.
  
 
To be continued...
 
To be continued...

Revision as of 12:21, 12 August 2021

RGB-Pi in Raspberry Pi4 and Beyond

As many of you are asking whether the RGB-Pi devices will be supporting the latest Raspberry Pi4 models, we wanted to clarify some points here:

  • From the GPIO specification point of view, all current RGB-Pi devices are 100% compatible with Raspberry Pi4.
  • From the software perspective, the introduction of the new VideoCore6 and FKMS/KMS video drivers are preventing us using from using the current on the fly resolution mode switch.

About Raspberry Video Drivers

  • Legacy - up to Pi3, Raspberry used a custom video driver that communicated directly to the firmware (which only had a custom implementation of OpenGL ES) and had direct access to the framebuffer. This is now legacy and not fully supported in Pi4 anymore.
  • FKMS (Fake/Firmware KMS) - uses the custom Dispmanx API to communicate with the firmware. It is the new default driver for Pi4 and does not support the use of framebuffer changes via fbset, tvservice or vcgencmd commands.
  • KMS - the kernel communicates directly to the hardware registers bypassing the firmware. As of today, this is the standard industry driver and the one that will become the default driver in all future Pi models once its development is fully finished.

Issues

Frontend

  • The current frontend makes use of Pygame SDL1 and surface objects. Since the release of Pygame SDL2, the current UI performs terrible due to unknown reasons. This results in the UI barely running at 4 FPS and 100% of CPU use.
  • The ALSA audio drivers have been changed to make some of the internal virtual devices comply with the standard naming and configuration, resulting in some current audio features like EQ broken.
  • Raspberry USB PCI hub descriptors and sorting has also changed resulting in controller ordering not matching with Retroarch anymore.

Device Tree Overlay .dtbo

  • The current device descriptor is not compatible/working anymore in KMS/DRI mode

Video Driver and Timings

  • As stated by Raspberry Pi engineers, a full KMS driver for Pi4 is being worked on by a subcontractor, and will be mainlined in the future.
  • Pi4 still has the same DPI, DSI, and VEC blocks. The HVS and HDMI blocks have significant updates, and the pixel valve routing has been changed.
  • The I2C block connected to the HDMI ports is different from previous versions.
  • Using the old legacy driver in Pi4 results in the following issues:
    • fbset only works in 32 bit depth mode
    • fbset is not able to properly change the framebuffer size, hanging or setting a virtual resolution instead
    • tvservice/vcgencmd only works with composite and HDMI
  • Using the new KMS video driver results in the following issues:
    • Custom timings (drm modes) are not supported when using GPIO DPI
    • When using DPI, there is not edid information available
    • Neither tvservice nor vcgencmd are supported by any means

Additional Misc. Blocking Issues

  • SDL2 version provided by Raspbian not being compatible with SDL2 in CLI with no X
  • Image formats and True Type font modules not supported in SDL2 Pi version
  • Changes in config.txt

Current Status

Frontend

  • A new fully refactored UI based on Sprites is being developed. Current pre-Alpha is working properly in both SDL1 software render, and SDL2 hardware accelerated mode. There is a bug in Pygame SDL2 that prevents us from reinit the video while the frontend is running that is already addressed by Pygame development team. Since Pygame SDL2 still has issues with software rendering, we will continue using the current Pygame SDL1 in soft. mode until the patch arrives and we can migrate to the new SDL2 hard. accel. version.
  • All issues with ALSA audio have been resolved.
  • USB ordering engine have been updated, so it is working properly again. When the migration to SDL2 is feasible, a refactor of this module will be required due to changes in the way SDL2 works with joysticks as compared with SDL1.

Device Tree Overlay .dtbo

  • A new universal custom .dtbo has been created to support all DPI RGB addons. The same is already working properly in KMS mode.

Video Driver and Timings

  • KMS driver is almost complete and working properly in Raspberry Pi4.
  • Retroarch is now also working properly with KMS video driver.
  • A new custom kernel module has been created to provide a bridge between KMS and DPI, and also provide a full timing database (due to edid lack).
  • A new kernel patch has been created to support interlaced (480i) resolutions.
  • A new feature was introduced in Retroarch to support manual video mode switch via special configuration file.

Additional Misc. Blocking Issues

  • Retropie SDL2 compilation is now fully working in pure CLI mode.
  • We now only use sprite based fonts and indexed BMP image formats so no more compatibility or performance issues will be faced in this regard in the future.
  • All config.txt issues were addressed.

Final Words

A lot of work and improvements have been done and still much more is still pending, but the current status looks promising. Do note that we are in direct discussions with many of top people in the scene for making all this things a reality in the mid term. Some of the people involved are Cpasjuste, Alphanu, Substring, Calamity, robertpfeiffer, digitalLumberjact and of course me (rTomas) and aTg from RGB-Pi team.

To be continued...

Retrieved from "https://www.mortaca.com/rgb-pi/wiki/index.php?title=About_RGB-Pi_and_Raspberry_Pi4&oldid=40973"