Draft: commit-queue-v1

Hi!

I've been working for some time now on implementing the upcoming commit-queue-v1 and commit-timing-v1 protocols. I've been developing and testing both in conjunction, but here I only show commit-queue-v1. (This is still a WIP, but since I recently came across a similar draft for the commit-queue-v1, I guess it's best to show my approach and see if something comes out of it).

The idea is basically to use the mechanism in wlr_compositor for locking surface commits: wlr_surface_lock_pending()/wlr_surface_unlock_cached() lets us postpone the application of a wl_surface .commit request; this serves as a basis for my approach in both queue and timing.

commit-{queue|timing}-v1 listen for client_commit events, which are sent before actually applying the commit, locking the commit if some conditions are met (if there are pending commits in the queue, or if there is a valid timestamp, in the case of *timing-v1).

For *queue-v1, in this way we maintain a queue of pending commits. To unlock, we must know when the current wl_surface .commit request has been committed or presented on the output. There is no way to know this right now in wlroots, so I worked out a commit_present event on wlr_surfaces, which lets us know when a .commit request on a wl_surface made it into the next output commit (note the overloading of 'commit' here).

For the use cases for which commit-{queue|timing}-v1 are intended, wp_presentation is important because clients will most probably want to know the timing information of their commit requests. wlr_presentation_time in wlroots follows the double-buffer (pending/current) model of wlr_surface, so I implemented a similar generalization of its state to be able to queue them: so if a client uses *queue-v1, requests 5 commits that end up queued, and requests presentation feedback for each of them, we are able to send each feedback when its corresponding .commit gets presented.

A better explanation is in the commits' messages.