On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer michel@daenzer.net wrote:
On 2021-03-23 4:32 p.m., Mark Yacoub wrote:
On Tue, Mar 23, 2021 at 11:02 AM Alex Deucher alexdeucher@gmail.com
wrote:
On Wed, Mar 10, 2021 at 11:15 AM Mark Yacoub markyacoub@chromium.org
wrote:
From: Mark Yacoub markyacoub@google.com
On initializing the framebuffer, call drm_any_plane_has_format to do a check if the modifier is supported. drm_any_plane_has_format calls dm_plane_format_mod_supported which is extended to validate that the modifier is on the list of the plane's supported modifiers.
The bug was caught using igt-gpu-tools test:
kms_addfb_basic.addfb25-bad-modifier
Tested on ChromeOS Zork by turning on the display, running an overlay test, and running a YT video.
Cc: Alex Deucher alexander.deucher@amd.com Cc: Bas Nieuwenhuizen bas@basnieuwenhuizen.nl Signed-off-by: default avatarMark Yacoub markyacoub@chromium.org
I'm not an expert with modifiers yet. Will this break chips which don't currently support modifiers?
No it shouldn't. When you don't support modifiers yet, your will default to Linear Modifier (DRM_FORMAT_MOD_LINEAR), [...]
No modifier support does not imply linear. It's generally signalled via DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver specific mechanisms".
Doesn't quite work that way in the kernel sadly. If you don't set DRM_MODE_FB_MODIFIERS then the modifier fields have to be 0 (which happens to alias DRM_FORMAT_MOD_LINEAR and then now deprecated DRM_FORMAT_MOD_NONE). This is verified in shared drm code.
(and all userspace code I've seen simply doesn't set DRM_MODE_FB_MODIFIERS if the incoming modifier is DRM_FORMAT_MOD_INVALID)
-- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx