From: Mateusz Kwiatkowski <kfyatek@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
Maxime Ripard <maxime@cerno.tech>
Cc: "Emma Anholt" <emma@anholt.net>,
"Neil Armstrong" <narmstrong@baylibre.com>,
"David Airlie" <airlied@linux.ie>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Phil Elwell" <phil@raspberrypi.com>,
"Jerome Brunet" <jbrunet@baylibre.com>,
"Samuel Holland" <samuel@sholland.org>,
"Kevin Hilman" <khilman@baylibre.com>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Chen-Yu Tsai" <wens@csie.org>,
linux-sunxi@lists.linux.dev,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic@lists.infradead.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
"Dom Cobley" <dom@raspberrypi.com>,
"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Noralf Trønnes" <noralf@tronnes.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>
Subject: Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Date: Wed, 24 Aug 2022 18:42:18 +0200 [thread overview]
Message-ID: <6d1dfaad-7310-a596-34dd-4a6d9aa95f65@gmail.com> (raw)
In-Reply-To: <CAMuHMdUjE0mwu8z5AksW4h1OwzDCQ5h1ZoCWDi+rC4p2Pu5O4g@mail.gmail.com>
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.
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.
- 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.
- 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.
- 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).
- 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.
- 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.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Best regards,
Mateusz Kwiatkowski
next prev parent reply other threads:[~2022-08-24 16:42 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 16:34 [PATCH v1 00/35] drm: Analog TV Improvements Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 01/35] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity Maxime Ripard
2022-08-08 12:25 ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 02/35] drm/connector: Rename subconnector state variable Maxime Ripard
2022-08-08 12:26 ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 03/35] drm/atomic: Add TV subconnector property to get/set_property Maxime Ripard
2022-08-08 12:30 ` Noralf Trønnes
2022-08-15 7:35 ` Maxime Ripard
2022-08-15 10:48 ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes Maxime Ripard
2022-08-02 13:58 ` Jani Nikula
2022-08-02 14:16 ` Thomas Zimmermann
2022-08-16 11:58 ` Maxime Ripard
2022-08-12 13:18 ` Geert Uytterhoeven
2022-08-16 13:26 ` Maxime Ripard
2022-08-16 15:00 ` Geert Uytterhoeven
2022-08-17 7:53 ` Maxime Ripard
2022-08-17 8:51 ` Geert Uytterhoeven
2022-08-17 13:14 ` Maxime Ripard
2022-08-17 14:01 ` Geert Uytterhoeven
2022-08-18 12:39 ` Maxime Ripard
2022-08-18 12:57 ` Geert Uytterhoeven
2022-08-18 13:42 ` Maxime Ripard
2022-08-18 15:34 ` Geert Uytterhoeven
2022-08-18 15:46 ` Maxime Ripard
2022-08-18 15:56 ` Geert Uytterhoeven
2022-08-24 16:42 ` Mateusz Kwiatkowski [this message]
2022-08-29 13:29 ` Maxime Ripard
2022-08-29 14:14 ` Geert Uytterhoeven
2022-08-29 14:33 ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 05/35] drm/connector: Add TV standard property Maxime Ripard
2022-08-08 12:44 ` Noralf Trønnes
2022-08-16 8:26 ` Maxime Ripard
2022-08-16 9:42 ` Noralf Trønnes
2022-08-16 9:49 ` Maxime Ripard
2022-08-16 19:35 ` Noralf Trønnes
2022-08-17 11:46 ` Maxime Ripard
2022-08-17 13:11 ` Noralf Trønnes
2022-08-17 23:23 ` Noralf Trønnes
2022-08-18 15:01 ` Noralf Trønnes
2022-08-18 15:31 ` Maxime Ripard
2022-08-21 11:43 ` Noralf Trønnes
2022-08-26 8:21 ` Maxime Ripard
2022-08-18 15:27 ` Maxime Ripard
2022-08-12 13:25 ` Geert Uytterhoeven
2022-08-16 13:20 ` Maxime Ripard
2022-08-16 13:29 ` Geert Uytterhoeven
2022-08-16 14:11 ` Maxime Ripard
2022-08-16 14:43 ` Geert Uytterhoeven
2022-08-16 15:49 ` Maxime Ripard
2022-08-17 7:31 ` Geert Uytterhoeven
2022-08-17 7:32 ` Geert Uytterhoeven
2022-08-17 7:47 ` Maxime Ripard
2022-08-17 8:35 ` Geert Uytterhoeven
2022-08-17 11:14 ` Maxime Ripard
2022-08-17 13:05 ` Geert Uytterhoeven
2022-08-17 13:18 ` Maxime Ripard
2022-08-17 14:04 ` Geert Uytterhoeven
2022-08-18 14:54 ` Maxime Ripard
2022-08-18 15:20 ` Geert Uytterhoeven
2022-08-18 15:34 ` Maxime Ripard
2022-08-19 9:35 ` Geert Uytterhoeven
2022-08-25 13:39 ` Maxime Ripard
2022-08-20 20:12 ` Noralf Trønnes
2022-08-25 13:44 ` Maxime Ripard
2022-08-25 15:13 ` Noralf Trønnes
2022-08-29 8:28 ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 06/35] drm/connector: Only register TV mode property if present Maxime Ripard
2022-08-08 12:49 ` Noralf Trønnes
2022-08-15 10:40 ` Maxime Ripard
2022-08-15 10:49 ` Noralf Trønnes
2022-07-29 16:34 ` [PATCH v1 07/35] drm/modes: Only consider bpp and refresh before options Maxime Ripard
2022-08-12 13:25 ` Geert Uytterhoeven
2022-08-16 12:20 ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 08/35] drm/client: Add some tests for drm_connector_pick_cmdline_mode() Maxime Ripard
2022-08-02 10:14 ` Thomas Zimmermann
2022-08-15 8:42 ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function Maxime Ripard
2022-08-12 13:27 ` Geert Uytterhoeven
2022-08-16 13:46 ` Maxime Ripard
2022-08-16 14:44 ` Geert Uytterhoeven
2022-07-29 16:34 ` [PATCH v1 10/35] drm/modes: Switch to named mode descriptors Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 11/35] drm/modes: Fill drm_cmdline mode from named modes Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 12/35] drmi/modes: Properly generate a drm_display_mode from a named mode Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 13/35] drm/atomic-helper: Add a TV properties reset helper Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 14/35] drm/atomic-helper: Add an analog TV atomic_check implementation Maxime Ripard
2022-07-29 17:16 ` Mateusz Kwiatkowski
2022-08-15 8:30 ` Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 15/35] drm/vc4: vec: Remove empty mode_fixup Maxime Ripard
2022-07-29 16:34 ` [PATCH v1 16/35] drm/vc4: vec: Convert to atomic helpers Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 17/35] drm/vc4: vec: Refactor VEC TV mode setting Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 18/35] drm/vc4: vec: Remove redundant atomic_mode_set Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 19/35] drm/vc4: vec: Fix timings for VEC modes Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 20/35] drm/vc4: vec: Switch for common modes Maxime Ripard
2022-07-29 18:12 ` Mateusz Kwiatkowski
2022-08-16 11:57 ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 21/35] drm/vc4: vec: Fix definition of PAL-M mode Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 22/35] drm/vc4: vec: Use TV Reset implementation Maxime Ripard
2022-07-30 3:03 ` kernel test robot
2022-07-29 16:35 ` [PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode property Maxime Ripard
2022-08-20 17:22 ` Noralf Trønnes
2022-08-24 15:26 ` Maxime Ripard
2022-08-25 13:14 ` Noralf Trønnes
2022-08-29 12:13 ` Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 24/35] drm/vc4: vec: Add support for more analog TV standards Maxime Ripard
2022-07-29 17:55 ` Mateusz Kwiatkowski
2022-08-15 8:37 ` Maxime Ripard
2022-08-24 16:59 ` Mateusz Kwiatkowski
2022-07-29 16:35 ` [PATCH v1 25/35] drm/sun4i: tv: Remove unused mode_valid Maxime Ripard
2022-07-30 9:13 ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 26/35] drm/sun4i: tv: Convert to atomic hooks Maxime Ripard
2022-07-30 9:12 ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 27/35] drm/sun4i: tv: Merge mode_set into atomic_enable Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 28/35] drm/sun4i: tv: Remove useless function Maxime Ripard
2022-07-29 16:35 ` [PATCH v1 29/35] drm/sun4i: tv: Remove useless destroy function Maxime Ripard
2022-07-30 9:14 ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 30/35] drm/sun4i: tv: Rename error label Maxime Ripard
2022-07-30 9:15 ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 31/35] drm/sun4i: tv: Add missing reset assertion Maxime Ripard
2022-07-30 9:16 ` Jernej Škrabec
2022-07-29 16:35 ` [PATCH v1 32/35] drm/sun4i: tv: Convert to the new TV mode property Maxime Ripard
2022-08-28 17:12 ` Noralf Trønnes
2022-07-29 16:35 ` [PATCH v1 33/35] drm/connector: Remove TV modes property Maxime Ripard
2022-07-29 20:06 ` kernel test robot
2022-07-29 20:16 ` kernel test robot
2022-07-29 16:35 ` [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option Maxime Ripard
2022-08-12 13:31 ` Geert Uytterhoeven
2022-08-16 13:51 ` Maxime Ripard
2022-08-20 20:18 ` Noralf Trønnes
2022-08-24 15:45 ` Maxime Ripard
2022-08-24 17:08 ` Mateusz Kwiatkowski
2022-08-25 12:41 ` Noralf Trønnes
2022-08-26 6:46 ` Maxime Ripard
2022-08-28 17:06 ` Noralf Trønnes
2022-07-29 16:35 ` [PATCH v1 35/35] drm/modes: Introduce more named modes Maxime Ripard
2022-08-21 16:16 ` Noralf Trønnes
2022-08-25 14:22 ` Maxime Ripard
2022-08-08 13:03 ` [PATCH v1 00/35] drm: Analog TV Improvements Noralf Trønnes
2022-08-21 16:33 ` Noralf Trønnes
2022-08-22 7:48 ` Maxime Ripard
2022-08-22 8:57 ` Mateusz Kwiatkowski
2022-08-25 15:55 ` Maxime Ripard
2022-08-25 16:17 ` Mateusz Kwiatkowski
2022-08-26 4:07 ` Mateusz Kwiatkowski
2022-08-26 8:39 ` Maxime Ripard
2022-08-26 14:56 ` Dom Cobley
2022-08-27 16:11 ` Noralf Trønnes
2022-08-30 21:31 ` kFYatek
2022-08-22 13:21 ` Noralf Trønnes
2022-08-25 16:21 ` Maxime Ripard
2022-08-25 19:36 ` Noralf Trønnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d1dfaad-7310-a596-34dd-4a6d9aa95f65@gmail.com \
--to=kfyatek@gmail.com \
--cc=airlied@linux.ie \
--cc=dave.stevenson@raspberrypi.com \
--cc=dom@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emma@anholt.net \
--cc=geert@linux-m68k.org \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=martin.blumenstingl@googlemail.com \
--cc=maxime@cerno.tech \
--cc=narmstrong@baylibre.com \
--cc=noralf@tronnes.org \
--cc=phil@raspberrypi.com \
--cc=samuel@sholland.org \
--cc=tzimmermann@suse.de \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).