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: > > 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 at 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). >> 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 >> -Daniel >> >>>> 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. >>>> -Daniel >>>> >>>>> --- >>>>> 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: >>>>> -- >>>>> 1.9.1 >>>>> >>>>> _______________________________________________ >>>>> dri-devel mailing list >>>>> dri-devel at lists.freedesktop.org >>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >
