1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

//! XWayland related protocols

#![cfg_attr(rustfmt, rustfmt_skip)]

#[cfg(feature = "staging")]
pub mod shell {
    //! This protocol adds a xwayland_surface role which allows an Xwayland
    //! server to associate an X11 window to a wl_surface.
    //!
    //! Before this protocol, this would be done via the Xwayland server
    //! providing the wl_surface's resource id via the a client message with
    //! the WL_SURFACE_ID atom on the X window.
    //! This was problematic as a race could occur if the wl_surface
    //! associated with a WL_SURFACE_ID for a window was destroyed before the
    //! client message was processed by the compositor and another surface
    //! (or other object) had taken its id due to recycling.
    //!
    //! This protocol solves the problem by moving the X11 window to wl_surface
    //! association step to the Wayland side, which means that the association
    //! cannot happen out-of-sync with the resource lifetime of the wl_surface.
    //!
    //! This protocol avoids duplicating the race on the other side by adding a
    //! non-zero monotonic serial number which is entirely unique that is set on
    //! both the wl_surface (via. xwayland_surface_v1's set_serial method) and
    //! the X11 window (via. the `WL_SURFACE_SERIAL` client message) that can be
    //! used to associate them, and synchronize the two timelines.
    //!
    //! The key words "must", "must not", "required", "shall", "shall not",
    //! "should", "should not", "recommended",  "may", and "optional" in this
    //! document are to be interpreted as described in IETF RFC 2119.

    #[allow(missing_docs)]
    pub mod v1 {
        wayland_protocol!(
            "./protocols/staging/xwayland-shell/xwayland-shell-v1.xml",
            []
        );
    }
}

#[cfg(feature = "unstable")]
pub mod keyboard_grab {
    //! Protocol for grabbing the keyboard from Xwayland
    //!
    //! This protocol is application-specific to meet the needs of the X11
    //! protocol through Xwayland. It provides a way for Xwayland to request
    //! all keyboard events to be forwarded to a surface even when the
    //! surface does not have keyboard focus.
    //!
    //! In the X11 protocol, a client may request an "active grab" on the
    //! keyboard. On success, all key events are reported only to the
    //! grabbing X11 client. For details, see XGrabKeyboard(3).
    //!
    //! The core Wayland protocol does not have a notion of an active
    //! keyboard grab. When running in Xwayland, X11 applications may
    //! acquire an active grab inside Xwayland but that cannot be translated
    //! to the Wayland compositor who may set the input focus to some other
    //! surface. In doing so, it breaks the X11 client assumption that all
    //! key events are reported to the grabbing client.
    //!
    //! This protocol specifies a way for Xwayland to request all keyboard
    //! be directed to the given surface. The protocol does not guarantee
    //! that the compositor will honor this request and it does not
    //! prescribe user interfaces on how to handle the respond. For example,
    //! a compositor may inform the user that all key events are now
    //! forwarded to the given client surface, or it may ask the user for
    //! permission to do so.
    //!
    //! Compositors are required to restrict access to this application
    //! specific protocol to Xwayland alone.

    /// Unstable version 1
    pub mod zv1 {
        wayland_protocol!(
            "./protocols/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml",
            []
        );
    }
}