1 //! Unstable protocols from wayland-protocols 2 //! 3 //! The protocols described in this module are experimental and 4 //! provide no guarantee of forward support. They may be abandoned 5 //! or never widely implemented. 6 //! 7 //! Backward compatible changes may be added together with the 8 //! corresponding interface version bump. 9 //! 10 //! Backward incompatible changes are done by bumping the version 11 //! number in the protocol and interface names and resetting the 12 //! interface version. Once the protocol is to be declared stable, 13 //! the 'z' prefix and the version number in the protocol and 14 //! interface names are removed and the interface version number is 15 //! reset. 16 17 #![cfg_attr(rustfmt, rustfmt_skip)] 18 19 pub mod fullscreen_shell { 20 //! Fullscreen shell protocol 21 22 /// Unstable version 1 23 pub mod v1 { 24 wayland_protocol!( 25 "./protocols/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml", 26 [] 27 ); 28 } 29 } 30 31 pub mod idle_inhibit { 32 //! Screensaver inhibition protocol 33 34 /// Unstable version 1 35 pub mod v1 { 36 wayland_protocol!( 37 "./protocols/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml", 38 [] 39 ); 40 } 41 } 42 43 pub mod input_method { 44 //! Input method protocol 45 46 /// Unstable version 1 47 pub mod v1 { 48 wayland_protocol!( 49 "./protocols/unstable/input-method/input-method-unstable-v1.xml", 50 [] 51 ); 52 } 53 } 54 55 pub mod input_timestamps { 56 //! Input timestamps protocol 57 58 /// Unstable version 1 59 pub mod v1 { 60 wayland_protocol!( 61 "./protocols/unstable/input-timestamps/input-timestamps-unstable-v1.xml", 62 [] 63 ); 64 } 65 } 66 67 pub mod keyboard_shortcuts_inhibit { 68 //! Protocol for inhibiting the compositor keyboard shortcuts 69 //! 70 //! This protocol specifies a way for a client to request the compositor 71 //! to ignore its own keyboard shortcuts for a given seat, so that all 72 //! key events from that seat get forwarded to a surface. 73 74 /// Unstable version 1 75 pub mod v1 { 76 wayland_protocol!( 77 "./protocols/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml", 78 [] 79 ); 80 } 81 } 82 83 pub mod linux_dmabuf { 84 //! Linux DMA-BUF protocol 85 86 /// Unstable version 1 87 pub mod v1 { 88 wayland_protocol!( 89 "./protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml", 90 [] 91 ); 92 } 93 } 94 95 pub mod linux_explicit_synchronization { 96 //! Linux explicit synchronization protocol 97 98 /// Unstable version 1 99 pub mod v1 { 100 wayland_protocol!( 101 "./protocols/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml", 102 [] 103 ); 104 } 105 } 106 107 pub mod pointer_constraints { 108 //! protocol for constraining pointer motions 109 //! 110 //! This protocol specifies a set of interfaces used for adding constraints to 111 //! the motion of a pointer. Possible constraints include confining pointer 112 //! motions to a given region, or locking it to its current position. 113 //! 114 //! In order to constrain the pointer, a client must first bind the global 115 //! interface "wp_pointer_constraints" which, if a compositor supports pointer 116 //! constraints, is exposed by the registry. Using the bound global object, the 117 //! client uses the request that corresponds to the type of constraint it wants 118 //! to make. See wp_pointer_constraints for more details. 119 120 /// Unstable version 1 121 pub mod v1 { 122 wayland_protocol!( 123 "./protocols/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml", 124 [] 125 ); 126 } 127 } 128 129 pub mod pointer_gestures { 130 //! Pointer gestures protocol 131 132 /// Unstable version 1 133 pub mod v1 { 134 wayland_protocol!( 135 "./protocols/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml", 136 [] 137 ); 138 } 139 } 140 141 pub mod primary_selection { 142 //! Primary selection protocol 143 144 /// Unstable version 1 145 pub mod v1 { 146 wayland_protocol!( 147 "./protocols/unstable/primary-selection/primary-selection-unstable-v1.xml", 148 [] 149 ); 150 } 151 } 152 153 pub mod relative_pointer { 154 //! protocol for relative pointer motion events 155 //! 156 //! This protocol specifies a set of interfaces used for making clients able to 157 //! receive relative pointer events not obstructed by barriers (such as the 158 //! monitor edge or other pointer barriers). 159 //! 160 //! To start receiving relative pointer events, a client must first bind the 161 //! global interface "wp_relative_pointer_manager" which, if a compositor 162 //! supports relative pointer motion events, is exposed by the registry. After 163 //! having created the relative pointer manager proxy object, the client uses 164 //! it to create the actual relative pointer object using the 165 //! "get_relative_pointer" request given a wl_pointer. The relative pointer 166 //! motion events will then, when applicable, be transmitted via the proxy of 167 //! the newly created relative pointer object. See the documentation of the 168 //! relative pointer interface for more details. 169 170 /// Unstable version 1 171 pub mod v1 { 172 wayland_protocol!( 173 "./protocols/unstable/relative-pointer/relative-pointer-unstable-v1.xml", 174 [] 175 ); 176 } 177 } 178 179 pub mod tablet { 180 //! Wayland protocol for graphics tablets 181 //! 182 //! This description provides a high-level overview of the interplay between 183 //! the interfaces defined this protocol. For details, see the protocol 184 //! specification. 185 //! 186 //! More than one tablet may exist, and device-specifics matter. Tablets are 187 //! not represented by a single virtual device like wl_pointer. A client 188 //! binds to the tablet manager object which is just a proxy object. From 189 //! that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat) 190 //! and that returns the actual interface that has all the tablets. With 191 //! this indirection, we can avoid merging wp_tablet into the actual Wayland 192 //! protocol, a long-term benefit. 193 //! 194 //! The wp_tablet_seat sends a "tablet added" event for each tablet 195 //! connected. That event is followed by descriptive events about the 196 //! hardware; currently that includes events for name, vid/pid and 197 //! a wp_tablet.path event that describes a local path. This path can be 198 //! used to uniquely identify a tablet or get more information through 199 //! libwacom. Emulated or nested tablets can skip any of those, e.g. a 200 //! virtual tablet may not have a vid/pid. The sequence of descriptive 201 //! events is terminated by a wp_tablet.done event to signal that a client 202 //! may now finalize any initialization for that tablet. 203 //! 204 //! Events from tablets require a tool in proximity. Tools are also managed 205 //! by the tablet seat; a "tool added" event is sent whenever a tool is new 206 //! to the compositor. That event is followed by a number of descriptive 207 //! events about the hardware; currently that includes capabilities, 208 //! hardware id and serial number, and tool type. Similar to the tablet 209 //! interface, a wp_tablet_tool.done event is sent to terminate that initial 210 //! sequence. 211 //! 212 //! Any event from a tool happens on the wp_tablet_tool interface. When the 213 //! tool gets into proximity of the tablet, a proximity_in event is sent on 214 //! the wp_tablet_tool interface, listing the tablet and the surface. That 215 //! event is followed by a motion event with the coordinates. After that, 216 //! it's the usual motion, axis, button, etc. events. The protocol's 217 //! serialisation means events are grouped by wp_tablet_tool.frame events. 218 //! 219 //! Two special events (that don't exist in X) are down and up. They signal 220 //! "tip touching the surface". For tablets without real proximity 221 //! detection, the sequence is: proximity_in, motion, down, frame. 222 //! 223 //! When the tool leaves proximity, a proximity_out event is sent. If any 224 //! button is still down, a button release event is sent before this 225 //! proximity event. These button events are sent in the same frame as the 226 //! proximity event to signal to the client that the buttons were held when 227 //! the tool left proximity. 228 //! 229 //! If the tool moves out of the surface but stays in proximity (i.e. 230 //! between windows), compositor-specific grab policies apply. This usually 231 //! means that the proximity-out is delayed until all buttons are released. 232 //! 233 //! Moving a tool physically from one tablet to the other has no real effect 234 //! on the protocol, since we already have the tool object from the "tool 235 //! added" event. All the information is already there and the proximity 236 //! events on both tablets are all a client needs to reconstruct what 237 //! happened. 238 //! 239 //! Some extra axes are normalized, i.e. the client knows the range as 240 //! specified in the protocol (e.g. [0, 65535]), the granularity however is 241 //! unknown. The current normalized axes are pressure, distance, and slider. 242 //! 243 //! Other extra axes are in physical units as specified in the protocol. 244 //! The current extra axes with physical units are tilt, rotation and 245 //! wheel rotation. 246 //! 247 //! Since tablets work independently of the pointer controlled by the mouse, 248 //! the focus handling is independent too and controlled by proximity. 249 //! The wp_tablet_tool.set_cursor request sets a tool-specific cursor. 250 //! This cursor surface may be the same as the mouse cursor, and it may be 251 //! the same across tools but it is possible to be more fine-grained. For 252 //! example, a client may set different cursors for the pen and eraser. 253 //! 254 //! Tools are generally independent of tablets and it is 255 //! compositor-specific policy when a tool can be removed. Common approaches 256 //! will likely include some form of removing a tool when all tablets the 257 //! tool was used on are removed. 258 259 /// Unstable version 1 260 pub mod v1 { 261 wayland_protocol!( 262 "./protocols/unstable/tablet/tablet-unstable-v1.xml", 263 [] 264 ); 265 } 266 267 /// Unstable version 2 268 pub mod v2 { 269 wayland_protocol!( 270 "./protocols/unstable/tablet/tablet-unstable-v2.xml", 271 [] 272 ); 273 } 274 } 275 276 pub mod text_input { 277 //! Text input protocol 278 279 /// Unstable version 1 280 pub mod v1 { 281 wayland_protocol!( 282 "./protocols/unstable/text-input/text-input-unstable-v1.xml", 283 [] 284 ); 285 } 286 287 /// Unstable version 3 288 pub mod v3 { 289 wayland_protocol!( 290 "./protocols/unstable/text-input/text-input-unstable-v3.xml", 291 [] 292 ); 293 } 294 } 295 296 pub mod xdg_decoration { 297 //! This interface allows a compositor to announce support for server-side 298 //! decorations. 299 300 //! A window decoration is a set of window controls as deemed appropriate by 301 //! the party managing them, such as user interface components used to move, 302 //! resize and change a window's state. 303 304 //! A client can use this protocol to request being decorated by a supporting 305 //! compositor. 306 307 //! If compositor and client do not negotiate the use of a server-side 308 //! decoration using this protocol, clients continue to self-decorate as they 309 //! see fit. 310 311 /// Unstable version 1 312 pub mod v1 { 313 wayland_protocol!( 314 "./protocols/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml", 315 [crate::xdg_shell] 316 ); 317 } 318 } 319 320 pub mod xdg_foreign { 321 //! Protocol for exporting xdg surface handles 322 //! 323 //! This protocol specifies a way for making it possible to reference a surface 324 //! of a different client. With such a reference, a client can, by using the 325 //! interfaces provided by this protocol, manipulate the relationship between 326 //! its own surfaces and the surface of some other client. For example, stack 327 //! some of its own surface above the other clients surface. 328 //! 329 //! In order for a client A to get a reference of a surface of client B, client 330 //! B must first export its surface using xdg_exporter.export. Upon doing this, 331 //! client B will receive a handle (a unique string) that it may share with 332 //! client A in some way (for example D-Bus). After client A has received the 333 //! handle from client B, it may use xdg_importer.import to create a reference 334 //! to the surface client B just exported. See the corresponding requests for 335 //! details. 336 //! 337 //! A possible use case for this is out-of-process dialogs. For example when a 338 //! sandboxed client without file system access needs the user to select a file 339 //! on the file system, given sandbox environment support, it can export its 340 //! surface, passing the exported surface handle to an unsandboxed process that 341 //! can show a file browser dialog and stack it above the sandboxed client's 342 //! surface. 343 344 /// Unstable version 1 345 pub mod v1 { 346 wayland_protocol!( 347 "./protocols/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml", 348 [] 349 ); 350 } 351 352 /// Unstable version 2 353 pub mod v2 { 354 wayland_protocol!( 355 "./protocols/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml", 356 [] 357 ); 358 } 359 } 360 361 pub mod xdg_output { 362 //! Protocol to describe output regions 363 //! 364 //! This protocol aims at describing outputs in a way which is more in line 365 //! with the concept of an output on desktop oriented systems. 366 //! 367 //! Some information are more specific to the concept of an output for 368 //! a desktop oriented system and may not make sense in other applications, 369 //! such as IVI systems for example. 370 //! 371 //! Typically, the global compositor space on a desktop system is made of 372 //! a contiguous or overlapping set of rectangular regions. 373 //! 374 //! Some of the information provided in this protocol might be identical 375 //! to their counterparts already available from wl_output, in which case 376 //! the information provided by this protocol should be preferred to their 377 //! equivalent in wl_output. The goal is to move the desktop specific 378 //! concepts (such as output location within the global compositor space, 379 //! the connector name and types, etc.) out of the core wl_output protocol. 380 381 /// Unstable version 1 382 pub mod v1 { 383 wayland_protocol!( 384 "./protocols/unstable/xdg-output/xdg-output-unstable-v1.xml", 385 [] 386 ); 387 } 388 } 389 390 pub mod xdg_shell { 391 //! XDG Shell protocol 392 //! 393 //! These are the old, unstable versions of the now stable XDG Shell protocol. 394 //! 395 //! They remain here for compatibility reasons, allowing you to support older 396 //! clients/server not yet implementing the new protocol. 397 398 /// Unstable version 5 399 pub mod v5 { 400 wayland_protocol!( 401 "./protocols/unstable/xdg-shell/xdg-shell-unstable-v5.xml", 402 [] 403 ); 404 } 405 406 /// Unstable version 6 407 pub mod v6 { 408 wayland_protocol!( 409 "./protocols/unstable/xdg-shell/xdg-shell-unstable-v6.xml", 410 [] 411 ); 412 } 413 } 414 415 pub mod xwayland_keyboard_grab { 416 //! Protocol for grabbing the keyboard from Xwayland 417 //! 418 //! This protocol is application-specific to meet the needs of the X11 419 //! protocol through Xwayland. It provides a way for Xwayland to request 420 //! all keyboard events to be forwarded to a surface even when the 421 //! surface does not have keyboard focus. 422 //! 423 //! In the X11 protocol, a client may request an "active grab" on the 424 //! keyboard. On success, all key events are reported only to the 425 //! grabbing X11 client. For details, see XGrabKeyboard(3). 426 //! 427 //! The core Wayland protocol does not have a notion of an active 428 //! keyboard grab. When running in Xwayland, X11 applications may 429 //! acquire an active grab inside Xwayland but that cannot be translated 430 //! to the Wayland compositor who may set the input focus to some other 431 //! surface. In doing so, it breaks the X11 client assumption that all 432 //! key events are reported to the grabbing client. 433 //! 434 //! This protocol specifies a way for Xwayland to request all keyboard 435 //! be directed to the given surface. The protocol does not guarantee 436 //! that the compositor will honor this request and it does not 437 //! prescribe user interfaces on how to handle the respond. For example, 438 //! a compositor may inform the user that all key events are now 439 //! forwarded to the given client surface, or it may ask the user for 440 //! permission to do so. 441 //! 442 //! Compositors are required to restrict access to this application 443 //! specific protocol to Xwayland alone. 444 445 /// Unstable version 1 446 pub mod v1 { 447 wayland_protocol!( 448 "./protocols/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml", 449 [] 450 ); 451 } 452 } 453