On Wed, Aug 10, 2016 at 06:57:02PM +0200, Daniel Vetter wrote:
On Wed, Aug 10, 2016 at 5:26 PM, Fabien DESSENNE fabien.dessenne@st.com 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@st.com
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.
Looks like I just plain forgot about these formats when I added drm_format_plane_cpp().
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel