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 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208
//! Server-side Wayland connector //! //! ## Overview //! //! This crate provides the interfaces and machinery to safely create servers //! for the Wayland protocol. It is a rust wrapper around the `libwayland-server.so` //! C library. //! //! The Wayland protocol revolves around the creation of various objects and the exchange //! of messages associated to these objects. Whenever a client connects, a `Display` object //! is automatically created in their object space, which they use as a root to create new //! objects and bootstrap their state. //! //! ## Protocol and messages handling model //! //! The protocol being bi-directional, you can send and receive messages. //! Sending messages is done via methods of Rust objects corresponding to the wayland protocol //! objects, receiving and handling them is done by providing implementations. //! //! ### Resources //! //! The protocol and message model is very similar to the one of `wayland-client`, with the //! main difference being that the underlying handles to objects are represented by the `Resource<I>` //! type, very similarly to proxies in `wayland-client`. //! //! These resources are used to send messages to the client (in the Wayland context, //! these are called "events"). You usually don't use them directly, and instead call //! methods on the Rust objects themselves, which invoke the appropriate `Resource` methods. //! It is also possible to directly use the `Resource::<I>::send(..)` method. //! //! There is not a 1 to 1 mapping between Rust object instances and protocol //! objects. Rather, you can think of the Rust objects as `Rc`-like handles to a //! Wayland object. Multiple instances of a Rust object can exist referring to the same //! protocol object. //! //! Similarly, the lifetimes of the protocol objects and the Rust objects are //! not tightly tied. As protocol objects are created and destroyed by protocol //! messages, it can happen that an object gets destroyed while one or more //! Rust objects still refer to it. In such case, these Rust objects will be disabled //! and the `alive()` method on the underlying `Resource<I>` will start to return `false`. //! Events that are subsequently sent to them are ignored. //! //! ### Implementations //! //! To receive and process messages from the clients to you (in Wayland context they are //! called "requests"), you need to provide an `Implementation` for each Wayland object //! created in the protocol session. Whenever a new protocol object is created, you will //! receive a `NewResource<I>` object. Providing an implementation via its `implement()` method //! will turn it into a regular Rust object. //! //! **All objects must be implemented**, even if it is an implementation doing nothing. //! Failure to do so (by dropping the `NewResource<I>` for example) can cause future fatal //! protocol errors if the client tries to send a request to this object. //! //! An implementation is a struct implementing the `RequestHandler` trait for the interface //! of the considered object. Alternatively, an `FnMut(I::Request, I)` closure can be //! used with the `implement_closure()` method, where `I` is the interface //! of the considered object. //! //! A Rust object passed to your implementation is guaranteed to be alive (as it just received //! a request), unless the exact message received is a destructor (which is indicated in the API //! documentations). //! //! ## Event loops and general structure //! //! The core of your server is the `Display` object. It represent the ability of your program to //! process Wayland messages. Once this object is created, you can configure it to listen on one //! or more sockets for incoming client connections (see the `Display` docs for details). //! //! To properly function, this Wayland implementation also needs an event loop structure, //! which is here provided by the `calloop` crate. It is a public dependency and is reexported //! as `wayland_server::calloop`. #![warn(missing_docs)] #[macro_use] extern crate bitflags; pub extern crate calloop; #[cfg(not(feature = "native_lib"))] #[macro_use] extern crate downcast_rs as downcast; extern crate libc; extern crate mio; extern crate nix; extern crate wayland_commons; #[cfg_attr(feature = "native_lib", macro_use)] extern crate wayland_sys; mod client; mod display; mod globals; mod resource; pub use client::Client; pub use display::Display; pub use globals::Global; pub use resource::{HandledBy, NewResource, Resource}; pub use anonymous_object::AnonymousObject; pub use wayland_commons::utils::UserDataMap; pub use wayland_commons::{Interface, MessageGroup, NoMessage}; /// C-associated types /// /// Required for plugging wayland-scanner generated protocols /// or interfacing with C code using wayland objects. pub mod sys { pub use wayland_sys::{common, server}; } // rust implementation #[cfg(not(feature = "native_lib"))] #[path = "rust_imp/mod.rs"] mod imp; // C-lib based implementation #[cfg(feature = "native_lib")] #[path = "native_lib/mod.rs"] mod imp; pub use imp::ResourceMap; /// Generated interfaces for the core wayland protocol pub mod protocol { #![allow(dead_code, non_camel_case_types, unused_unsafe, unused_variables)] #![allow(non_upper_case_globals, non_snake_case, unused_imports)] #![allow(missing_docs)] #![cfg_attr(feature = "cargo-clippy", allow(clippy))] pub(crate) use wayland_commons::map::{Object, ObjectMetadata}; pub(crate) use wayland_commons::wire::{Argument, ArgumentType, Message, MessageDesc}; pub(crate) use wayland_commons::{Interface, MessageGroup}; pub(crate) use wayland_sys as sys; pub(crate) use {AnonymousObject, HandledBy, NewResource, Resource, ResourceMap}; include!(concat!(env!("OUT_DIR"), "/wayland_api.rs")); } mod anonymous_object { use super::{Interface, NoMessage, Resource}; /// Anonymous interface /// /// A special Interface implementation representing an /// handle to an object for which the interface is not known. #[derive(Clone, Eq, PartialEq)] pub struct AnonymousObject(Resource<AnonymousObject>); impl Interface for AnonymousObject { type Request = NoMessage; type Event = NoMessage; const NAME: &'static str = "<anonymous>"; const VERSION: u32 = 0; fn c_interface() -> *const ::wayland_sys::common::wl_interface { ::std::ptr::null() } } impl AsRef<Resource<AnonymousObject>> for AnonymousObject { #[inline] fn as_ref(&self) -> &Resource<Self> { &self.0 } } impl From<Resource<AnonymousObject>> for AnonymousObject { #[inline] fn from(resource: Resource<Self>) -> Self { AnonymousObject(resource) } } impl From<AnonymousObject> for Resource<AnonymousObject> { #[inline] fn from(value: AnonymousObject) -> Self { value.0 } } } /* * A raw Fd Evented struct */ pub(crate) struct Fd(pub ::std::os::unix::io::RawFd); impl ::mio::Evented for Fd { fn register( &self, poll: &::mio::Poll, token: ::mio::Token, interest: ::mio::Ready, opts: ::mio::PollOpt, ) -> ::std::io::Result<()> { ::mio::unix::EventedFd(&self.0).register(poll, token, interest, opts) } fn reregister( &self, poll: &::mio::Poll, token: ::mio::Token, interest: ::mio::Ready, opts: ::mio::PollOpt, ) -> ::std::io::Result<()> { ::mio::unix::EventedFd(&self.0).reregister(poll, token, interest, opts) } fn deregister(&self, poll: &::mio::Poll) -> ::std::io::Result<()> { ::mio::unix::EventedFd(&self.0).deregister(poll) } }