Messages in this thread | | | Date | Thu, 3 Aug 2023 11:30:52 +0200 | From | Neil Armstrong <> | Subject | Re: [PATCH 0/4] drm/panel: sitronix-st7789v: add support for partial mode |
| |
On 03/08/2023 11:22, Maxime Ripard wrote: > On Thu, Aug 03, 2023 at 10:51:57AM +0200, Daniel Vetter wrote: >> On Thu, Aug 03, 2023 at 10:48:57AM +0200, Maxime Ripard wrote: >>> On Thu, Aug 03, 2023 at 10:11:22AM +0200, Neil Armstrong wrote: >>>> Hi, >>>> >>>> On 18/07/2023 17:31, Michael Riesch wrote: >>>>> Hi all, >>>>> >>>>> This series adds support for the partial display mode to the Sitronix >>>>> ST7789V panel driver. This is useful for panels that are partially >>>>> occluded by design, such as the Jasonic JT240MHQS-HWT-EK-E3. Support >>>>> for this particular panel is added as well. >>>>> >>>>> Note: This series is already based on >>>>> https://lore.kernel.org/lkml/20230714013756.1546769-1-sre@kernel.org/ >>>> >>>> I understand Maxime's arguments, but by looking closely at the code, >>>> this doesn't look like an hack at all and uses capabilities of the >>>> panel controller to expose a smaller area without depending on any >>>> changes or hacks on the display controller side which is coherent. >>>> >>>> Following's Daniel's summary we cannot compare it to TV overscan >>>> because overscan is only on *some* displays, we can still get 100% >>>> of the picture from the signal. >>> >>> Still disagree on the fact that it only affects some display. But it's >>> not really relevant for that series. >> >> See my 2nd point, from a quick grep aside from i915 hdmi support, no one >> else sets all the required hdmi infoframes correctly. Which means on a >> compliant hdmi tv, you _should_ get overscan. That's how that stuff is >> speced. >> >> Iirc you need to at least set both the VIC and the content type, maybe >> even more stuff. >> >> Unless all that stuff is set I'd say it's a kms driver bug if you get >> overscan on a hdmi TV. > > I have no doubt that i915 works there. The source of my disagreement is > that if all drivers but one don't do that, then userspace will have to > care. You kind of said it yourself, i915 is kind of the exception there. > > The exception can be (and I'm sure it is) right, but still, it deviates > from the norm.
HDMI spec is hidden behind a paywall, HDMI testing is a mess, HDMI real implementation on TVs and Displays is mostly broken, and HDMI certification devices are too expensive... this is mainly why only i915 handles it correctly.
> >>> I think I'll still like to have something clarified before we merge it: >>> if userspace forces a mode, does it contain the margins or not? I don't >>> have an opinion there, I just think it should be documented. >> >> The mode comes with the margins, so if userspace does something really >> funny then either it gets garbage (as in, part of it's crtc area isn't >> visible, or maybe black bars on the screen), or the driver rejects it >> (which I think is the case for panels, they only take their mode and >> nothing else). > > Panels can usually be quite flexible when it comes to the timings they > accept, and we could actually use that to our advantage, but even if we > assume that they have a single mode, I don't think we have anything that > enforces that, either at the framework or documentation levels?
Yep, this is why we would need a better atomic based panel API that would permit us handling dynamic timings for panel and get out of the single-mode for modern panels.
Neil
> > Maxime
| |