[PATCH 6/6] drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags

[Michel Dänzer]

On 04.08.2016 16:42, Ville Syrjälä wrote:
> On Thu, Aug 04, 2016 at 12:39:41PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daenzer at amd.com>
>>
>> These flags allow userspace to explicitly specify the target vertical
>> blank period when a flip should take effect.
> 
> I like the idea. Atomic could use this too, although there we'd need to
> potentially pass in a target vblank for each crtc taking part of the
> operation, or I suppose you could pass it only for, say, a single crtc
> in case you only want ot sync to that one.

Yes, userspace tends to just synchronize to one CRTC and doesn't
particularly care about any others performing the same flip.


> One thing I've pondered in the past is the OML_sync_control modulo stuff.
> Looks like what you have here won't free up userspace from doing the
> wait_vblank+flip sequence if it wants to implement the modulo behaviour.
> And of course it's still not guaranteed to honor the modulo if, for
> instance, the flip ioctl itself gets blocked on a mutex for a wee bit too
> long and misses the target. So should we just implement the modulo stuff
> in the kernel instead?

That might be nice, but I'm afraid it would be rather more complex than
this patch for various reasons. E.g., in no particular order:

The modulo can't be passed to the ioctl without extending the struct
used by the ioctl, which could be tricky to get right in all corner cases.

The current driver interface of the Present extension code in xserver
wouldn't allow making use of it, the xserver code already handles the
modulo before calling into the driver.

The kernel driver interface would have to change significantly as well,
it would be basically the driver's responsibility to handle the modulo.
It would also be rather tricky to make it work reliably with our
hardware, because we can't reliably determine in advance when a flip
will take effect in the hardware.


Overall, it seems like too much effort for too little gain with the
legacy KMS API. Might be worth tackling for atomic though.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer