Groundwork for wp_linux_explicit_synchronization
Created by: ascent12
Another entry in my series of massive PRs that I take too long to finish.
Groundwork needed for #894 Closes #1546 (closed)
Due to the very large amount of API breakage this introduces, I'd like to give people a heads up and get any feedback on the new design.
To see a full explanation for why I'm doing this, see the issues linked above. But to sum it up quickly:
Our current state-keeping method won't work for explicit-synchronization, since a surface being committed now doesn't really mean it's ready to be shown. Instead of just "pending" and "current", we have to keep a queue of commits, so that we always have a valid buffer handy.
The core part of this is wlr_commit. This represents a "coherent presentation" of the client's contents, and should contain all of the information to render a client correctly. Every bit of state synchronized by wl_surface.commit should be changed to use this.
Todo:
-
wlr_compositor -
wlr_subcompositor -
wlr_xdg_shell and related (WIP) -
wlr_xdg_shell_v6 and related (There have been talks of removing this anyway) -
wlr_fullscreen_shell_v1 -
wlr_layer_shell_v1 -
xwm -
wlr_presentation_time -
wlr_linux_explicit_synchronization (Only acquire fences; maybe a different PR) -
wlr_buffer -
wlr_renderer -
wlr_seat and related (They set wlr_surface roles) -
wlr_pointer_constraints -
Other trivial uses of wlr_surface (e.g. wlr_output) -
tinywl -
rootston -
More comments and documentation
Extra notes:
- All wlr_surface functions are being merged into wlr_compositor. I haven't removed the old code yet, so I'm using a _2 suffix to just prevent some conflicts. That'll be removed eventually.
- wlr_region functions were merged into wlr_compositor.
- wlr_subcompositor was split out from wlr_compositor, technically making this an optional interface (but you'd want to use it)
- wlr_subcompositor is definitely the hardest part of this, because it's simply a complicated specification. Changing the other protocols will be much easier by comparison.
- I don't want wlr_surface managing any real buffer operations
- wl_shm should be added to the renderer (using wlr_shm from another of my PRs)
- Some callback functions to get information for a wlr_buffer would be needed, as they're needed for protocol compliance checks.
- I haven't done any real testing on a lot of the current code; more protocols need to be done before I can look at doing tinywl and rootston and giving it a real go. I've done some basic hack code to test the bare essentials, though.