[PATCH v2] drm/fb-helper: Scale back depth to supported maximum

[Daniel Vetter]

On Thu, Jan 10, 2019 at 10:19 AM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Fri, Dec 28, 2018 at 5:05 PM Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Fri, Dec 28, 2018 at 4:40 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> > > - Skip over YUV formats. The framebuffer emulation cannot
> > >   handle these formats.
> (...)
> > > +                       /* Do not consider YUV formats for framebuffers */
> > > +                       if (fmt->is_yuv)
> >
> > I think better to skip all funny formats with fmt->depth == 0. With that:
> >
> > Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> I can easily make that change but this comment in the drm_fourcc.h
> header makes me insecure:
>
> /**
>  * @depth:
>  *
>  * Color depth (number of bits per pixel excluding padding bits),
>  * valid for a subset of RGB formats only. This is a legacy field, do
>  * not use in new code and set to 0 for new formats.
>  */
> u8 depth;
>
> This would mean that we make the framebuffer only support
> "legacy formats". It might be that "legacy formats" include
> all reasonable ones such as any RGB/BGA variants.

Yeah it's not a perfect fit either, but there's a lot non-yuv format
that are very special, and checking for ->depth excludes them. And yes
all the usual rgb/bga formats have bpp/depth descriptions. That's also
all that the fbdev format stuff can describe. Long term we maybe want
to switch over to directly using the format fourcc (and -EINVAL the
ones we don't understand), because atm we're shrugging the bgr vs rgb
difference under the rug.

Cheers, Daniel

> I will make the change and put in some comments about this
> so it's clear.
>
> Yours,
> Linus Walleij



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch