Re: [PATCH i-g-t] lib/igt_kms: Identify writeback connectors in msm driver on android

[Jani Nikula <jani.nikula@intel.com>]

On Wed, 08 Apr 2026, Harshdeep Dhatt <harshdeepdhatt@gmail.com> wrote:
> Thanks for the feedback.
>
> Yes, this quirk is specifically for the downstream MSM DRM driver used on
> Android devices. The upstream MSM driver does not need this, and the intent
> is not to modify or affect upstream MSM behavior in any way.
>
> The goal here is to allow IGT to run on Qualcomm-based Android platforms,
> which currently expose writeback connectors differently (as VIRTUAL
> connectors with a custom "FB_ID" property). Without assigning a writeback
> FB, the driver rejects the atomic commit, causing several IGT tests to fail
> early.
>
> All of the logic in this patch is fully isolated behind detection of the
> downstream Android MSM driver (`"msm_drm"`). Upstream MSM continues to use
> the existing code paths unchanged.
>
> IGT’s documentation states that it aims to be a universal test suite for
> DRM/KMS drivers on Linux *and similar platforms*. Supporting the downstream
> MSM driver helps extend IGT coverage to a widely deployed class of devices
> without impacting upstream users.
>
> If it would be preferable, I can restructure this into a dedicated
> “msm-android quirk” helper or move the detection/handling into a separate
> file so that the core paths remain untouched. 
>
> This keeps all non-upstream behavior contained in one place, avoids
> polluting the main code paths, and provides a maintainable structure for
> any future quirks that may be needed for other platforms. Upstream MSM
> remains unaffected, and the quirk only activates when running on the
> downstream Android MSM driver.
>
> I’m happy to adjust the approach based on your guidance.

Cc'd some more folks.

As a contributor, I'm not very fond of the idea of tiptoeing around code
in IGT that caters for some downstream vendor kernels. I'm not going to
go hunting for those sources. Hardly anyone will.

I'm not an IGT maintainer. I'm not making decisions on what is, and is
not, acceptable new maintenance burden to take on.

But the maintainers do have a decision to make. The options are to
support either 0 or N downstream kernels. If you take one, you can't
reasonably refuse anything after that. Even if the patch at hand is
benign, the precedent it sets is emphatically not.


BR,
Jani.


-- 
Jani Nikula, Intel