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...")
 
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
==RGB-Pi Statement of Direction - Raspberry Pi4==
+
<languages/>
 +
<translate>
  
 +
==RGB-Pi in Raspberry Pi4 and Beyond== <!--T:1-->
 +
 +
<!--T:2-->
 
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/Pi400.
−
* 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 KMS video driver, made impossible to use the old way of changing resolutions via firmware custom driver.
 +
 
 +
 
 +
==About Raspberry Video Drivers== <!--T:3-->
 +
 
 +
<!--T:4-->
 +
* 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 was the default Pi4's driver for some time, and did 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 video driver and the new default driver in all current and future Pi models.
 +
 
 +
 
 +
==Development Status== <!--T:5-->
 +
 
 +
 
 +
===Frontend=== <!--T:6-->
 +
 
 +
<!--T:7-->
 +
* The frontend, which makes use of Pygame SDL1 and surface objects, has been remade from scratch to avoid the performance issues that suffered in Pi4 due to changes in video libraries. Now it is sprite based and it is prepared to be easily migrated to Pygame SDL2. There is a bug in Pygame SDL2 that prevents us from reinit the video while the frontend is running. This issue is currently being addressed by Pygame development team.
 +
* The ALSA audio drivers was changed to make some of the internal virtual devices comply with the standard naming and configuration That resulted in some audio features like EQ and audiojack broken. All issues with ALSA audio have been resolved.
 +
* Raspberry USB PCI hub descriptors and sorting has changed resulting in controller ordering not matching with Retroarch anymore. Also RetroArch changed their sorting engine. After some work on our controller engine, it is now already fully adapted to match all these changes.
 +
 
 +
 
 +
===Video Driver and Timings=== <!--T:8-->
 +
 
 +
<!--T:9-->
 +
* The new KMS driver is now finished and working.
 +
* A new Device Tree Overlay .dtbo has been created to make it 100% KMS compatible.
 +
* A new custom kernel module has been created to provide a bridge between KMS and DPI.
 +
* A new custom kernel has been created to support interlaced (480i) resolutions.
 +
* A new custom kernel has been created to support native CSYNC.
 +
* A new custom RetroArch has been created to support KMS and the new custom DynaRes video subsystem (more info in the 'New Features' section down below).
 +
 
 +
 
 +
==New Features== <!--T:10-->
 +
 
 +
 
 +
===DynaRes=== <!--T:11-->
 +
 
 +
<!--T:12-->
 +
[[File:Dynares.gif|File:Dynares.gif]]
  
−
==Tests & Tech Facts==
+
<!--T:13-->
 +
We have developed a custom version of RetroArch which includes a new video subsystem (DynaRes) to fully manage all the video modes and options. the main features of DynaRes are the following ones:
 +
* Does not require any external timings database.
 +
* Can set the proper resolution and native refresh rate, as provided by the core, when launching games.
 +
* Can change the resolution on the fly as requested by the core/game while playing.
 +
* Support different monitor types (15khz, 25khz, 31khz, etc.)
 +
* Timings calculated based on Calamity switchres.
 +
* Automatic H and V image positioning and centering.
 +
* Has different working modes (all of them using native refresh rates):
 +
** Native: games will run on native H and V resolutions. On the fly timing changes will happen on both H and V resolution changes. This is recommended if your priority are arcade games, when using real arcade monitors (specially for 25/31kHz), or if you plan to capture video.
 +
** SuperX: games will run on native V resolution. H resolution is super res dynamically calculated using integer scale with 8px of overscan. On the fly timing changes will happen only on V resolution changes. This is recommended in most of the cases for 15kHz TVs, specially for playing PSX games.
 +
** Custom Fixed: games will run in a fixed resolution. This is useful for scenarios like Dreamcast 240p/480i, or TATE games played rotated.
 +
** Handheld Full: systems like GBA and NGP can be displayed in special fullscreen mode.
  
−
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.
 
  
−
A brief explanation on the different graphic drivers on Raspberry Pi:
+
===Lightgun=== <!--T:14-->
−
* 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==
+
<!--T:15-->
 +
[[File:Lgun.gif|File:Lgun.gif]]
  
−
* 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.
+
<!--T:16-->
−
* 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.
+
We have developed a custom driver to support original Namco GunCon 2 lightgun. Currently, only original blue(EU), black(JP) and orange(US) original guns are supported. We are working on supporting clones and original XBOX gun in the future if feasible.
−
* 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.
+
It is very important to know that there are 4 different kinds of gun games based on the hardware they used. While nothing prevents us on playing any of them, different results could be faced:
−
* Disabling FKMS  driver in Pi4 results in the following issues:
+
* Lightgun blanking based. The main example is the NES Zapper. These games play really well. Some cores like Genesis Plus GX do not provide any precision adjustment, so SMS games for instance become more challenging.
−
** fbset only works in 32 bit depth mode
+
* Lightgun beam read based. The main example is PSX GunCon. These games work and play perfectly fine.
−
** fbset is not able to properly change the framebuffer size, hanging or setting a virtual resolution instead
+
* Lightgun + IR receiver based. Sega Menacer is the main example. These games play well as long as they do not have big black areas. An example of game that do not work well is Megadrive T2 the Arcade. The sky in this game is black, so the gun cannot read the beam. On the other hand, SNES version which is prepared for beam read based gun plays well since the sky changes to a blue color.
−
** tvservice only works with composite and HDMI
+
* Fake Lightgun. There are many examples of this in arcade. For example Operation Wolf arcade cabinet uses a joystick disguised as gun. Again, the playability here relies on games not having many and/or big black areas on the screen.
  
−
==Conclusions==
 
  
−
* We must wait some time until all these changes be mainlined in the Raspberry kernel drivers.
+
==Final Words== <!--T:17-->
−
* 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.
+
<!--T:18-->
 +
While we are still working on more and new features, fixing bugs, etc., the system is currently in a very advanced Alpha status and working very nicely.
 +
Please be patient, all this work is made in my spare time (rTomas). The system will be for sure released at some point in 2022.
 +
For quick updates, photos, videos, etc. you can follow me on Twitter @rtomasal
  
 +
<!--T:19-->
 
To be continued...
 
To be continued...
 +
</translate>

Latest revision as of 17:46, 21 February 2022

Other languages:
English • ‎español

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/Pi400.
  • From the software perspective, the introduction of the new KMS video driver, made impossible to use the old way of changing resolutions via firmware custom driver.


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 was the default Pi4's driver for some time, and did 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 video driver and the new default driver in all current and future Pi models.


Development Status

Frontend

  • The frontend, which makes use of Pygame SDL1 and surface objects, has been remade from scratch to avoid the performance issues that suffered in Pi4 due to changes in video libraries. Now it is sprite based and it is prepared to be easily migrated to Pygame SDL2. There is a bug in Pygame SDL2 that prevents us from reinit the video while the frontend is running. This issue is currently being addressed by Pygame development team.
  • The ALSA audio drivers was changed to make some of the internal virtual devices comply with the standard naming and configuration That resulted in some audio features like EQ and audiojack broken. All issues with ALSA audio have been resolved.
  • Raspberry USB PCI hub descriptors and sorting has changed resulting in controller ordering not matching with Retroarch anymore. Also RetroArch changed their sorting engine. After some work on our controller engine, it is now already fully adapted to match all these changes.


Video Driver and Timings

  • The new KMS driver is now finished and working.
  • A new Device Tree Overlay .dtbo has been created to make it 100% KMS compatible.
  • A new custom kernel module has been created to provide a bridge between KMS and DPI.
  • A new custom kernel has been created to support interlaced (480i) resolutions.
  • A new custom kernel has been created to support native CSYNC.
  • A new custom RetroArch has been created to support KMS and the new custom DynaRes video subsystem (more info in the 'New Features' section down below).


New Features

DynaRes

File:Dynares.gif

We have developed a custom version of RetroArch which includes a new video subsystem (DynaRes) to fully manage all the video modes and options. the main features of DynaRes are the following ones:

  • Does not require any external timings database.
  • Can set the proper resolution and native refresh rate, as provided by the core, when launching games.
  • Can change the resolution on the fly as requested by the core/game while playing.
  • Support different monitor types (15khz, 25khz, 31khz, etc.)
  • Timings calculated based on Calamity switchres.
  • Automatic H and V image positioning and centering.
  • Has different working modes (all of them using native refresh rates):
    • Native: games will run on native H and V resolutions. On the fly timing changes will happen on both H and V resolution changes. This is recommended if your priority are arcade games, when using real arcade monitors (specially for 25/31kHz), or if you plan to capture video.
    • SuperX: games will run on native V resolution. H resolution is super res dynamically calculated using integer scale with 8px of overscan. On the fly timing changes will happen only on V resolution changes. This is recommended in most of the cases for 15kHz TVs, specially for playing PSX games.
    • Custom Fixed: games will run in a fixed resolution. This is useful for scenarios like Dreamcast 240p/480i, or TATE games played rotated.
    • Handheld Full: systems like GBA and NGP can be displayed in special fullscreen mode.


Lightgun

File:Lgun.gif

We have developed a custom driver to support original Namco GunCon 2 lightgun. Currently, only original blue(EU), black(JP) and orange(US) original guns are supported. We are working on supporting clones and original XBOX gun in the future if feasible. It is very important to know that there are 4 different kinds of gun games based on the hardware they used. While nothing prevents us on playing any of them, different results could be faced:

  • Lightgun blanking based. The main example is the NES Zapper. These games play really well. Some cores like Genesis Plus GX do not provide any precision adjustment, so SMS games for instance become more challenging.
  • Lightgun beam read based. The main example is PSX GunCon. These games work and play perfectly fine.
  • Lightgun + IR receiver based. Sega Menacer is the main example. These games play well as long as they do not have big black areas. An example of game that do not work well is Megadrive T2 the Arcade. The sky in this game is black, so the gun cannot read the beam. On the other hand, SNES version which is prepared for beam read based gun plays well since the sky changes to a blue color.
  • Fake Lightgun. There are many examples of this in arcade. For example Operation Wolf arcade cabinet uses a joystick disguised as gun. Again, the playability here relies on games not having many and/or big black areas on the screen.


Final Words

While we are still working on more and new features, fixing bugs, etc., the system is currently in a very advanced Alpha status and working very nicely. Please be patient, all this work is made in my spare time (rTomas). The system will be for sure released at some point in 2022. For quick updates, photos, videos, etc. you can follow me on Twitter @rtomasal

To be continued...

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