Hi Geert, On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, > > Thanks for your patch! > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@xxxxxxxxxx> wrote: > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines > > modes in the drivers. > > Nit: strictly speaking these are not analog modes, but the digital > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a > 13.5 MHz sampling frequency for pixels. > > In analog modes, the only discrete values are the number of lines, and > the frame/field rate (fixing the horizontal sync rate when combined). > > The number of (in)visible pixels per line depends on the available > bandwidth. In a digital variant (which is anything generated by a > digital computer system), the latter depends on the pixel clock, which > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g. > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)). > > So I think we probably need some way to generate a PAL/NTSC-compatible > mode based not only on resolution, but also on pixel clock. This would also fix the comments made by Jani and Thomas, so I quite like the idea of it. I'm struggling a bit to find how would could implement this though. From what you were saying, I guess the prototype would be something like struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock, unsigned int lines, unsigned int frame_rate) But I have zero idea on what the implementation would be. Do you have some resources for this you could point me to? Thanks Maxime
Attachment:
signature.asc
Description: PGP signature