[PATCH] drm/amd/display: Allow faking displays as VRR capable.

[Kazlauskas, Nicholas]

On 4/30/19 3:44 AM, Michel Dänzer wrote:
> [CAUTION: External Email]
> 
> On 2019-04-30 9:37 a.m., Mario Kleiner wrote:
>> Allow to detect any connected display to be marked as
>> VRR capable. This is useful for testing the basics of
>> VRR mode, e.g., scheduling and timestamping, BTR, and
>> transition logic, on non-VRR capable displays, e.g.,
>> to perform IGT test-suit kms_vrr test runs.
>>
>> This fake VRR display mode is enabled by setting the
>> optional module parameter amdgpu.fakevrrdisplay=1.
>>
>> It will try to use VRR range info parsed from EDID on
>> DisplayPort displays which have a compatible EDID,
>> but not compatible DPCD caps for Adaptive Sync. E.g.,
>> NVidia G-Sync compatible displays expose a proper EDID,
>> but not proper DPCD caps.
>>
>> It will use a hard-coded VRR range of 30 Hz - 144 Hz on
>> other displays without suitable EDID, e.g., standard
>> DisplayPort, HDMI, DVI monitors.
>>
>> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
>>
>> [...]
>>
>>   struct amdgpu_mgpu_info mgpu_info = {
>>        .mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
>> @@ -665,6 +666,16 @@ MODULE_PARM_DESC(halt_if_hws_hang, "Halt if HWS hang is detected (0 = off (defau
>>   MODULE_PARM_DESC(dcfeaturemask, "all stable DC features enabled (default))");
>>   module_param_named(dcfeaturemask, amdgpu_dc_feature_mask, uint, 0444);
>>
>> +/**
>> + * DOC: fakevrrdisplay (int)
>> + * Override detection of VRR displays to mark any display as VRR capable, even
>> + * if it is not. Useful for basic testing of VRR without need to attach such a
>> + * display, e.g., for igt tests.
>> + * Setting 1 enables faking VRR. Default value, 0, does normal detection.
>> + */
>> +module_param_named(fakevrrdisplay, amdgpu_fake_vrr_display, int, 0644);
>> +MODULE_PARM_DESC(fakevrrdisplay, "Detect any display as VRR capable (0 = off (default), 1 = on)");
> 
> amdgpu has too many module parameters already; IMHO this kind of niche
> use-case doesn't justify adding yet another one. For the vast majority
> of users, this would just be another knob to break things, resulting in
> support burden for us.
> 
> How about e.g. making the vrr_capable property mutable, or adding
> another property for this?
> 
> 
> --
> Earthling Michel Dänzer               |              https://www.amd.com
> Libre software enthusiast             |             Mesa and X developer
> 

Since vrr_capable is already an optional property I think making it 
mutable could potentially be an option. It would allow for userspace to 
be able to disable capability as well that way.

It's a pretty niche usecase though. However, as Michel said, it would 
probably just end up being another setting that allows users to break 
their own setup.

Nicholas Kazlauskas