https://bugs.freedesktop.org/show_bug.cgi?id=32789
--- Comment #4 from Michel Dänzer <[email protected]> 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. _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
