protocols/workspace: Store request queue in workspace manager udata

This is slightly simpler, if there's not some reason I'm missing to do
this as it was previously done. And in particular provides a cleaner
API (if we wanted to move this to Smithay; perhaps without the Cosmic
extension).

But it also should be more correct. Presumably if a client (unusually)
had multiple components with their own `ext_workspace_manager_v1`
instance, they should have their own queues, and
`ext_workspace_manager_v1::commit` should be independent.

Inevitably, there's a racy element to multiple components trying to
update the workspace state like this, but it should behave the same as
two clients with separate connections.

(This is different from `CompositorClientState`, since the commit queue
there is fundamentally tied to the client, and different components with
their own compositor instance way have related surfaces.)
This commit is contained in:
Ian Douglas Scott 2025-04-16 16:05:39 -07:00 committed by Ian Douglas Scott
parent 2f6d600502
commit e944ee9b2f
5 changed files with 106 additions and 113 deletions

View file

@ -24,7 +24,7 @@ use crate::{
screencopy::ScreencopyState,
toplevel_info::ToplevelInfoState,
toplevel_management::{ManagementCapabilities, ToplevelManagementState},
workspace::{WorkspaceClientState, WorkspaceState, WorkspaceUpdateGuard},
workspace::{WorkspaceState, WorkspaceUpdateGuard},
},
},
xwayland::XWaylandState,
@ -141,7 +141,6 @@ macro_rules! fl {
pub struct ClientState {
pub compositor_client_state: CompositorClientState,
pub workspace_client_state: WorkspaceClientState,
pub advertised_drm_node: Option<DrmNode>,
pub privileged: bool,
pub evls: LoopSignal,
@ -679,7 +678,6 @@ impl State {
pub fn new_client_state(&self) -> ClientState {
ClientState {
compositor_client_state: CompositorClientState::default(),
workspace_client_state: WorkspaceClientState::default(),
advertised_drm_node: match &self.backend {
BackendData::Kms(kms_state) => kms_state.primary_node,
_ => None,