search

talex5 / wayland-proxy-virtwl

Allow guest VMs to open windows on the host
Apache License 2.0
110 stars 12 forks source link

wl_surface.commit should send xdg_surface.configure before processing the next event #58

Closed alyssais closed 1 year ago

alyssais commented 1 year ago

Most of the time, I get traces like this:

2023-06-27 10:07:34.311   wl-client [INFO]: 7 -> xdg_surface@11.get_toplevel id:+12
2023-06-27 10:07:34.312   wl-client [INFO]: 7 -> wl_surface@10.commit 
2023-06-27 10:07:34.313   wl-client [INFO]: 7 -> wl_display@1.sync callback:+13
2023-06-27 10:07:34.313   wl-client [INFO]: 7 <- wl_shm@4.format format:0
2023-06-27 10:07:34.314   wl-client [INFO]: 7 <- wl_shm@4.format format:1
2023-06-27 10:07:34.314   wl-client [INFO]: 7 <- wl_shm@4.format format:875709016
2023-06-27 10:07:34.315   wl-client [INFO]: 7 <- wl_shm@4.format format:875708993
2023-06-27 10:07:34.316   wl-client [INFO]: 7 <- wl_shm@4.format format:875710274
2023-06-27 10:07:34.316   wl-client [INFO]: 7 <- wl_shm@4.format format:842094674
2023-06-27 10:07:34.317   wl-client [INFO]: 7 <- wl_shm@4.format format:842088786
2023-06-27 10:07:34.317   wl-client [INFO]: 7 <- wl_shm@4.format format:892426322
2023-06-27 10:07:34.318   wl-client [INFO]: 7 <- wl_shm@4.format format:892420434
2023-06-27 10:07:34.319   wl-client [INFO]: 7 <- wl_shm@4.format format:909199186
2023-06-27 10:07:34.319   wl-client [INFO]: 7 <- wl_shm@4.format format:808665688
2023-06-27 10:07:34.320   wl-client [INFO]: 7 <- wl_shm@4.format format:808665665
2023-06-27 10:07:34.320   wl-client [INFO]: 7 <- wl_shm@4.format format:1211384408
2023-06-27 10:07:34.321   wl-client [INFO]: 7 <- wl_shm@4.format format:1211384385
2023-06-27 10:07:34.321   wl-client [INFO]: 7 <- wl_seat@7.capabilities capabilities:3
2023-06-27 10:07:34.322   wl-client [INFO]: 7 -> wl_seat@7.get_pointer id:+8
2023-06-27 10:07:34.322   wl-client [INFO]: 7 <- xdg_wm_base@6.ping serial:43474
2023-06-27 10:07:34.323   wl-client [INFO]: 7 <- xdg_toplevel@12.configure width:0 height:0 states:""
2023-06-27 10:07:34.324   wl-client [INFO]: 7 <- xdg_surface@11.configure serial:43473
2023-06-27 10:07:34.324   wl-client [INFO]: 7 <- wl_callback@13.done callback_data:43474
2023-06-27 10:07:34.325   wl-client [INFO]: 7 <- wl_display@1.delete_id id:13

This is correct, because the callback is triggered after the configure event has been sent.

But very occasionally, I get traces like this instead:

2023-06-27 09:45:54.862   wl-client [INFO]: 7 -> xdg_surface@11.get_toplevel id:+12
2023-06-27 09:45:54.862   wl-client [INFO]: 7 -> wl_surface@10.commit 
2023-06-27 09:45:54.863   wl-client [INFO]: 7 -> wl_display@1.sync callback:+13
2023-06-27 09:45:54.863   wl-client [INFO]: 7 <- wl_shm@4.format format:0
2023-06-27 09:45:54.863   wl-client [INFO]: 7 <- wl_shm@4.format format:1
2023-06-27 09:45:54.864   wl-client [INFO]: 7 <- wl_shm@4.format format:875709016
2023-06-27 09:45:54.864   wl-client [INFO]: 7 <- wl_shm@4.format format:875708993
2023-06-27 09:45:54.864   wl-client [INFO]: 7 <- wl_shm@4.format format:875710274
2023-06-27 09:45:54.864   wl-client [INFO]: 7 <- wl_shm@4.format format:842094674
2023-06-27 09:45:54.864   wl-client [INFO]: 7 <- wl_shm@4.format format:842088786
2023-06-27 09:45:54.865   wl-client [INFO]: 7 <- wl_shm@4.format format:892426322
2023-06-27 09:45:54.865   wl-client [INFO]: 7 <- wl_shm@4.format format:892420434
2023-06-27 09:45:54.865   wl-client [INFO]: 7 <- wl_shm@4.format format:909199186
2023-06-27 09:45:54.865   wl-client [INFO]: 7 <- wl_shm@4.format format:808665688
2023-06-27 09:45:54.865   wl-client [INFO]: 7 <- wl_shm@4.format format:808665665
2023-06-27 09:45:54.870   wl-client [INFO]: 7 <- wl_shm@4.format format:1211384408
2023-06-27 09:45:54.870   wl-client [INFO]: 7 <- wl_shm@4.format format:1211384385
2023-06-27 09:45:54.870   wl-client [INFO]: 7 <- wl_seat@7.capabilities capabilities:3
2023-06-27 09:45:54.871   wl-client [INFO]: 7 -> wl_seat@7.get_pointer id:+8
2023-06-27 09:45:54.871   wl-client [INFO]: 7 <- xdg_wm_base@6.ping serial:34047
2023-06-27 09:45:54.872   wl-client [INFO]: 7 <- wl_callback@13.done callback_data:34047
2023-06-27 09:45:54.872   wl-client [INFO]: 7 <- wl_display@1.delete_id id:13
2023-06-27 09:45:54.872   wl-client [INFO]: 7 <- xdg_toplevel@12.configure width:0 height:0 states:""
2023-06-27 09:45:54.872   wl-client [INFO]: 7 <- xdg_surface@11.configure serial:34046

This is not correct, because the callback is triggered before the configure event has been sent. Wayland clients depend on being able to wl_display_roundtrip() to wait for the xdg_surface to have been configured after sending wl_surface.commit.

I can only assume that this is a wayland-proxy-virtwl bug, because I've never seen it happen directly with my host compositor, and I've verified in #wayland that the client code looks correct.

talex5 commented 1 year ago

This is not correct, because the callback is triggered before the configure event has been sent. Wayland clients depend on being able to wl_display_roundtrip() to wait for the xdg_surface to have been configured after sending wl_surface.commit.

To wait for a surface to be configured, you should wait for the configured event I think. Sending a callback and hoping configuration finishes first sounds like it might work, but I don't recall seeing any guarantee about that.

Except for Xwayland, the proxy just relays sync requests to the host, so it shouldn't be affecting anything: https://github.com/talex5/wayland-proxy-virtwl/blob/f49f69a314e2cdec4cb6833d690be5f24009c2b1/relay.ml#L1308-L1316

If you run the proxy with -v, it will show both the host and client protocols, which might make it easier to see what's going on (i.e. whether the host replied to the callback before doing the configure).

alyssais commented 1 year ago

You're right. It's still a bit of a mystery to me how this happened if wayland-proxy-virtwl just relays everything back and worth, and sway (according to one of its maintainers) should send configure immediately, but this is a client bug, and it looks like it will be fixed in the client. Thanks!