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 --- drivers/gpu/drm/drm_fourcc.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 0645c85..aa8c909 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -80,6 +80,17 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth, *depth = 8; *bpp = 8; break; + case DRM_FORMAT_XRGB4444: + case DRM_FORMAT_XBGR4444: + case DRM_FORMAT_RGBX4444: + case DRM_FORMAT_BGRX4444: + case DRM_FORMAT_ARGB4444: + case DRM_FORMAT_ABGR4444: + case DRM_FORMAT_RGBA4444: + case DRM_FORMAT_BGRA4444: + *depth = 12; + *bpp = 16; + break; case DRM_FORMAT_XRGB1555: case DRM_FORMAT_XBGR1555: case DRM_FORMAT_RGBX5551:
On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
Why? Who's going to use this? -Daniel
On 08/10/2016 12:35 PM, Daniel Vetter wrote:
At least for consistency between format_check() and drm_fb_get_bpp_depth().
Who's going to use this?
For the time being, I can see 9 drivers that make more or less use of this format (amd, atmel-hlcdc, exynos, fsl-dcu, imx, omapdrm, radeon, rcar-du, sti). In top of that I am working on a new driver that actually needs this format, and that does not work without this patch.
On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
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.
Probably a better patch would be to update the kerneldoc for these functions. Also Laurent is working on a complete reorg of all this. -Daniel
On 08/10/2016 04:12 PM, Daniel Vetter wrote:
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).
Probably a better patch would be to update the kerneldoc for these functions.
For the time being we have an issue with the current drivers that use the 4444 DRM formats and updating kerneldoc won't fix them
Also Laurent is working on a complete reorg of all this.
Looping Laurent who may have a different opinion, or plan to consider the 4444 DRM formats in its rework.
Fabien
On Wed, Aug 10, 2016 at 5:26 PM, Fabien DESSENNE fabien.dessenne@st.com wrote:
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
Hi Laurent,
Daniel talked about a planned reorg from you around DRM formats (or something like this) and I have proposed to fix some missing parts with the XRGB444 formats.
Can you let us know if you can consider this fix as part of your reorg?
If you can't what would be the best option to get this fixed?
Fabien
On 08/10/2016 05:26 PM, Fabien DESSENNE wrote:
Hi Fabien,
On Friday 19 Aug 2016 11:01:37 Fabien DESSENNE wrote:
I don't, because it's already there :-) See "[PATCH v4 00/14] Centralize format information" posted to this mailing list.
The series removes the drm_fb_get_bpp_depth() function. You have several options:
- Use drm_format_info() to retrieve format information that include the depth and the number of bytes per pixel per plane.
- Use drm_format_plane_cpp() if you only need the number of bytes per pixel per plane.
- Check the formats directly in your driver instead of basing decisions on the number of bytes per pixel, as Daniel mentioned.
If you can't what would be the best option to get this fixed?
dri-devel@lists.freedesktop.org