[PATCH 0/5] drm/sti: do not sync legacy IOCTL on vblank if not ATOMIC

Daniel Vetter daniel at ffwll.ch
Mon Jan 9 10:03:31 UTC 2017


On Thu, Jan 05, 2017 at 03:23:24PM +0000, Fabien DESSENNE wrote:
> Hi Daniel
> 
> 
> I come to the conclusion that (only) Atomic Weston will solve all of my 
> troubles, so let's forget these patches (and work for atomic weston).
> 
> By the way, is the expected behavior (Vblank - sync'ed or not) of 
> drmModeSetPlane() described anywhere? The last time I browsed the 
> related documentation I could not find the answer. Maybe something that 
> needs to be clarified ?

It's undefined and depends upon driver and platform and kernel version.
And all the work is done already, we've taken all the lessons learned from
legacy planes and made sure atomic sucks less ;-) There's no point in
changing/clarifying legacy semantics, at worst you'll end up breaking more
existing userspace. And we're not going to get uniform behaviour between
all drivers anyway for the legacy interfaces. Imo not worth the trouble,
let's just use atomic.
-Daniel


> I will also re-send patch 1 & 5 out of this abandoned series since they 
> make sense independently of this (a)sync stuff.
> 
> 
> BR.
> 
> 
> Fabien
> 
> 
> On 04/01/17 10:18, Daniel Vetter wrote:
> > On Tue, Jan 03, 2017 at 05:56:47PM +0100, Fabien Dessenne wrote:
> >> These patches allow a legacy framework (eg non-atomic Weston) to call
> >> several SETPLANE within the same Vsync cycle.
> >> - [PATCH 1/5] drm/sti: use atomic_helper for commit
> >> - [PATCH 2/5] drm/sti: add drm_file to sti_private
> >> - [PATCH 3/5] drm/sti: do not sync SETPLANE on vblank if not ATOMIC
> >> - [PATCH 4/5] drm/sti: do not sync SETPROPERTY on vblank if not ATOMIC
> >> - [PATCH 5/5] drm/sti: do not check hw scaling if mode is not set
> > Upstream weston never really enabled plane support, why exactly do you
> > need this? Also, if this really is required, I think we should implement
> > something like this (aka async plane flips) in general for everyone. sti
> > is by far not the only driver playing around with these games.
> > -Daniel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list