Hi Daniel, On Fri, 2023-10-13 at 17:26 +0100, Daniel Stone wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Hi Shawn, > > On Fri, 6 Oct 2023 at 08:38, Hsiao Chien Sung < > shawn.sung@xxxxxxxxxxxx> wrote: > > + Padding provides ability to add pixels to width and height of a > layer with > > + specified colors. Due to hardware design, Mixer in VDOSYS1 > requires > > + width of a layer to be 2-pixel-align, or 4-pixel-align when > ETHDR is enabled, > > + we need Padding to deal with odd width. > > + Please notice that even if the Padding is in bypass mode, > settings in > > + register must be cleared to 0, or undefined behaviors could > happen. > > If I understand the driver correctly, padding is automatically > applied > to compensate for unaligned dimensions. The first/last rows/columns > of > the overlay area will be filled with a specified colour (black?) to > preserve the area. This is unfortunately not OK to do transparently. > Userspace must be aware of this policy decision and specifically > request it. If not, the atomic request check should fail and tell > userspace that the requested configuration is not possible to > achieve. > > Cheers, > Daniel Yes, Padding works as you described, users can assign background colors for the filled area in 10bit RGB format, however, the rows and columns that are filled by Padding will be cropped by the hardware components after it to avoid situations as you mentioned, so users should not notice any difference. The reason why we add paddings to the frame and then remove it before showing it on the screen is due to the limitation of ETHDR. When HDR is enabled, the input pixels in width must be 4-pixel aligned, but for now ETHDR is bypassed so as the Paddings. Since the Paddings are always bypassed currently, the logics described above are not implemented yet, mtk_padding_config() will also be removed in the next version as the reviewer's suggestion. Cheers, Shawn
