Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard <maxime@cerno.tech>]

[-- Attachment #1: Type: text/plain, Size: 8397 bytes --]

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@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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]