RP1 Video Out: Hack for 50fps/60fps buffer-flips in interlaced modes #7010
Conversation
|
Simulations suggest that the issue with NTSC timings may be the small distance between the last active (or FE-inserted "vfp") line and the field datum (rather than the vertical sync sequence per se). It seems the BE stops accepting pixels just before it gets to see the first pixel of the second field, the one with VSync. In the native interlace mode it won't be expecting a VSync here, but in the hacked mode it seems to lock up if one is not present! Fortunately (and still rather mysteriously) the workaround works. |
|
Do we have a policy about "chicken parameters"? e.g. a module parameter called Even once 60fps is (we hope) proven reliable, it's just conceivable some users might want to keep the old 30fps rate (though VC4 was always 60fps). |
Use them when necessary? Module parameters have the advantage that they can be set in their own module.conf file, which makes maintenance easier for distros. |
|
Done some more testing.
I might not bother with a parameter. |
To work around the 30fps buffer-flip rate limit when using VEC's "native" interlaced modes, switch to sending individual fields to the VEC BE, using an ISR to flip between fields. When the TV mode is NTSC, change advertised progressive modes to have 263 total lines; this ameliorates colour artifacts, although it reduces the frame rate slightly from 60.05Hz to 59.83Hz. Progressive modes with 262 lines remain supported. Fix an error in equalising pulse configuration for PAL-M/PAL60. Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
a9cc7c8 to
0bf6e9f
Compare
kernel: RP1 Video Out: Hack for 50fps/60fps buffer-flips in interlaced modes See: raspberrypi/linux#7010 kernel: Splash Screen: bug fix See: raspberrypi/linux#7021
kernel: RP1 Video Out: Hack for 50fps/60fps buffer-flips in interlaced modes See: raspberrypi/linux#7010 kernel: Splash Screen: bug fix See: raspberrypi/linux#7021
By avoiding VEC's built-in interlaced DMA modes, and sending individual fields (adapting the "field wobble" trick from the DPI driver), it looks like we can get VEC to update at full field rate.
This changes the pattern of VSync pulses on the VEC's FE->BE interface. Some jiggery-pokery with the NTSC vertical settings was required before the BE would tolerate this (my guess is that the offset between "frame datum" and VSync, which is nonzero in conventional NTSC line numbering, made it more sensitive to FE VSync timings?)
Needs more testing to ensure it's reliable in all modes (including the "vintage" ones). Unlike the DPI case we can't use PIO to infer correct field polarity. If it ever gets out of step, it won't recover!
To clarify: The first of these two commits relates to progressive modes, and is unrelated.