On Thu, Jan 10, 2019 at 10:19 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Fri, Dec 28, 2018 at 5:05 PM Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Fri, Dec 28, 2018 at 4:40 PM Linus Walleij <linus.walleij@xxxxxxxxxx> 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@xxxxxxxx> > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
