Fix new clippy lints up to Rust 1.84

Rust points out new issues with improperly indented list items in doc
comments, unnecessary named lifetimes, and missing types in transmutes
(that can be circumvented entirely with helpers).

src/buffer/mod.rs

@@ -16,13 +16,13 @@
 //! There are two methods of sharing a GEM handle between processes:
 //!
 //! 1. Using `Flink` to globally publish a handle using a 32-bit 'name'. This
-//! requires either holding the DRM Master lock or having the process'
-//! [`AuthToken`](struct@crate::AuthToken) authenticated. However, any process can
-//! open these handles if they know (or even guess) the global name.
+//!    requires either holding the DRM Master lock or having the process'
+//!    [`AuthToken`](struct@crate::AuthToken) authenticated. However, any process can
+//!    open these handles if they know (or even guess) the global name.
 //!
 //! 2. Converting the GEM handle into a PRIME file descriptor, and passing it
-//! like a regular one. This allows better control and security, and is the
-//! recommended method of sharing buffers.
+//!    like a regular one. This allows better control and security, and is the
+//!    recommended method of sharing buffers.
 
 use crate::control;
 pub use drm_fourcc::{DrmFourcc, DrmModifier, DrmVendor, UnrecognizedFourcc, UnrecognizedVendor};

src/control/dumbbuffer.rs

@@ -63,7 +63,7 @@ impl DerefMut for DumbMapping<'_> {
     }
 }
 
-impl<'a> Drop for DumbMapping<'a> {
+impl Drop for DumbMapping<'_> {
     fn drop(&mut self) {
         unsafe {
             rustix::mm::munmap(self.map.as_mut_ptr() as *mut _, self.map.len())

src/control/mod.rs

@@ -6,20 +6,20 @@
 //! exposing the following resource types:
 //!
 //! * FrameBuffer - Specific to an individual process, these wrap around generic
-//! GPU buffers so that they can be attached to a Plane.
+//!   GPU buffers so that they can be attached to a Plane.
 //!
 //! * Planes - Dedicated memory objects which contain a buffer that can then be
-//! scanned out by a CRTC. There exist a few different types of planes depending
-//! on the use case.
+//!   scanned out by a CRTC. There exist a few different types of planes depending
+//!   on the use case.
 //!
 //! * CRTC - Scanout engines that read pixel data from a Plane and sends it to
-//! a Connector. Each CRTC has at least one Primary Plane.
+//!   a Connector. Each CRTC has at least one Primary Plane.
 //!
 //! * Connector - Represents the physical output, such as a DisplayPort or
-//! VGA connector.
+//!   VGA connector.
 //!
 //! * Encoder - Encodes pixel data from a CRTC into something a Connector can
-//! understand.
+//!   understand.
 //!
 //! Further details on each resource can be found in their respective modules.
 //!
@@ -214,7 +214,7 @@ pub trait Device: super::Device {
             },
             modes: Mode::wrap_vec(modes),
             encoders: unsafe { transmute_vec_from_u32(encoders) },
-            curr_enc: unsafe { mem::transmute(ffi_info.encoder_id) },
+            curr_enc: from_u32(ffi_info.encoder_id),
             subpixel: connector::SubPixel::from_raw(ffi_info.subpixel),
         };
 

src/control/plane.rs

@@ -7,13 +7,13 @@
 //! types of planes available for use:
 //!
 //! * Primary - A CRTC's built-in plane. When attaching a framebuffer to a CRTC,
-//! it is actually being attached to this kind of plane.
+//!   it is actually being attached to this kind of plane.
 //!
 //! * Overlay - Can be overlaid on top of a primary plane, utilizing extremely
-//! fast hardware compositing.
+//!   fast hardware compositing.
 //!
 //! * Cursor - Similar to an overlay plane, these are typically used to display
-//! cursor type objects.
+//!   cursor type objects.
 
 use crate::control;
 use drm_ffi as ffi;