search

swaywm / wlr-protocols

Wayland protocols designed for use in wlroots (and other compositors)
122 stars 29 forks source link

Race in output-management heads/modes #62

Open emersion opened 5 years ago

emersion commented 5 years ago

When plugging out an output, this sequence of events can happen (and happens in practice, see https://github.com/emersion/kanshi/issues/55):

  1. Compositor sends zwlr_output_head_v1.finished and destroys the object immediately. Compositor also sends a zwlr_output_manager_v1.done event with a fresh serial to apply the changes.
  2. Client hasn't received the events yet. It creates a new zwlr_output_configuration_v1 with an (outdated) serial. It issues a zwlr_output_configuration_v1.enable_head request with the object that has just been destroyed by the compositor.
  3. Compositor receives the request and libwayland disconnects the client with wl_display@1: error 1: invalid arguments for zwlr_output_configuration_v1@5.enable_head.

This is a race in the protocol itself. The only thing I can think of to fix it is to stop destroying immediately the zwlr_output_head_v1 objects. Instead, let the client issue a destroy request.

any1 commented 3 years ago

Another consequence of server created objects racing with the client's object map is that when the server destroys object and creates new ones immediately after, it will send the client "new objects" with object ids that the client still has pointing to the old objects because it hasn't had a chance to remove them from its own object map when the new objects are demarshalled. Thus, the client aborts.

emersion commented 3 years ago

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/62