This is increasingly not just related to screencopy, so it's weird to
add there. I don't see any other module that fits, so add one called
"quirks" (like the Linux kernel uses for device-specific handling in
generic drives).
This allows `cosmic-workspaces` to rely on cosmic-comp for rendering the
background, and just have transparency. This should be a more reliable
and performant way of doing things, at least for now.
Instead of adding another opaque bool argument, this defines an
`ElementFilter` enum, which makes calls more readable.
Window surfaces are still included in screencopy, as needed for the
workspace previews.
`(w_elements, p_elements)` tuples are used in a bunch of places. A
struct with named fields is generally an improvement just due to the
fact the order is non-obvious.
But we can also add methods. In particular,
`extend_from_workspace_elements` abstracts out some of the more
redundant code in `workspace_elements`.
It would be nice to avoid allocation everywhere, but iterators would
complicate lifetimes, run into issues with needing multiple mutable
borrows to things like the `Renderer`, and be awkward in certain
functions without generator syntax. In any case, cosmic-comp already
relies on allocating vectors here.
If this abstraction is commonly useful in compositors, perhaps it could
be moved to Smithay.
The default implementation always returned `Kind::Unspecified`. Instead,
we should pass this method through to the wrapped element.
This fixes the use of cursor planes. Now trace logs show Smithay
assigning an element to the cursor plane, and tools like `drm_info` show
the cursor plane with an `FB_ID` attached.
We'll probably want to add support for `cursor-shape-v1`. Not sure about
`wlr-data-control-unstable-v1`. But this just updates to work with the
latest smithay commit for new.