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

Kazlauskas, Nicholas Nicholas.Kazlauskas at amd.com
Tue Apr 30 12:21:58 UTC 2019


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


More information about the dri-devel mailing list