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@xxxxxxxxxxxxxx> >>> >>> 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
