On 2018-04-10 07:44 AM, Chris Wilson wrote:
> Quoting Christian K├Ânig (2018-04-10 07:45:04)
>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
>>> Properties that you mentioned above that the UMD can set before kernel can 
>>> enable VRR functionality
>>> *bool vrr_enable or vrr_compatible
>>> target_frame_duration_ns
>> Yeah, that certainly makes sense. But target_frame_duration_ns is a bad 
>> name/semantics.
>> We should use an absolute timestamp where the frame should be presented, 
>> otherwise you could run into a bunch of trouble with IOCTL restarts or 
>> missed blanks.
> Hear, hear. I was disappointed not to see this be the starting point of
> the conversation. Imo, the uABI should in terms of absolutes with the
> drivers mapping that onto HW and reporting back the discrepancies.

I think it's just that some of us that work on KMD display drivers have had our 
work primarily guided by different use cases, such as gaming, which has then be 
extended to provide a better experience for video as well. We might not be as 
intimately aware of some of the work that's been done on video APIs and the 
pains involved in it but are always happy to learn and work together toward the 
best solution.


> -Chris
dri-devel mailing list

Reply via email to