On Wed, Aug 10, 2016 at 5:26 PM, Fabien DESSENNE <fabien.dessenne@xxxxxx> wrote: > On 08/10/2016 04:12 PM, Daniel Vetter wrote: >> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote: >>> On 08/10/2016 12:35 PM, Daniel Vetter wrote: >>>> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote: >>>>> These pixel formats are supported by format_check() from drm_crtc.c, so >>>>> provide there depth and bpp. >>>>> >>>>> Signed-off-by: Fabien Dessenne <fabien.dessenne@xxxxxx> >>>> Why? >>> At least for consistency between format_check() and drm_fb_get_bpp_depth(). >> fb_get_bpp_depth is kinda legacy, the recommended way is to have a switch >> statement in your driver that directly decodes DRM_FORMAT_* into driver >> register values. The inconsistency is intentional since just looking at >> bpp and depth removes a lot of information. > I can understand that fb_get_bpp_depth() shall not be called by (new) > drivers. > But it is also called by the core part through drm_format_plane_cpp() > which is not a legacy interface and is used across many drivers (I think > that this is a recent change initiated by Ville). I've dug around and the only places I've found changes is from 2012. I think rgb444 formats just plain never worked. But in case I've missed something and this is a regression then indeed we need to fix it. For the real solution it's better to sync up with Laurent and his plans to rework the fourcc handling we have in drm. -Daniel -- 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
