[Bug 32789] VSync loss after rotation to portrait mode

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32789

--- Comment #4 from Michel Dänzer <michel at daenzer.net> 2011-01-04 02:35:47 PST ---
(In reply to comment #3)
> If I understand correctly, the X server is responsible for this?

The X driver. The X server doesn't have any concept of tearing avoidance yet.

> Efficiency issues aside, I guess the simplest approach would be to patch X to
> wait for vblank before drawing to the rotated frontbuffer? Is this approach feasible?

Option "EXAVSync" does almost that, except it doesn't wait for vblank but just
for scanout to be outside of the rectangle being updated. The tearing you're
still seing may be due to several conceptually related rectangles ending up
being updated during different scanout frames. Or maybe there's a problem which
prevents the updates from happening outside of scanout in all cases.

Either way, waiting for vblank might be a solution for the tearing, but the
driver doesn't have enough knowledge to do that without murdering performance
when there's lots of rectangles to update. It would have to be done more
explicitly at a higher level. One possible solution being discussed is to make
the compositing manager responsible for rendering the rotated output.

> (Actually, why doesn't X allocate a 1080x1920 frontbuffer from the beginning
> and prefers to allocate a second one and copy+rotate its contents?)

Different RandR CRTCs can have different rotations.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.