3 files changed, 20 insertions, 20 deletions
diff --git a/crates/wayland/src/udev/gpu.rs b/crates/wayland/src/udev/gpu.rs
index ad6526e..f230f92 100644
--- a/crates/wayland/src/udev/gpu.rs
+++ b/crates/wayland/src/udev/gpu.rs
@@ -144,12 +144,12 @@ const COLOR_FORMATS: [DrmFourcc; 2] = [DrmFourcc::Argb8888, DrmFourcc::Xrgb8888]
 /// here, matching the existing legacy path's own connector handling) is
 /// *not* an atomic-vs-legacy switch, despite that being an easy assumption
 /// - reading smithay's own source (`backend/drm/device/mod.rs`) directly
-/// showed `DrmDevice::create_internal` tries atomic capability first and
-/// falls back to a `Legacy` internal variant automatically if the driver
-/// doesn't support it, both exposed through the one `DrmDevice` type via
-/// its own `is_atomic()` query - logged here, not assumed, since Phase 1's
-/// probe never got far enough to find this out empirically on this
-/// specific machine's `i915` driver.
+///   showed `DrmDevice::create_internal` tries atomic capability first and
+///   falls back to a `Legacy` internal variant automatically if the driver
+///   doesn't support it, both exposed through the one `DrmDevice` type via
+///   its own `is_atomic()` query - logged here, not assumed, since Phase 1's
+///   probe never got far enough to find this out empirically on this
+///   specific machine's `i915` driver.
 ///
 /// Deliberately does **not** yet call `initialize_output` for any specific
 /// head, or touch `render_udev_frame` at all - this function's whole job
diff --git a/crates/wayland/src/udev/mod.rs b/crates/wayland/src/udev/mod.rs
index cae7177..61b7d29 100644
--- a/crates/wayland/src/udev/mod.rs
+++ b/crates/wayland/src/udev/mod.rs
@@ -190,14 +190,14 @@ pub(crate) struct UdevHead {
     /// exact same head still "ready" and every prior damage still pending,
     /// tried the exact same flip again, failed the exact same way, forever
     /// - a true busy loop with no backoff at all, not merely a missed
-    /// optimization. Confirmed live from a real session log: tens of
-    /// thousands of consecutive `page flip failed: Device or resource
+    ///   optimization. Confirmed live from a real session log: tens of
+    ///   thousands of consecutive `page flip failed: Device or resource
     /// busy` lines a few *microseconds* apart, the compositor's one thread
-    /// spinning flat out on nothing else, which is what actually explains
-    /// the user's report of losing pointer input and the ability to
-    /// switch VTs at all after switching away and back once - not a
-    /// separate input bug, this loop simply never yielded the CPU back to
-    /// anything else, libinput's own event processing included.
+    ///   spinning flat out on nothing else, which is what actually explains
+    ///   the user's report of losing pointer input and the ability to
+    ///   switch VTs at all after switching away and back once - not a
+    ///   separate input bug, this loop simply never yielded the CPU back to
+    ///   anything else, libinput's own event processing included.
     pub(crate) flip_retry_after: Option<Instant>,
 }
 
diff --git a/crates/wayland/src/udev/platform.rs b/crates/wayland/src/udev/platform.rs
index 45def0a..c400183 100644
--- a/crates/wayland/src/udev/platform.rs
+++ b/crates/wayland/src/udev/platform.rs
@@ -704,13 +704,13 @@ impl Platform for UdevPlatform {
 
     /// One `srdwm_core::Monitor` per head, positioned in the global space
     /// - or several, when `srd.monitor.split` has requested that head be
-    /// divided into logical sub-monitors ("monitors inside monitors"; see
-    /// `srdwm_core::monitor::MonitorSplit`'s own doc comment). This is
-    /// what makes core's layout engine multi-monitor-aware in practice:
-    /// `arrange_workspace` groups windows by `monitor` and lays each group
-    /// out inside that monitor's rectangle - a split just means more,
-    /// smaller rectangles feeding the same grouping, no other core-side
-    /// change needed.
+    ///   divided into logical sub-monitors ("monitors inside monitors"; see
+    ///   `srdwm_core::monitor::MonitorSplit`'s own doc comment). This is
+    ///   what makes core's layout engine multi-monitor-aware in practice:
+    ///   `arrange_workspace` groups windows by `monitor` and lays each group
+    ///   out inside that monitor's rectangle - a split just means more,
+    ///   smaller rectangles feeding the same grouping, no other core-side
+    ///   change needed.
     fn monitors(&mut self) -> PlatformResult<Vec<srdwm_core::Monitor>> {
         let Some(udev) = self.state.udev.as_ref() else { return Ok(Vec::new()) };
         let wm = self.state.wm.clone();