The logic `age_for_buffer` used seems to be a misinterpretation of the
protocol.
The wording is a little unclear, but it seems tracking buffer age is the
responsibility of the client, and the client is required to accumulate
damage and pass it in `damage_buffer`.
Our clients initially weren't doing that correctly. I updated
xdg-desktop-portal-cosmic to use `damage_buffer` after testing on
wlroots, and cosmic-workspaces was recently updated as well.
The important change here is that we now apply the additional damage
first, instead of using `.extend()` to add it after other elements. This
is important since `OutputDamageTracker` will ignore our damage elements
if there are behind an element with an opaque region.
This also makes things a bit simpler, especially `take_screencopy_frames()`,
which no longer needs a mutable references to extend then truncate.
The implementation of `OutputDamageTracker` isn't entirely clear, but as
far as I can tell this is intended to work, and it seems to work in some
testing.
This doesn't change much, since the Smithay implementation is based on
the `cosmic-comp` version, but made more generic. We provide our own
implementation for our workspace capture protocol, but otherwise Smithay
handles the boilerplate now.
This should not cause any change in behavior.
Previously, `unmap_surface` automatically pushed all unmapped windows
into the `pending_windows` list. This behavior is correct for X11
windows (which may be remapped) but incorrect for Wayland `toplevel_destroyed`
events, where the role is permanently gone.
This caused issues with clients like Telegram that reuse `wl_surface`s.
Because the destroyed toplevel remained in `pending_windows`, a
subsequent cleanup commit (e.g., null buffer) triggered a configure
event. This prematurely marked the surface as `configured` in the
shell state.
Consequently, when the client attached a new `xdg_toplevel` role,
the compositor skipped the mandatory initial configure event (assuming
it was already done), causing the window to never appear.
This refactors `unmap_surface` to return `Option<PendingWindow>`
instead of mutating global state.
- XWayland: Explicitly saves the pending window (behavior preserved).
- XDG Shell: Drops the pending window, preventing ghost state interactions.
Fixes#1816
Allow X11 clients to activate a window.
This shares the logic with xdg-activation. It might make sense to handle
the urgent hint on an X11 Window natively, but for now this just marks a
workspace as urgent on activation in the same way xdg-activation does.
If we want to use the `org.freedesktop.a11y.KeyboardMonitor` protocol on
Pop!_OS, there is no need to support the Cosmic-specific protocol that
requires an `at-spi2-core` patch.
cosmic-comp panics here after launching an app from the app tray overflow popup. While it may indicate a panel issue that I also need to look into, it seems to work fine if we don't unwrap on this option.
This is identical to the wlr protocol, and Smithay has implementations
for both.
New clients should use the `ext` protocol where present. Not sure how
widely used it is yet, but we probably should have both for now.
Some users have complained about not supporting clipboard managers. But
this was possible, but hidden under the `COSMIC_DATA_CONTROL_ENABLED`
env var.
Since the security context protocol exists now to provide a way to not
expose a protocol like this to sandboxed clients, it should be safe to
expose this now.
`privileged` now only indicates if a client is "sandboxed", i.e. it has
a security context, where the sandbox engine isn't cosmic-panel.
So replace the field with a method that's a bit more descriptive.
It seems https://github.com/pop-os/cosmic-comp/pull/1638 caused an issue
in cosmic-workspaces, where if there are multiple toplevels, when
dragging a toplevel, the drag surface would appear in capture for other
toplevels.
For now, omit drag surface in toplevel capture without `draw_cursor`.
Though I guess ultimately we do want it for metadata cursor capture in
the portal, but not in cosmic-workspaces? Maybe the protocol needs some
additional option for this...
`CosmicMapped::cursor_positon` may have worked previously, but doesn't
now.
This is based on the code used for seperate cursor capture sessions.
Maybe this could be consolidated in some way.
But this seems to work. Including for rotated outputs.
This fixes two issues:
- The `area` passed to `to_buffer()` should match the dimensions of the
output/etc. being captured, rather than coming from the damage rect
size.
- The transform needs to be inverted.
Previously, rotated outputs could cause a crash
`xdg-desktop-portal-cosmic`, since the compositor was passing negative
coordinates in `damage`, and the client used the same in
`damage_buffer`. This was causing
https://github.com/pop-os/xdg-desktop-portal-cosmic/issues/165.
The portal crash no longer occurs, and logging in
xdg-desktop-portal-cosmic shows damage rects that match expectation
while moving the cursor over different corners of a workspace.
The `id` is defined to be sent only once, on creation of the handle or
later. And only for workspaces that are "likely to be stable across
multiple sessions".
Set we add an `id` initially for pinned workspaces, and add one when the
workspace is pinned.
The `id` is not supposed to be human readable, so we just use a random
value.
Adding anything else to this tuple is awkward; defining a simple struct
makes this cleaner.
This also adds a `sync` property, which will come in handy later.
Containing simply the same-named argument that was passed to
`submit_buffer`.
