I hoped to split this up into multiple commits, but the api
changes to `shell/workspace.rs` were to invasive to feasibly do this.
Here is a rough list of changes:
- Fullscreen windows aren't mapped to other layers anymore
- This they need their own logic for:
- Sending frames
- Dmabuf Feedback
- Primary outputs
- On commit handlers
- cursor tests
- They get their own unmap/remap logic
- They get a new restore state similar to minimized windows
- Refactored the minimized window state to reuse as much as possible
here
- They need to be part of focus stacks, which means adjusting them
to a new type `FocusTarget` as they previously only handled
`CosmicMapped`.
- Various shell handlers (minimize, move, menu) now have dedicated
logic for fullscreen surfaces
- This was partially necessary due to relying on CosmicSurface now,
partially because they should've had their own logic from the
start. E.g. the context menu is now reflecting the fullscreen
state
- Fullscreen windows may be rendered behind other windows now, when they
loose focus.
- This needed changes to input handling / rendering
Similar to the change in https://github.com/pop-os/cosmic-comp/pull/780,
but also updates it to be a little clearer than just an uncommented `age
= 0` line.
Ideally we want some robust system to re-use the offscreen buffer (but
not allocate more buffers indefinitely if the client doesn't capture
with the same `wl_buffer`).
It seems previously, workspace migration due to output add could result in
a workspace being removed from a group, but not added to the new group
for existing clients, because the workspace group creation didn't happen
until `done`. And `send_workspace_to_client` didn't send
`workspace_enter` except when a workspace instance is newly created.
That logic worked with the old protocol, but now a workspace can be
moved to a different group.
Seems to fix the issue with workspaces disappearing from the workspaces
view in https://github.com/pop-os/cosmic-comp/issues/1470. I don't seem
to be able to reproduce the panel auto-hide issue, but have seen it in
the past. So it may or may not be prevented from happening now.
This matches behavior in X11 sessions (Gnome and i3). It presumably is
reasonable to have the same behavior here as with Wayland-native
keyboard shortcut inhibition.
A solution for https://github.com/Smithay/smithay/issues/1714.
With this, the lock screen is able to get keyboard focus normally, but
focus then reverts to the XWayland grab surface. This can be tested with
the example client from the issue.
Adding a new variant of `KeyboardFocusTarget` is annoying. Maybe it
could map to a different variant of the enum. But it presumably needs to
handle any `wl_surface` XWayland uses. (Override redirect surfaces?
Subsurfaces?) This seems as good as anything for now.
Previously, if `expected_node` couldn't import a buffer, it would print
an error, then try the next node. There shouldn't really be a reason to
attempt import if the format/modifier isn't in `dmabuf_texture_formats`.
It seems the issue I've been seeing with cosmic-workspaces crashing
the Nvidia driver is fixed by removing this, and disabling `dma_shadow_copy`
(which was producing the same error). Importing Nvidia buffers on the AMD
GPU seems to be causing issues.
Not sure how `dma_shadow_copy` should be fixed, but a test for supported
formats is easy to add here anyway.
This ensures that a commit to a cursor or drag surface will queue a
redraw, even if nothing else has changed on screen.
This can be tested by running `vkgears` in an otherwise empty
cosmic-comp instance, and dragging it.
It can still get unthrottled frame callbacks by not having any primary
scanout output, but presumably we want this. Alongside the code setting
it for cursor surfaces, and dragged windows.
Previously, some errors in the screencopy code resulted in `redraw`
returning an error, while others make the screencopy frame fail, and
logged a warning.
Instead, make all errors here log a warning, and call `reset()` on the
session, but continue running `redraw()`.
Calling `frame.error` explictly isn't needed, since the same error will
be sent on drop otherwise.
Fixes an issue where a dual GPU system would keep allocating dGPU PBOs in
`cpu_copy()` every frame, but `cleanup()` was not being called, since the
surface thread for the builtin output was rendered on the
primary/integrated GPU, targeting the same GPU.
Even if a different monitor was compositing on the dGPU, That wouldn't
help since that thread has it's own `GpuManager` with it's own renderer
and cache.
Running cleanup at the end (or start) of each frame seems like a good
idea. Not sure if it would be best to avoid additional calls, or if
that's desirable/fine.
