From 721fe5ee776ee5a4e9fd700cd1e0ab0a208dd7b4 Mon Sep 17 00:00:00 2001 From: Shawn Wallace Date: Tue, 11 Jun 2024 23:30:58 -0400 Subject: [PATCH] Flush after wl_shm_pool destruction Bit of a hacky fix for #12. It seems like the issue is caused by too many wl_shm_pools being created and then destroyed before being flushed to the parent compositor. Might negatively impact performance, but most performant things shouldn't be using wl_shm anyway. --- src/server/dispatch.rs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/server/dispatch.rs b/src/server/dispatch.rs index 2a52451..5999c13 100644 --- a/src/server/dispatch.rs +++ b/src/server/dispatch.rs @@ -241,13 +241,13 @@ impl Dispatch for ServerState { } } -impl Dispatch for ServerState { +impl Dispatch for ServerState { fn request( state: &mut Self, _: &wayland_server::Client, _: &WlShmPool, request: ::Request, - c_pool: &ClientShmPool, + c_pool: &client::wl_shm_pool::WlShmPool, _: &DisplayHandle, data_init: &mut wayland_server::DataInit<'_, Self>, ) { @@ -261,7 +261,7 @@ impl Dispatch for ServerState { format, } => { state.objects.insert_with_key(|key| { - let client = c_pool.pool.create_buffer( + let client = c_pool.create_buffer( offset, width, height, @@ -275,7 +275,8 @@ impl Dispatch for ServerState { }); } Request::::Destroy => { - c_pool.pool.destroy(); + c_pool.destroy(); + state.clientside.queue.flush().unwrap(); } other => warn!("unhandled shmpool request: {other:?}"), } @@ -297,7 +298,6 @@ impl Dispatch> match request { Request::::CreatePool { id, fd, size } => { let c_pool = client.create_pool(fd.as_fd(), size, &state.qh, ()); - let c_pool = ClientShmPool { pool: c_pool, fd }; data_init.init(id, c_pool); } other => {