Previously, framebuffers were stored as fb_current and fb_pending. In this scheme, current was the last buffer that the kernel/hardware had acknowledged displaying: a framebuffer would be created, set as fb_pending, and Weston would request the kernel display it. When the kernel signals that the request was completed and the hardware had made the buffer current (i.e. page_flip_handler / vblank_handler), we would unreference the old fb_current, and promote fb_pending to fb_current. In other words, the view is 'which buffer has turned to light?'. This patch changes them to a tristate of fb_last, fb_current and fb_pending, based around the kernel's view of the current state. fb_pending is used purely as a staging area for request construction; when the kernel acknowledges a request (e.g. drmModePageFlip returns 0), the previous buffer is moved to fb_last, and this new buffer to fb_current. When the kernel signals that the request has completed and the hardware has made the buffer current, we simply unreference and clear fb_last, without touching fb_current/fb_pending. The view here is now 'which state is current in the kernel?'. As all state changes are incremental on the last state submitted to the kernel, even if the hardware has not yet been able to make it current, this simplifies state tracking: all state submissions will always be relative to fb_current, rather than the previous (fb_pending) ? fb_pending : fb_current. The use of fb_pending is strictly bounded between a repaint cycle (including a grouped set of repaints) beginning, and those repaints being flushed to the kernel. fb_current will always be valid between an output's first repaint flush, and when a disable/destroy request has been processed. For a plane, it will be valid when a repaint cycle enabling that plane has been flushed, and when a repaint cycle disabling that plane has been flushed. fb_last is only present when a repaint request for the output/plane has been submitted, but not yet completed by the hardware. This is the same set of constructs which will be used for storing plane/output state objects in future patches. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>dev
parent
863e66b003
commit
f30a18c1c3
Loading…
Reference in new issue