On Wed, 1 Jul 2020 12:45:48 -0700
James Jones <jajones@xxxxxxxxxx> wrote:
> OK, I think I see what's going on. In the Xorg modesetting driver, the
> logic is basically:
>
> if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) {
> drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
> } else {
> drmModeAddFB(...);
> }
>
> There's no attempt to verify the DRM-KMS device supports the modifier,
> but then, why would there be? GBM presumably chose a supported modifier
> at buffer creation time, and we don't know which plane the FB is going
> to be used with yet. GBM doesn't actually ask the kernel which
> modifiers it supports here either though. It just goes into Mesa via
> DRI and reports the modifier (unpatched) Mesa chose on its own. Mesa
> just hard-codes the modifiers in its driver backends since its thinking
> in terms of a device's 3D engine, not display. In theory, Mesa's DRI
> drivers could query KMS for supported modifiers if allocating from GBM
> using the non-modifiers path and the SCANOUT flag is set (perhaps some
> drivers do this or its equivalent? Haven't checked.), but that seems
> pretty gnarly and doesn't fix the modifier-based GBM allocation path
> AFAIK. Bit of a mess.
Hi,
the way I believe it is supposed to work is that modesetting DDX first
asks KMS what modifiers it supports, and then passes that list to GBM
when it is attempting to create a gbm_bo or a gbm_surface. If
modesetting does not do that and still uses modifiers API for creating
bos or surfaces, modesetting is broken I believe.
gbm_bo_create_with_modifiers()
gbm_surface_create_with_modifiers()
Of course, this doesn't affect the need of a kernel workaround.
How is modesetting creating the bo or surface currently?
Why would the KMS driver starting to support modifiers API suddenly
make the buffers fail, does it change how the buffers get allocated in
modesetting as well?
Or maybe you're talking about something else than what I assumed, I'm
not really up-to-date here.
Thanks,
pq
Attachment:
pgpcNdRRvTT59.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
