Put smithay's docs through a spell checker.

I noticed quite a few spelling errors, so I fixed a whole bunch of them.

src/backend/allocator/dmabuf.rs

@@ -5,7 +5,7 @@
 //! underlying resources are freed.
 //!
 //! If you want to hold on to a potentially alive dmabuf without blocking the free up
-//! of the underlying resouces, you may `downgrade` a `Dmabuf` reference to a `WeakDmabuf`.
+//! of the underlying resources, you may `downgrade` a `Dmabuf` reference to a `WeakDmabuf`.
 //!
 //! This can be especially useful in resources where other parts of the stack should decide upon
 //! the lifetime of the buffer. E.g. when you are only caching associated resources for a dmabuf.
@@ -125,9 +125,9 @@ pub struct DmabufBuilder {
 }
 
 impl DmabufBuilder {
-    /// Add a plane to the construted Dmabuf
+    /// Add a plane to the constructed Dmabuf
     ///
-    /// *Note*: Each Dmabuf needs atleast one plane.
+    /// *Note*: Each Dmabuf needs at least one plane.
     /// MAX_PLANES notes the maximum amount of planes any format may use with this implementation.
     pub fn add_plane(&mut self, fd: RawFd, idx: u32, offset: u32, stride: u32, modifier: Modifier) -> bool {
         if self.internal.planes.len() == MAX_PLANES {
@@ -158,7 +158,7 @@ impl DmabufBuilder {
 }
 
 impl Dmabuf {
-    /// Create a new Dmabuf by intializing with values from an existing buffer
+    /// Create a new Dmabuf by initializing with values from an existing buffer
     ///
     // Note: the `src` Buffer is only used a reference for size and format.
     // The contents are determined by the provided file descriptors, which

src/backend/allocator/swapchain.rs

@@ -146,7 +146,7 @@ where
 
     /// Change the dimensions of newly returned buffers.
     ///
-    /// Already optained buffers are unaffected and will be cleaned up on drop.
+    /// Already obtained buffers are unaffected and will be cleaned up on drop.
     pub fn resize(&mut self, width: u32, height: u32) {
         if self.width == width && self.height == height {
             return;

src/backend/drm/device/mod.rs

@@ -212,7 +212,7 @@ impl<A: AsRawFd + 'static> DrmDevice<A> {
     ///
     /// - [`crtcs`](drm::control::crtc) represent scanout engines of the device pointing to one framebuffer. \
     ///     Their responsibility is to read the data of the framebuffer and export it into an "Encoder". \
-    ///     The number of crtc's represent the number of independant output devices the hardware may handle.
+    ///     The number of crtc's represent the number of independent output devices the hardware may handle.
     /// - [`mode`](drm::control::Mode) describes the resolution and rate of images produced by the crtc and \
     ///     has to be compatible with the provided `connectors`.
     /// - [`connectors`](drm::control::connector) - List of connectors driven by the crtc. At least one(!) connector needs to be \
@@ -304,9 +304,9 @@ impl<A: AsRawFd> DevPath for A {
 /// Events that can be generated by a DrmDevice
 #[derive(Debug)]
 pub enum DrmEvent {
-    /// A vblank blank event on the provided crtc has happend
+    /// A vblank blank event on the provided crtc has happened
     VBlank(crtc::Handle),
-    /// An error happend while processing events
+    /// An error happened while processing events
     Error(Error),
 }
 

src/backend/drm/mod.rs

@@ -60,7 +60,7 @@
 //! It just provides a way to create framebuffers from various buffer types (mainly `DumbBuffer`s and hardware-backed gbm `BufferObject`s).
 //!
 //! Buffer management and details about the various types can be found in the [`allocator`-Module](crate::backend::allocator) and
-//! renderering abstractions, which can target these buffers can be found in the [`renderer`-Module](crate::backend::renderer).
+//! rendering abstractions, which can target these buffers can be found in the [`renderer`-Module](crate::backend::renderer).
 
 pub(crate) mod device;
 pub(self) mod error;

src/backend/drm/surface/gbm.rs

@@ -40,7 +40,7 @@ where
     /// Create a new `GbmBufferedSurface` from a given compatible combination
     /// of a surface, an allocator and renderer formats.
     ///
-    /// To sucessfully call this function, you need to have a renderer,
+    /// To successfully call this function, you need to have a renderer,
     /// which can render into a Dmabuf, and a gbm allocator that can produce
     /// buffers of a supported format for rendering.
     #[allow(clippy::type_complexity)]

src/backend/egl/context.rs

@@ -292,7 +292,7 @@ pub struct PixelFormatRequirements {
     pub color_bits: Option<u8>,
     /// If `true`, the color buffer must be in a floating point format. Default is `false`.
     ///
-    /// Using floating points allows you to write values outside of the `[0.0, 1.0]` range.
+    /// Using floating points allows you to write values outside the `[0.0, 1.0]` range.
     pub float_color_buffer: bool,
     /// Minimum number of bits for the alpha in the color buffer. `None` means "don't care". The default is `None`.
     pub alpha_bits: Option<u8>,

src/backend/egl/mod.rs

@@ -7,7 +7,7 @@
 //! - Import/Export external resources to/from OpenGL
 //!
 //! To use this module, you first need to create a [`EGLDisplay`] through a supported EGL platform
-//! as inidicated by an implementation of the `native::EGLNativeDisplay` trait.
+//! as indicated by an implementation of the `native::EGLNativeDisplay` trait.
 //!
 //! You may bind the [`EGLDisplay`], that shall be used by clients for rendering (so pick one initialized by a fast platform)
 //! to the [`wayland_server::Display`] of your compositor. Note only one backend may be bound to any [`Display`](wayland_server::Display) at any time.
@@ -20,7 +20,7 @@
 //! it may also be used to initialize an [`EGLSurface`], which can be [bound](crate::backend::renderer::Bind) to some renderers.
 //!
 //! Alternatively you may import [`dmabuf`](crate::backend::allocator::dmabuf)s using the display, which result
-//! in an [`EGLImage`], which can be rendered into by OpenGL. This is perferrable to using surfaces as the dmabuf can be
+//! in an [`EGLImage`], which can be rendered into by OpenGL. This is preferable to using surfaces as the dmabuf can be
 //! passed around freely making resource-management and more complex use-cases like Multi-GPU rendering easier to manage.
 //! Renderers based on EGL may support doing this for you by allowing you to [`Bind`](crate::backend::renderer::Bind) a dmabuf directly.
 //!

src/backend/egl/native.rs

@@ -79,7 +79,7 @@ impl<'a> EGLPlatform<'a> {
     ///
     /// * `platform` - The platform defined in `ffi::egl::`
     /// * `platform_name` - A human readable representation of the platform
-    /// * `native_display` - The native display raw pointer which can be casted to `*mut c_void`
+    /// * `native_display` - The native display raw pointer which can be cast to `*mut c_void`
     /// * `attrib_list` - A list of `ffi::EGLint` like defined in the EGL Extension
     /// * `required_extensions` - The names of the required EGL Extensions for this platform
     ///
@@ -185,7 +185,7 @@ pub unsafe trait EGLNativeSurface: Send + Sync {
 
     /// Will be called to check if any internal resources will need
     /// to be recreated. Old resources must be used until `create`
-    /// was called again and a new surface was optained.
+    /// was called again and a new surface was obtained.
     ///
     /// Only needs to be recreated, if this may return true.
     /// The default implementation always returns false.

src/backend/input/mod.rs

@@ -455,7 +455,7 @@ impl<B: InputBackend> TouchUpEvent<B> for UnusedEvent {
     }
 }
 
-/// Trait for touch events cancelling the chain
+/// Trait for touch events canceling the chain
 pub trait TouchCancelEvent<B: InputBackend>: Event<B> {
     /// [`TouchSlot`], if the device has multi-touch capabilities
     fn slot(&self) -> Option<TouchSlot>;
@@ -497,7 +497,7 @@ pub trait InputBackend: Sized {
     type TouchUpEvent: TouchUpEvent<Self>;
     /// Type representing touch events from moving
     type TouchMotionEvent: TouchMotionEvent<Self>;
-    /// Type representing cancelling of touch events
+    /// Type representing canceling of touch events
     type TouchCancelEvent: TouchCancelEvent<Self>;
     /// Type representing touch frame events
     type TouchFrameEvent: TouchFrameEvent<Self>;
@@ -532,17 +532,17 @@ pub enum InputEvent<B: InputBackend> {
         /// The removed device
         device: B::Device,
     },
-    /// A keyboard event occured
+    /// A keyboard event occurred
     Keyboard {
         /// The keyboard event
         event: B::KeyboardKeyEvent,
     },
-    /// A relative pointer motion occured
+    /// A relative pointer motion occurred
     PointerMotion {
         /// The pointer motion event
         event: B::PointerMotionEvent,
     },
-    /// An absolute pointer motion occures
+    /// An absolute pointer motion occurs
     PointerMotionAbsolute {
         /// The absolute pointer motion event
         event: B::PointerMotionAbsoluteEvent,
@@ -552,7 +552,7 @@ pub enum InputEvent<B: InputBackend> {
         /// The pointer button event
         event: B::PointerButtonEvent,
     },
-    /// A pointer axis was actionned
+    /// A pointer action occurred while scrolling on an axis
     PointerAxis {
         /// The pointer axis event
         event: B::PointerAxisEvent,
@@ -577,7 +577,7 @@ pub enum InputEvent<B: InputBackend> {
         /// The touch cancel event
         event: B::TouchCancelEvent,
     },
-    /// A touch frame was emmited
+    /// A touch frame was emitted
     ///
     /// A set of two events received on the same seat between two frames should
     /// be interpreted as an atomic event.
@@ -586,19 +586,19 @@ pub enum InputEvent<B: InputBackend> {
         event: B::TouchFrameEvent,
     },
 
-    /// A tablet tool axis was emited
+    /// A tablet tool axis was emitted
     TabletToolAxis {
         /// The tablet tool axis event
         event: B::TabletToolAxisEvent,
     },
 
-    /// A tablet tool proximity was emited
+    /// A tablet tool proximity was emitted
     TabletToolProximity {
         /// The tablet tool proximity  event
         event: B::TabletToolProximityEvent,
     },
 
-    /// A tablet tool tip event was emited
+    /// A tablet tool tip event was emitted
     TabletToolTip {
         /// The tablet tool axis event
         event: B::TabletToolTipEvent,

src/backend/input/tablet.rs

@@ -16,7 +16,7 @@ pub struct TabletToolDescriptor {
     pub capabilitys: TabletToolCapabilitys,
 }
 
-/// Describes the physical type of a tool. The physical type of a tool generally defines its base usage.
+/// Describes the physical type of tool. The physical type of tool generally defines its base usage.
 #[derive(Debug, Clone, Copy, Hash, Eq, PartialEq)]
 pub enum TabletToolType {
     /// A generic pen.

src/backend/mod.rs

@@ -9,9 +9,9 @@
 //!
 //! ### Session management
 //!
-//! Session management relates to mechanisms allowing the compositor to access the ressources
+//! Session management relates to mechanisms allowing the compositor to access the resources
 //! it needs to function. It contains interaction with the login manager if any ((e)logind or
-//! seatd), as well as releasing thoses ressources when TTY-switching. It is handled by the
+//! seatd), as well as releasing those resources when TTY-switching. It is handled by the
 //! [`session`] module, gated by the `backend_session` cargo feature. You will generally need
 //! it to run your compositor directly on a TTY.
 //!

src/backend/renderer/mod.rs

@@ -163,7 +163,7 @@ pub trait Frame {
     /// If called outside this operation may error-out, do nothing or modify future rendering results in any way.
     fn clear(&mut self, color: [f32; 4]) -> Result<(), Self::Error>;
     /// Render a texture to the current target using given projection matrix and alpha.
-    /// The given verticies are used to source the texture. This is mostly useful for cropping the texture.
+    /// The given vertices are used to source the texture. This is mostly useful for cropping the texture.
     fn render_texture(
         &mut self,
         texture: &Self::TextureId,
@@ -257,7 +257,7 @@ pub trait Renderer {
     /// Initialize a rendering context on the current rendering target with given dimensions and transformation.
     ///
     /// This function *may* error, if:
-    /// - The given dimensions are unsuppored (too large) for this renderer
+    /// - The given dimensions are unsupported (too large) for this renderer
     /// - The given Transformation is not supported by the renderer (`Transform::Normal` is always supported).
     /// - This renderer implements `Bind`, no target was bound *and* has no default target.
     /// - (Renderers not implementing `Bind` always have a default target.)

src/backend/session/auto.rs

@@ -13,7 +13,7 @@
 //!
 //! The session may be used to open devices manually through the [`Session`] interface
 //! or be passed to other objects that need it to open devices themselves.
-//! The [`AutoSession`] is clonable
+//! The [`AutoSession`] is cloneable
 //! and may be passed to multiple devices easily.
 //!
 //! Examples for those are e.g. the [`LibinputInputBackend`](crate::backend::libinput::LibinputInputBackend)

src/backend/session/mod.rs

@@ -14,7 +14,7 @@
 //! Session handling in Smithay is done through a pair of types that each session provider implements.
 //!
 //! The first is a handle implementing the [`Session`] trait, which allows you to request the opening
-//! of devices, a VT change, or informations about the session state.
+//! of devices, a VT change, or information about the session state.
 //!
 //! The second is a notifier which informs you when the session is enabled or disabled by the system.
 //! This notifier takes the form of a [`calloop`] event source, but it does not generates any event

src/backend/winit.rs

@@ -644,7 +644,7 @@ impl InputBackend for WinitInputBackend {
     /// Processes new events of the underlying event loop and calls the provided callback.
     ///
     /// You need to periodically call this function to keep the underlying event loop and
-    /// [`WinitWindow`] active. Otherwise the window may no respond to user interaction.
+    /// [`WinitWindow`] active. Otherwise the window may not respond to user interaction.
     ///
     /// Returns an error if the [`WinitWindow`] the window has been closed. Calling
     /// `dispatch_new_events` again after the [`WinitWindow`] has been closed is considered an

src/lib.rs

@@ -31,7 +31,7 @@
 //! as `Rc` and `Arc` and the synchronization they require, [`calloop`] allows you to provide a mutable
 //! reference to a value, that will be passed down to most callbacks (possibly under the form of a
 //! [`DispatchData`](::wayland_server::DispatchData) for wayland-related callbacks). This structure provides
-//! an easy access to a centralized mutable state without synchronization (as the callback invocation is
+//! easy access to a centralized mutable state without synchronization (as the callback invocation is
 //! *always* sequential), and is the recommended way to of structuring your compositor.
 //!
 //! Several objects, in particular on the wayland clients side, can exist as multiple instances where each

src/utils/signaling.rs

@@ -2,8 +2,8 @@
 //!
 //! This mechanism allows inter-module communication, by letting your modules
 //! register callbacks to listen for events generated by other modules. This
-//! signaling mechanism is synchronous and non-threadsafe. If you need
-//! ascynchronous threadsafe communication, instead consider relying on channels.
+//! signaling mechanism is synchronous and non-thread safe. If you need
+//! asynchronous thread safe communication, instead consider relying on channels.
 //!
 //! The whole mechanism is built on the [`Signaler`] type.
 //! It serves both as a message sending facility and a way to register new callbacks

src/wayland/compositor/cache.rs

@@ -32,7 +32,7 @@ use downcast_rs::{impl_downcast, Downcast};
 
 use crate::wayland::Serial;
 
-/// Trait represening a value that can be used in double-buffered storage
+/// Trait representing a value that can be used in double-buffered storage
 ///
 /// The type needs to implement the [`Default`] trait, which will be used
 /// to initialize. You further need to provide two methods:
@@ -46,14 +46,14 @@ use crate::wayland::Serial;
 /// current state.
 ///
 /// In most cases, this method will simply produce a copy of the pending state,
-/// but you might need additionnal logic in some cases, such as for handling
+/// but you might need additional logic in some cases, such as for handling
 /// non-cloneable resources (which thus need to be moved into the produce value).
 ///
 /// Then at some point the [`Cacheable::merge_into`] method of your type will be
 /// invoked. In this method, `self` acts as the update that should be merged into
 /// the current state provided as argument. In simple cases, the action would just
-/// be to copy `self` into the current state, but mre complex cases require
-/// additionnal logic.
+/// be to copy `self` into the current state, but more complex cases require
+/// additional logic.
 pub trait Cacheable: Default {
     /// Produce a new state to be cached from the pending state
     fn commit(&mut self) -> Self;
@@ -117,7 +117,7 @@ impl<T: Cacheable + 'static> Cache for RefCell<CachedState<T>> {
 /// A typemap-like container for double-buffered values
 ///
 /// All values inserted into this container must implement the [`Cacheable`] trait,
-/// which defines their buffering semantics. They futhermore must be `Send` as the surface state
+/// which defines their buffering semantics. They furthermore must be `Send` as the surface state
 /// can be accessed from multiple threads (but `Sync` is not required, the surface internally synchronizes
 /// access to its state).
 ///
@@ -130,7 +130,7 @@ impl<T: Cacheable + 'static> Cache for RefCell<CachedState<T>> {
 /// stored.
 ///
 /// This contained has [`RefCell`]-like semantics: values of multiple stored types can be accessed at the
-/// same time. The stored values are initialized lazyly the first time `current()` or `pending()` are
+/// same time. The stored values are initialized lazily the first time `current()` or `pending()` are
 /// invoked with this type as argument.
 pub struct MultiCache {
     caches: appendlist::AppendList<Box<dyn Cache + Send>>,
@@ -164,7 +164,7 @@ impl MultiCache {
             .unwrap()
     }
 
-    /// Acces the pending state associated with type `T`
+    /// Access the pending state associated with type `T`
     pub fn pending<T: Cacheable + Send + 'static>(&self) -> RefMut<'_, T> {
         RefMut::map(self.find_or_insert::<T>().borrow_mut(), |cs| &mut cs.pending)
     }

src/wayland/compositor/mod.rs

@@ -8,7 +8,7 @@
 //! ## Why use this implementation
 //!
 //! This implementation does a simple job: it stores in a coherent way the state of
-//! surface trees with subsurfaces, to provide you a direct access to the tree
+//! surface trees with subsurfaces, to provide you direct access to the tree
 //! structure and all surface attributes, and handles the application of double-buffered
 //! state.
 //!
@@ -17,7 +17,7 @@
 //! need to display the subsurface tree.
 //!
 //! This implementation will not do anything more than present you the metadata specified by the
-//! client in a coherent and practical way. All the logic regarding to drawing itself, and
+//! client in a coherent and practical way. All the logic regarding drawing itself, and
 //! the positioning of windows (surface trees) one relative to another is out of its scope.
 //!
 //! ## How to use it

src/wayland/compositor/transaction.rs

@@ -185,7 +185,7 @@ pub(crate) struct Transaction {
 }
 
 impl Transaction {
-    /// Computes the global state of the transaction wrt its blockers
+    /// Computes the global state of the transaction with regard to its blockers
     ///
     /// The logic is:
     ///

src/wayland/compositor/tree.rs

@@ -52,7 +52,7 @@ pub enum Location {
     After,
 }
 
-/// Possible actions to do after handling a node diring tree traversal
+/// Possible actions to do after handling a node during tree traversal
 #[derive(Debug)]
 pub enum TraversalAction<T> {
     /// Traverse its children as well, providing them the data T

src/wayland/data_device/mod.rs

@@ -15,7 +15,7 @@
 //! Using these two functions is enough for your clients to be able to interact with each other using
 //! the data devices.
 //!
-//! The module also provides additionnal mechanisms allowing your compositor to see and interact with
+//! The module also provides additional mechanisms allowing your compositor to see and interact with
 //! the contents of the data device:
 //!
 //! - You can provide a callback closure to [`init_data_device`]
@@ -83,7 +83,7 @@ pub enum DataDeviceEvent {
         /// The data source provided by the client
         ///
         /// If it is `None`, this means the DnD is restricted to surfaces of the
-        /// same client and the client will manage data transfert by itself.
+        /// same client and the client will manage data transfer by itself.
         source: Option<wl_data_source::WlDataSource>,
         /// The icon the client requested to be used to be associated with the cursor icon
         /// during the drag'n'drop.
@@ -93,7 +93,7 @@ pub enum DataDeviceEvent {
     ///
     /// At this point, any pointer icon should be removed.
     ///
-    /// Note that this event will only be genrated for client-initiated drag'n'drop session.
+    /// Note that this event will only be generated for client-initiated drag'n'drop session.
     DnDDropped,
     /// A client requested to read the server-set selection
     SendSelection {
@@ -327,7 +327,7 @@ pub fn set_data_device_selection(seat: &Seat, mime_types: Vec<String>) {
         }));
 }
 
-/// Start a drag'n'drop from a ressource controlled by the compositor
+/// Start a drag'n'drop from a resource controlled by the compositor
 ///
 /// You'll receive events generated by the interaction of clients with your
 /// drag'n'drop in the provided callback. See [`ServerDndEvent`] for details about

src/wayland/data_device/server_dnd_grab.rs

@@ -22,7 +22,7 @@ pub enum ServerDndEvent {
     Action(DndAction),
     /// The DnD resource was dropped by the user
     ///
-    /// After that, the client can still interract with your ressource
+    /// After that, the client can still interact with your resource
     Dropped,
     /// The Dnd was cancelled
     ///

src/wayland/explicit_synchronization/mod.rs

@@ -82,11 +82,11 @@ impl ExplicitBufferRelease {
 /// An explicit synchronization state
 ///
 /// The client is not required to fill both. `acquire` being `None` means that you don't need to wait
-/// before acessing the buffer, `release` being `None` means that the client does not require additionnal
+/// before accessing the buffer, `release` being `None` means that the client does not require additional
 /// signaling that you are finished (you still need to send `wl_buffer.release`).
 ///
-/// When processing the current state, the whould [`Option::take`] the values from it. Otherwise they'll
-/// be treated as unused and released when overwritten by the next client commit.
+/// When processing the current state, [`Option::take`] the values from it. Otherwise they'll be
+/// treated as unused and released when overwritten by the next client commit.
 #[derive(Debug)]
 pub struct ExplicitSyncState {
     /// An acquire `dma_fence` object, that you should wait on before accessing the contents of the

src/wayland/mod.rs

@@ -16,7 +16,7 @@
 //!
 //! Some of these modules require you to provide a callback that is invoked for some
 //! client requests that your logic needs to handle. In most cases these callback
-//! are given as input an enum specifying the event that occured, as well as the
+//! are given as input an enum specifying the event that occurred, as well as the
 //! [`DispatchData`](wayland_server::DispatchData) from `wayland_server`.
 //!
 //! ## Provided helpers
@@ -28,7 +28,7 @@
 //! Following this, the [`shell`] module contains the logic allowing clients to use their
 //! surface to build concrete windows with the usual interactions. Different kind of shells
 //! exist, but in general you will want to support at least the [`xdg`](shell::xdg) variant,
-//! which is the standart used by most applications.
+//! which is the standard used by most applications.
 //!
 //! Then, the [`seat`] module contains logic related to input handling. These helpers are used
 //! to forward input (such as pointer action or keystrokes) to clients, and manage the input
@@ -38,7 +38,7 @@
 //! The [`shm`] module provides the necessary logic for client to provide buffers defining the
 //! contents of their windows using shared memory. This is the main mechanism used by clients
 //! that are not hardware accelerated. As a complement, the [`dmabuf`] module provides support
-//! hardware-accelerated clients; it is tighly linked to the
+//! hardware-accelerated clients; it is tightly linked to the
 //! [`backend::allocator`](crate::backend::allocator) module.
 //!
 //! The [`output`] module helps forwarding to clients information about the display monitors that

src/wayland/output/xdg.rs

@@ -1,6 +1,6 @@
 //! XDG Output advertising capabilities
 //!
-//! This protocol is ment for describing outputs in a way
+//! This protocol is meant for describing outputs in a way
 //! which is more in line with the concept of an output on desktop oriented systems.
 
 use std::{

src/wayland/seat/mod.rs

@@ -162,7 +162,7 @@ impl Seat {
             .map(|arc| Seat { arc })
     }
 
-    /// Acces the `UserDataMap` associated with this `Seat`
+    /// Access the `UserDataMap` associated with this `Seat`
     pub fn user_data(&self) -> &UserDataMap {
         &self.arc.user_data
     }

src/wayland/seat/pointer.rs

@@ -161,7 +161,7 @@ impl PointerHandle {
         self.inner.borrow_mut().grab = GrabStatus::Active(serial, Box::new(grab));
     }
 
-    /// Remove any current grab on this pointer, reseting it to the default behavior
+    /// Remove any current grab on this pointer, resetting it to the default behavior
     pub fn unset_grab(&self) {
         self.inner.borrow_mut().grab = GrabStatus::None;
     }

src/wayland/shell/legacy/mod.rs

@@ -4,7 +4,7 @@
 //! as a global handler for `wl_shell`. This protocol is deprecated in favor of `xdg_shell`,
 //! thus this module is provided as a compatibility layer with older clients. As a consequence,
 //! you can as a compositor-writer decide to only support its functionality in a best-effort
-//! maneer: as this global is part of the core protocol, you are still required to provide
+//! manner: as this global is part of the core protocol, you are still required to provide
 //! some support for it.
 //!
 //! ## Why use this implementation
@@ -159,7 +159,7 @@ pub enum ShellSurfaceKind {
         parent: wl_surface::WlSurface,
         /// Location relative to the parent
         location: Point<i32, Logical>,
-        /// Wether this window should be marked as inactive
+        /// Weather this window should be marked as inactive
         inactive: bool,
     },
     /// Fullscreen surface, covering an entire output
@@ -181,7 +181,7 @@ pub enum ShellSurfaceKind {
         /// The serial of the input event triggering the creation of this
         /// popup
         serial: Serial,
-        /// Wether this popup should be marked as inactive
+        /// Weather this popup should be marked as inactive
         inactive: bool,
         /// Location of the popup relative to its parent
         location: Point<i32, Logical>,

src/wayland/shell/xdg/mod.rs

@@ -183,11 +183,11 @@ xdg_role!(
     ///
     /// Unmapping an xdg_toplevel means that the surface cannot be shown
     /// by the compositor until it is explicitly mapped again.
-    /// All active operations (e.g., move, resize) are canceled and all
+    /// All active operations (e.g., move, resize) are cancelled and all
     /// attributes (e.g. title, state, stacking, ...) are discarded for
     /// an xdg_toplevel surface when it is unmapped. The xdg_toplevel returns to
     /// the state it had right after xdg_surface.get_toplevel. The client
-    /// can re-map the toplevel by perfoming a commit without any buffer
+    /// can re-map the toplevel by performing a commit without any buffer
     /// attached, waiting for a configure event and handling it as usual (see
     /// xdg_surface description).
     ///

src/wayland/tablet_manager/mod.rs

@@ -46,9 +46,9 @@ pub use tablet::{TabletDescriptor, TabletHandle};
 pub use tablet_seat::TabletSeatHandle;
 pub use tablet_tool::TabletToolHandle;
 
-/// Extends [Seat] with graphic tablet specyfic functionality
+/// Extends [Seat] with graphic tablet specific functionality
 pub trait TabletSeatTrait {
-    /// Get tablet seat asosiated with this seat
+    /// Get tablet seat associated with this seat
     fn tablet_seat(&self) -> TabletSeatHandle;
 }
 

src/wayland/tablet_manager/tablet_seat.rs

@@ -41,7 +41,7 @@ impl fmt::Debug for TabletSeat {
 
 /// Handle to a tablet seat
 ///
-/// TabletSeat extends `Seat` with graphic tablet specyfic functionality
+/// TabletSeat extends `Seat` with graphic tablet specific functionality
 ///
 /// TabletSeatHandle can be used to advertise available graphics tablets and tools to wayland clients
 #[derive(Default, Debug, Clone)]
@@ -92,7 +92,7 @@ impl TabletSeatHandle {
     /// You can either add tablet on [input::Event::DeviceAdded](crate::backend::input::InputEvent::DeviceAdded) event,
     /// or you can add tablet based on tool event, then clients will not know about devices that are not being used
     ///
-    /// Returns new [TabletHandle] if tablet was not know by this seat, if tablet was allready know it returns exsisting handle.
+    /// Returns new [TabletHandle] if tablet was not know by this seat, if tablet was already know it returns existing handle.
     pub fn add_tablet(&self, tablet_desc: &TabletDescriptor) -> TabletHandle {
         let inner = &mut *self.inner.borrow_mut();
 
@@ -123,7 +123,7 @@ impl TabletSeatHandle {
 
     /// Remove tablet device
     ///
-    /// Called when tablet is no longer avalible
+    /// Called when tablet is no longer available
     /// For example on [input::Event::DeviceRemoved](crate::backend::input::InputEvent::DeviceRemoved) event.
     pub fn remove_tablet(&self, tablet_desc: &TabletDescriptor) {
         self.inner.borrow_mut().tablets.remove(tablet_desc);
@@ -138,7 +138,7 @@ impl TabletSeatHandle {
     ///
     /// Tool is usually added on [TabletToolProximityEvent](crate::backend::input::InputEvent::TabletToolProximity) event.
     ///
-    /// Returns new [TabletToolHandle] if tool was not know by this seat, if tool was allready know it returns exsisting handle,
+    /// Returns new [TabletToolHandle] if tool was not know by this seat, if tool was already know it returns existing handle,
     /// it allows you to send tool input events to clients.
     pub fn add_tool(&self, tool_desc: &TabletToolDescriptor) -> TabletToolHandle {
         let inner = &mut *self.inner.borrow_mut();
@@ -177,7 +177,7 @@ impl TabletSeatHandle {
     ///
     /// Policy of tool removal is a compositor-specific.
     ///
-    /// One posible policy would be to remove a tool when all tablets the tool was used on are removed.
+    /// One possible policy would be to remove a tool when all tablets the tool was used on are removed.
     pub fn remove_tool(&self, tool_desc: &TabletToolDescriptor) {
         self.inner.borrow_mut().tools.remove(tool_desc);
     }

src/wayland/tablet_manager/tablet_tool.rs

@@ -350,7 +350,7 @@ impl TabletToolHandle {
         }
     }
 
-    /// Notifify that this tool is focused on a certain surface.
+    /// Notify that this tool is focused on a certain surface.
     ///
     /// You provide the location of the tool, in the form of:
     ///
@@ -370,7 +370,7 @@ impl TabletToolHandle {
             .proximity_in(pos, focus, tablet, serial, time)
     }
 
-    /// Notifify that this tool has left proximity.
+    /// Notify that this tool has left proximity.
     pub fn proximity_out(&self, time: u32) {
         self.inner.borrow_mut().proximity_out(time);
     }

src/xwayland/x11_sockets.rs

@@ -111,7 +111,7 @@ impl Drop for X11Lock {
 
 /// Open the two unix sockets an X server listens on
 ///
-/// Should only be done after the associated lockfile is aquired!
+/// Should only be done after the associated lockfile is acquired!
 fn open_x11_sockets_for_display(display: u32) -> NixResult<[UnixStream; 2]> {
     let path = format!("/tmp/.X11-unix/X{}", display);
     let _ = ::std::fs::remove_file(&path);

src/xwayland/xserver.rs

@@ -76,7 +76,7 @@ pub struct XWayland<Data> {
 /// This is a very low-level interface, only notifying you when the connection
 /// with XWayland is up, or when it terminates.
 ///
-/// Your WM code must be able handle the XWayland server connecting then
+/// Your WM code must be able to handle the XWayland server connecting then
 /// disconnecting several time in a row, but only a single connection will
 /// be active at any given time.
 #[derive(Debug)]