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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 2 Aug 2023 17:03:59 +0200
From:   Michael Riesch <michael.riesch@...fvision.net>
To:     Maxime Ripard <mripard@...nel.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Sam Ravnborg <sam@...nborg.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Sebastian Reichel <sre@...nel.org>,
        Gerald Loacker <gerald.loacker@...fvision.net>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 3/4] drm/panel: sitronix-st7789v: add support for partial
 mode

Hi all,

In order to avoid spamming the list, I sparked a discussion in
#dri-devel. FTR the log can be found here:
https://oftc.irclog.whitequark.org/dri-devel/2023-08-02#32360491;

On 8/2/23 14:47, Maxime Ripard wrote:
> Hi,
> 
> On Wed, Aug 02, 2023 at 02:34:28PM +0200, Michael Riesch wrote:
>> On 7/19/23 08:39, Maxime Ripard wrote:
>>> On Tue, Jul 18, 2023 at 05:31:52PM +0200, Michael Riesch wrote:
>>>> The ST7789V controller features support for the partial mode. Here,
>>>> the area to be displayed can be restricted in one direction (by default,
>>>> in vertical direction). This is useful for panels that are partially
>>>> occluded by design. Add support for the partial mode.
>>>>
>>>> Signed-off-by: Michael Riesch <michael.riesch@...fvision.net>
>>>
>>> We already had that discussion, but I think we shouldn't treat this any
>>> differently than overscan for other output.
>>
>> Indeed we had that discussion. For reference, it can be found here:
>> https://lore.kernel.org/dri-devel/20230329091636.mu6ml3gvw5mvkhm4@penduick/#t
>> The thing is that I am still clueless how the overscan approach could work.
>>
>> I found some DRM properties related to overscan/margins and I guess
>> userspace needs to set those. On my system weston is running. Is weston
>> in charge of configuring the corresponding output so that the correct
>> margins are applied? If so, how can this be achieved?
> 
> I don't really know Weston, but my guess would be based on some
> configuration or user feedback, depending on which case we're in.
> 
> We also set the default using some kernel command-line options.
> 
>> Will DRM handle the properties generically or does the driver need to do
>> some work as well?
> 
> What do you mean by generically?

I guess my question can be reduced to "What does the driver have to do
to support this overscan thingy?" If the overscan approach is the
preferred one, then I'd appreciate some pointers as to how this could work.

>> In any case it could make sense to write the partial mode registers and
>> enter the effective dimensions. At least I have seen this in other panel
>> drivers.
> 
> Sure, it makes sense. It shouldn't come from the DT and be fixed though.

However, as indicated in Daniel Vetter's summary of the IRC discussion,
the overscan properties may not be the preferred solution in this case.

Looking forward to further comments (alternatively, to seeing this patch
series getting applied :-))

Best regards,
Michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ