On Mon, 15 Oct 2018 12:06:52 +0200 Michel Dänzer <michel@xxxxxxxxxxx> wrote: > 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. Hi > In contrast, the CRTC property based solution for the gaming use-case > can work even with older xserver versions. This is probably the heaviest reason. Coming up with a KMS UABI for target timestamps could get complicated. Do you need a flip queue deeper than one? Do you need to be able to cancel flips? > > 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. It would not imply direct control to clients. The target timestamps go through the X server, the X server can mangle them or remove them before calling KMS any way it wants. The X server can invent a RandR property to disable/enable VRR. One would need a video-DDX update the very minimum to start passing the timestamps to the kernel, so there is no way VRR would be enabled unwanted. Thanks, pq
Attachment:
pgpg0BW1nqSgR.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
