On 17/10/17 01:04 PM, Nicolai Hähnle wrote: > On 17.10.2017 12:28, Michel Dänzer wrote: >> On 17/10/17 11:34 AM, Nicolai Hähnle wrote: >>> >>> Common sense suggests that there need to be two side to FreeSync / VESA >>> Adaptive Sync support: >>> >>> 1. Query the display capabilities. This means querying minimum / maximum >>> refresh duration, plus possibly a query for when the earliest/latest >>> timing of the *next* refresh. >>> >>> 2. Signal desired present time. This means passing a target timer value >>> instead of a target vblank count, e.g. something like this for the KMS >>> interface: >>> >>> int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id, >>> uint32_t flags, void *user_data, >>> uint64_t target); >>> >>> + a flag to indicate whether target is the vblank count or the >>> CLOCK_MONOTONIC (?) time in ns. >> >> drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative >> sync should probably only be supported via the atomic API, presumably >> via output properties. > > Time for xf86-video-amdgpu to grow atomic support, then? ;) Yes, that will likely be part of an upstreamable solution. There are already patches for this for the modesetting driver, adapting those might not be that hard. > How is a target vblank count communicated via the atomic API? Or is that > simply not part of the design and up to user space? >From Daniel's followup it sounds like there's no support for this yet in the atomic API, but I'm assuming it would be communicated via properties, as is the case for most things in the atomic API. -- 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
