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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
> 
> [...]
>  
>  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
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux