[PATCH v3] video: sunxi_display: Convert to DM_VIDEO

[Maxime Ripard]

Hi Andre,

On Sun, Feb 21, 2021 at 12:07:35AM +0000, Andre Przywara wrote:
> > >  enum sunxi_monitor {
> > >         sunxi_monitor_none,
> > >         sunxi_monitor_dvi,
> > > @@ -59,12 +68,11 @@ enum sunxi_monitor {
> > >  #define SUNXI_MONITOR_LAST sunxi_monitor_composite_pal_nc
> > >
> > >  struct sunxi_display {
> > > -       GraphicDevice graphic_device;
> > >         enum sunxi_monitor monitor;
> > >         unsigned int depth;
> > >         unsigned int fb_addr;
> > >         unsigned int fb_size;  
> > 
> > These last three are repeated from the uclass info. But fb_addr seems
> > to sometimes be different from the ucass frame buffer, in which case I
> > wonder how output actually works.
> > 
> > If you do actually need these, can you please document them here?
> 
> I think this might be mostly non-DM legacy, but for the composite
> overscan we tweak the framebuffer address. I haven't fully wrapped
> my mind around this, though, and ideally we can indeed lose those
> extra members.
> I will try to find some device with composite input to test it.

So the overscan will put the edges of any displayed image out of the
visible area of the screen, right? The amount of content non-visible due
to this isn't really standard and any display will behave differently
there.

One way to deal with this is to rescale the composited image to a
slightly smaller and center it in the middle of the screen.

We don't have that option though, so the code will instead render in a
slightly smaller resolution, centered in the framebuffer.

Note that composite isn't the only output that you can test this on:
HDMI TVs will also use overscan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210222/27d6640d/attachment.sig>