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@xxxxxxxxxx> 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@xxxxxxxxxx> 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:
signature.asc
Description: PGP signature
