[PATCH 0/4] drm/panel: sitronix-st7789v: add support for partial mode

[Neil Armstrong]

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