linux-kernel - Re: [PATCH 7/7] dt-bindings: display: add panel-timing property to sitronix,st7789v

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d3d3cnpoeiozaqvbgy4e767omkjqi5vywj6jkxcl6pzgwu654k@kebuuk6irse4>
Date:   Wed, 5 Apr 2023 17:01:26 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Michael Riesch <michael.riesch@...fvision.net>
Cc:     Rob Herring <robh@...nel.org>,
        Gerald Loacker <gerald.loacker@...fvision.net>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Thierry Reding <thierry.reding@...il.com>,
        Sam Ravnborg <sam@...nborg.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Sebastian Reichel <sebastian.reichel@...labora.com>
Subject: Re: [PATCH 7/7] dt-bindings: display: add panel-timing property to
 sitronix,st7789v

On Tue, Apr 04, 2023 at 06:26:25PM +0200, Michael Riesch wrote:
> >>>> A different question is the partial mode, for which (IIUC) you suggest
> >>>> the overscan feature. As I have never heard of this before, it would be
> >>>> very nice if you could point me to some examples. Where would the
> >>>> effective resolution be set in this case?
> >>>
> >>> So, back when CRT were a thing the edges of the tube were masked by the
> >>> plastic case. HDMI inherited from that and that's why you still have
> >>> some UI on some devices (like consoles) to setup the active area of the
> >>> display.
> >>>
> >>> The underlying issue is exactly what you describe: the active area is
> >>> larger than what the plastic case allows to see. I don't think anyone
> >>> ever had the usecase you have, but it would be the right solution to me
> >>> to solve essentially the same issue the same way we do on other output
> >>> types.
> >>
> >> OK, we'll look into the overscan feature. But still the information
> >> about the active area should come from the driver, right?
> > 
> > No, the userspace is in charge there.
> 
> I'd prefer not to have the hardware description in user space. But we
> can continue this discussing once our v2 is out.

I'm not sure if it's worth doing something if you don't agree with it :)

At the end of the day, "the hardware" is a matter of semantics, and you
would argue that it's only the (user) visible part of the display, and I
would argue that it's the whole panel and we would both be somewhat
right.

The thing is: having the margins definition allows the userspace to be
aware that there's overscan to deal with, and for example setup the
scaler to properly display whatever you put in there.

If you just report a weird mode that doesn't match any kind of standard,
well, you could still do that, but you would need to tell the compositor
which mode you would need to scale down from.

In both case the userspace is involved. One is generic, the other isn't
and probably requires some extra development.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)