[PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Maxime Ripard
maxime at cerno.tech
Mon Aug 29 06:29:53 PDT 2022
Hi Mateusz
On Wed, Aug 24, 2022 at 06:42:18PM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
>
> W dniu 18.08.2022 o 17:56, Geert Uytterhoeven pisze:
> > Hi Maxime,
> >
> > On Thu, Aug 18, 2022 at 5:46 PM Maxime Ripard <maxime at cerno.tech> wrote:
> >> On Thu, Aug 18, 2022 at 05:34:30PM +0200, Geert Uytterhoeven wrote:
> >>> On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard <maxime at cerno.tech> wrote:
> >>>> I started adding more sanity checks to my code, and I just realised I
> >>>> don't seem to be able to reach 720 pixels over a single line though. If
> >>>> I understood it properly, and according to [1] the active part of a line
> >>>> is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
> >>>> in the timing section has pretty much the same numbers, so it looks
> >>>> sane.
> >>>>
> >>>> At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
> >>>> pixels
> >>>>
> >>>> It seems we can go push it to 52350 ns, but that still gives us only 706
> >>>> pixels.
> >>>>
> >>>> Similarly, if I just choose to ignore that limit and just take the
> >>>> active time I need, 720 * 74 = 53280ns
> >>>>
> >>>> That leaves us 10720ns for the blanking period, and that's not enough to
> >>>> fit even the minimum of the front porch, hsync and back porch (1.55 +
> >>>> 4.5 + 5.5 = 11.55us).
> >>>>
> >>>> Are those constraints merely recommendations, or am I missing something?
> >>>
> >>> You are missing that the parts near the borders of the full image are
> >>> part of the overscan range, and may or may not be visible, depending
> >>> on your actual display.
> >>> The full 768x576 image size from BT.656 is not visible on a typical PAL display,
> >>> and is more of an "absolute maximum rating", guaranteed to cover more
> >>> than analog PAL.
> >>
> >> So the overscan range is not part of the active area, unlike what HDMI
> >> is doing for example?
> >
> > Indeed. DVI-D and HDMI etc. are pure digital (let's ignore they are a
> > digitized variant of old analog VGA ;-), hence there is a one-to-one
> > match between pixels in the image and pixels on the screen (ignoring
> > scaling). But even when using an analog VGA input on a modern
> > digital display, you have controls to e.g. move the image.
> >
> >> Is there some minimal timings available somewhere to fit those absolute
> >> maximum ratings?
> >
> > I guess they can be found on the Internet...
>
> Here are some references that I personally found useful:
>
> - ITU-R BT.601 <https://www.itu.int/rec/R-REC-BT.601/en>
> This is *the* standard that pretty much every modern device that deals with
> analog-style TV signal follows then converting to and from the digital domain.
> For example in the figures on page 10 (12 in the PDF numbering) you can see
> that the "time datum", i.e. start of horizontal sync pulse is canonically
> supposed to happen on sample 732 for 50 Hz or sample 736 for 59.94 Hz modes.
>
> BT.601 assumes 13.5 MHz sample rate / pixel clock, but you can proportionally
> scale those for other pixel clocks.
>
> - ITU-R BT.1700 <https://www.itu.int/rec/R-REC-BT.1700/en>
> This is *the* standard in force for actual analog composite video signals.
> The vertical sync specs are discrete, so they don't really change between
> analog and digital domains. For horizontal sync, the values in those specs
> are given in microseconds/nanoseconds, but you can multiply those by the
> sampling rate for equivalent pixel counts.
>
> - Pembers' Ponderings
> <https://web.archive.org/web/20160423225838/http://www.pembers.freeserve.co.uk/>
> An old archived website with a ton of resources about analog TV.
> The "Line Standards" article will probably be most interesting to you.
Thanks so much for all those resources, it's been super helpful :)
> By the way, please note a couple of things:
>
> - The analog standards are very imprecise for modern digital norms, giving
> considerable leeway for just about every timing. The allowed leeways are
> usually equivalent to a couple of pixels at the standard 13.5 MHz sampling
> rate - and those are meant for the transmitting end. Receivers are usually
> much more forgiving to maximize compatibility.
Ok
> - The 720-pixel standard of BT.601 is considerably wider than the active width
> specified in the analog standards. AFAIK this is intentional, to ensure that
> no part of the actual image is missed during digitization, and to keep the
> number a nice multiply of 16. The picture width given in the analog standards
> is equivalent to somewhere between 702 and 714 pixels (at 13.5 MHz clock),
> depending on the specific standard. And that includes overscan.
Ok. I think it still makes sense to allow it, if only we were using it so far :)
I've done a first implementation in the v2 I just sent that seems to
work ok, please let me know if I did anything stupid :)
In particular, I chose, if we were between 702 and 720 pixels to disable
all duration checks, and take the missing time from the front and back
porch, in equal proportions.
> - Same goes for the vertical active area. Original analog standards varied
> wildly from country to country, before finally settling on 575 lines for the
> 50 Hz standard and 485 lines for the 59.94 Hz standard. Or 576/486, depending
> on how you count. The topmost line of those 576/486 starts at half the screen,
> and the bottommost line ends at half the screen - so they are often combined
> when counting and given as 575/485. The digital 576i50 standard includes
> those half-lines. In the 59.94 Hz regions, 480 active digial lines ended up
> the norm, because 486 does not have nice dividers, and also some of the
> outermost lines which were always overscanned anyway, ended up used for things
> like closed captioning over the years.
Ok
> - Speaking of closed captioning... a lot of different stuff were put in the
> blanking interval over the years. Like teletext in Europe. There are projects
> like VBIT2 <https://github.com/peterkvt80/vbit2> which intentionally
> reconfigure the Raspberry Pi composite output to include the blanking interval
> in the framebuffer so that teletext can be output by drawing on the edge of
> the "screen" (from the computer point of view).
I'm not sure how we would support this in KMS to be honest. Asking for a
wider mode and the userspace putting whatever it wants in the margins
seems like a good choice.
> - A lot of equipment outside the broadcast industry willingly violated those
> standards, and there are real world use cases for that. Film studios used very
> slightly modified TVs to make them sync with 24fps cameras - in that variant,
> "NTSC" could have e.g. 655 lines so that the TV would refresh at 48 Hz with
> the same line frequency. Home computers and video game consoles output
> progressive 262/312-line modes instead of interlaced 525/625 lines. And often
> changed the line frequency slightly as well, for various reasons. Those
> progressive modes are still favored by retro gaming and emulation enthusiasts,
> because they incur a specific look on CRT displays. Even playing back video
> from a tape (especially home-grade, like VHS) could cause timings to go wildly
> out of spec, because of mechanical imprecisions.
Ok
> - There were multitude of standards predating the ubiquitous 525/60 and 625/50
> modes. The British 405-line and French 819-line standards are the most
> notorious, having lasted well into the 1980s, but there were also a lot of
> wildly varying pre-WW2 television systems. And there are enthusiasts dedicated
> to preserving those.
>
> My point is that the norms for analog TV are rather loose, and I think we
> shouldn't limit the drivers to only accepting the "proper" modes as defined in
> the spec. Those should of course be the default, but if non-standard modelines
> can be generated - there are legitimate use cases why people might want those.
Yep, that part has been dropped. I'm still wondering if we'd need to
still have a bunch of restrictions (like a total number of lines of 625
with NTSC would be obviously invalid), but that can always be added
later on if such a need comes up
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-amlogic/attachments/20220829/775f8675/attachment.sig>
More information about the linux-amlogic
mailing list