On 2018-10-15 11:47 a.m., Christian König wrote: > Am 15.10.2018 um 11:40 schrieb Michel Dänzer: >> On 2018-10-13 7:38 p.m., Christian König wrote: >>> Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas: >>>> This patch introduces the 'vrr_enabled' CRTC property to allow >>>> dynamic control over variable refresh rate support for a CRTC. >>>> >>>> This property should be treated like a content hint to the driver - >>>> if the hardware or driver is not capable of driving variable refresh >>>> timings then this is not considered an error. >>>> >>>> Capability for variable refresh rate support should be determined >>>> by querying the vrr_capable drm connector property. >>>> >>>> It is worth noting that while the property is intended for atomic use >>>> it isn't filtered from legacy userspace queries. This allows for Xorg >>>> userspace drivers to implement support. >>> I'm honestly still not convinced that a per CRTC property is actually >>> the right approach. >>> >>> What we should rather do instead is to implement a target timestamp for >>> the page flip. >> You'd have to be more specific about how the latter could completely >> replace the former. I don't see how it could. > > Each flip request send by an application gets a timestamp when the flip > should be displayed. > > If I'm not completely mistaken we already have something like that in > both DRI2 as well as DRI3. Certainly not DRI2, but for now we're not enabling VRR with that anyway. While the X11 Present extension specifies PresentOptionUST for this, support for it isn't implemented yet in xserver (as in setting the option has no effect, the X server interprets the target value as an MSC anyway). So this couldn't work before the next major release of xserver, which based on recent history could be at least about one year away. In contrast, the CRTC property based solution for the gaming use-case can work even with older xserver versions. > So as far as I can see we only need to add an extra flag that those > information are trust worth in the context of VRR as well. > > If we don't set this flag we always get the always working fallback > behavior, e.g. VRR is disabled and we have a fixed refresh rate. > > If we set this flag and the timestamp is in the past we get the VRR > behavior to display the next frame as soon as possible. > > If we set this flag and specific a specific timestamp then we get the > VRR behavior to display the frame as close as possible to the specified > timestamp. Apart from the above, another issue is that this would give direct control to the client on whether or not VRR should be used. But we want to allow the user to disable VRR even if a client wants to use it, via an RandR output property. This requires that the Xorg driver can control whether or not VRR can actually be used, via the CRTC property added by this patch. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
