kernel/linux.git/drivers/gpu/drm/drm_fourcc.c, branch v6.19.11

drm: Pass pixel_format+modifier directly to drm_get_format_info()

2025-07-16T17:01:13+00:00

Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just pass the pixel format+modifier combo in by hand. We may want to use drm_get_format_info() outside of the normal addfb paths where we won't have a struct drm_mode_fb_cmd2, and creating a temporary one just for this seems silly. Done with cocci: @@ identifier dev, mode_cmd; @@ struct drm_format_info * drm_get_format_info(struct drm_device *dev, - const struct drm_mode_fb_cmd2 *mode_cmd + u32 pixel_format, u64 modifier ) { <... ( - mode_cmd->pixel_format + pixel_format | - mode_cmd->modifier[0] + modifier ) ...> } @@ identifier dev, mode_cmd; @@ struct drm_format_info * drm_get_format_info(struct drm_device *dev, - const struct drm_mode_fb_cmd2 *mode_cmd + u32 pixel_format, u64 modifier ); @@ expression dev, mode_cmd; @@ - drm_get_format_info(dev, mode_cmd) + drm_get_format_info(dev, mode_cmd->pixel_format, mode_cmd->modifier[0]) v2: Fix kernel docs (Laurent) Drop drm_mode_fb_cmd2 forward declaration (Thomas) Cc: Liviu Dudau Cc: Russell King Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Patrik Jakobsson Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul Cc: Marijn Suijten Cc: Marek Vasut Cc: Stefan Agner Cc: Lyude Paul Cc: Danilo Krummrich Cc: Tomi Valkeinen Cc: Alex Deucher Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Andy Yan Cc: Thierry Reding Cc: Mikko Perttunen Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Reviewed-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Reviewed-by: Liviu Dudau Acked-by: Alex Deucher Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-3-ville.syrjala@linux.intel.com

drm: Pass pixel_format+modifier to .get_format_info()

2025-07-16T16:59:59+00:00

Decouple .get_format_info() from struct drm_mode_fb_cmd2 and just pass the pixel format+modifier combo in by hand. We may want to use .get_format_info() outside of the normal addfb paths where we won't have a struct drm_mode_fb_cmd2, and creating a temporary one just for this seems silly. v2: Fix intel_fb_get_format_info() docs (Laurent) Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: Laurent Pinchart Reviewed-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Alex Deucher Acked-by: Rodrigo Vivi Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-2-ville.syrjala@linux.intel.com

drm/fourcc: Add RGB161616 and BGR161616 formats

2025-06-28T07:36:16+00:00

Add FourCC definitions for the 48-bit RGB/BGR formats to the DRM/KMS uapi. The format will be used by the Raspberry Pi PiSP Back End, supported by a V4L2 driver in kernel space and by libcamera in userspace, which uses the DRM FourCC identifiers. Signed-off-by: Jacopo Mondi Reviewed-by: Rob Clark Reviewed-by: Simon Ser Reviewed-by: Naushir Patuck Link: https://lore.kernel.org/r/20240226132544.82817-1-jacopo.mondi@ideasonboard.com Signed-off-by: Javier Martinez Canillas

drm: drm_fourcc: add 10/12/16bit software decoder YCbCr formats

2025-05-29T15:32:58+00:00

This adds FOURCCs for 3-plane 10/12/16bit YCbCr formats used by software decoders like ffmpeg, dav1d and libvpx. The intended use-case is buffer sharing between decoders and GPUs by allocating buffers with e.g. udmabuf or dma-heaps, avoiding unnecessary copies and format conversions in various scenarios. Unlike formats typically used by hardware decoders the 10/12bit formats use a LSB alignment. In order to allow fast implementations in GL and Vulkan the padding must contain only zeros, so the float representation can be calculated by multiplying with 2^6=64 or 2^4=16 respectively. MRs or branches for Mesa, Vulkan, Gstreamer, Weston and Mutter can be found at: - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34303 - https://github.com/rmader/Vulkan-Docs/commits/ycbcr-16bit-lsb-formats/ - https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8540 - https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1753 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4348 The naming scheme follows the 'P' and 'Q' formats. The 'S' stands for 'software' and was selected in order to make remembering easy. The 'Sx16' formats could as well be 'Qx16'. We stick with 'S' as 16bit software decoders are likely much more common than hardware ones for the foreseeable future. Note that these formats already have Vulkan equivalents: - VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM - VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM - VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM Signed-off-by: Robert Mader Reviewed-by: Daniel Stone Link: https://lore.kernel.org/r/20250509133535.60330-1-robert.mader@collabora.com Signed-off-by: Daniel Stone

drm/fbdev-helper: Move color-mode lookup into 4CC format helper

2024-09-26T06:27:49+00:00

The color mode as specified on the kernel command line gives the user's preferred color depth and number of bits per pixel. Move the color-mode-to-format conversion from fbdev helpers into a 4CC helper, so that it can be shared among DRM clients. v2: - fix grammar in commit message (Laurent) Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-2-tzimmermann@suse.de

drm/fourcc: Add NV20 and NV30 YUV formats

2023-10-24T19:34:35+00:00

DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled variant of NV15, a 10-bit 2-plane YUV format that has no padding between components. Instead, luminance and chrominance samples are grouped into 4s so that each group is packed into an integer number of bytes: YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes The '20' and '30' suffix refers to the optimum effective bits per pixel which is achieved when the total number of luminance samples is a multiple of 4. V2: Added NV30 format Signed-off-by: Jonas Karlman Reviewed-by: Sandy Huang Reviewed-by: Christopher Obbard Tested-by: Christopher Obbard Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20231023173718.188102-2-jonas@kwiboo.se

drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats

2022-11-23T19:34:46+00:00

As of commit eae06120f1974e1a ("drm: refuse ADDFB2 ioctl for broken bigendian drivers"), drivers must set the quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() compat code work correctly on big-endian machines. While that works fine for big-endian XRGB8888 and ARGB8888, which are mapped to the existing little-endian BGRX8888 and BGRA8888 formats, it does not work for big-endian XRGB1555 and RGB565, as the latter are not listed in the format database. Fix this by adding the missing formats. Limit this to big-endian platforms, as there is currently no need to support these formats on little-endian platforms. Fixes: 6960e6da9cec3f66 ("drm: fix drm_mode_addfb() on big endian machines.") Signed-off-by: Geert Uytterhoeven Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/3ee1f8144feb96c28742b22384189f1f83bcfc1a.1669221671.git.geert@linux-m68k.org

drm/fourcc: Fix vsub/hsub for Q410 and Q401

2022-11-16T11:29:09+00:00

These formats are not subsampled, but that means hsub and vsub should be 1, not 0. Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats") Reported-by: George Kennedy Reported-by: butt3rflyh4ck Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20220913144306.17279-1-brian.starkey@arm.com

drm/fourcc: Add DRM_FORMAT_D[1248]

2022-07-09T13:36:07+00:00

As Rn covers single-channel formats with a direct relationship between channel value and brightness, and Cn can be any colors, there are currently no fourcc codes to describe single-channel formats with an inverse relationship between channel value and brightness. Introduce fourcc codes for a single-channel frame buffer format with two, four, sixteen, or 256 brightness ("darkness") levels, where there is an inverse relationship between channel value and brightness. As the number of bits per pixel may be less than eight, some of these formats rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files. Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/6119f3abeda9baaa88652843960adc032da276b4.1657294931.git.geert@linux-m68k.org

drm/fourcc: Add DRM_FORMAT_R[124]

2022-07-09T13:35:55+00:00

Introduce fourcc codes for single-channel frame buffer formats with two, four, and sixteen brightness levels, where there is a direct relationship between channel value and brightness. As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files. Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/96561a88e53c59cac72e66642bf4c097aacefd18.1657294931.git.geert@linux-m68k.org