Smithay
`BufferAssignment::NewBuffer::delta` is unused
The delta of wl_surface::attach is tracked in BufferAssignment::NewBuffer but ignored in the desktop abstractions.
It is unclear how they should be handled, given their are essentially hints for resizing windows. But they should probably be exposed somehow instead of just ignored by the on_commit_buffer_handler and dropped.
wlroots uses the delta for updating some external_damage on commit. For me it looks like the external_damage is similar to the damage in smithays space, so it could have something to do with movement.
I believe the attach-delta-loop example of wleird could be a good testbed for what behavior is expected with this delta.
Without attach, DND icons are also not placed correctly, they pass their offset by wl_surface.attach
For me this is no longer an issue, I just needed to have a way to access the delta, and that is done. The only question left would be, should desktop abstraction take delta into account on its own?
Good question, I guess if we are handling the buffer management, we also need to update the internal location of windows, if clients set a delta (which might give clients a way to move themselves... urgh).
Moving clients in the context of window tiling would be weird to say the least.
Protocol wise, delta is just a hit, we don't have to move the surface in response to it.
Personally, I use delta only for DND icon offset because: Initially, the top-left corner of the icon surface is placed at the cursor hotspot, but subsequent wl_surface.attach request can move the relative position.
So, I'd say it's compositor specific behavior.
How is the compatibility handled when binding version smaller than 5?
As it is officially discouraged to use the attach offset I think it is fine if we just ignore it, but from the code I am unsure
what happens when a client binds version 4 and sets an offset in attach.
Does to PR implement the protocol check for:
When the bound wl_surface version is 5 or higher, passing any non-zero x or y is a protocol violation, and will result in an 'invalid_offset' error being raised. To achieve equivalent semantics, use wl_surface.offset.
Lower then 5 works like it used to, 5 or higher rises a protocol error and expects you to use new offset message. https://github.com/Smithay/smithay/blob/c30fc14a4c638ee56f8dce2d43ab5f82df9ef414/src/wayland/compositor/handlers.rs#L174-L187