Render the real cursor on the GPU render path, not just a clear color

Past clear-color-only (Phase 2): the GPU-driven head now shows the
same moving cursor the Pixman path renders, via cursor::render_elements
- already generic over the renderer (R: Renderer + ImportAll +
ImportMem), so it works unmodified against gpu.renderer (GlesRenderer)
instead of udev.renderer (PixmanRenderer).

GpuElement (gpu.rs) widened from a bare MemoryRenderBufferRenderElement
to crate::elements::OverlayElement<GlesRenderer> - the same
Surface/Memory/Solid enum the Pixman path's own custom_elements already
uses, needed once the element list stopped always being empty.

Window content and decorations remain a real gap - a GPU-driven head
still shows no windows, just its own clear color and cursor. Untested
on real GPU-enabled hardware this work (SRDWM_GPU unset on this
machine's live session); builds, passes clippy, full test suite green.

1 files changed, 19 insertions, 9 deletions

diff --git a/crates/wayland/src/udev/gpu.rs b/crates/wayland/src/udev/gpu.rs
index 50c42c1..904a420 100644
--- a/crates/wayland/src/udev/gpu.rs
+++ b/crates/wayland/src/udev/gpu.rs
@@ -1,8 +1,14 @@
 //! Opt-in (`SRDWM_GPU=1`) GBM+EGL+`DrmCompositor` GPU render path for the
 //! udev backend - see [`probe`]'s own doc comment for exactly what this
-//! does and does not do yet (Phase 2: one output, clear-color only, no
-//! window content/decorations, no VT-switch support - see the plan this
-//! was built from, `snappy-percolating-boole.md`, for the full scoping).
+//! does and does not do yet. Past the original Phase 2 (one output,
+//! clear-color only - see the plan this was built from, `snappy-
+//! percolating-boole.md`, for that phase's own scoping): every head
+//! `initialize_output` succeeds for gets driven, not just the first
+//! (`GpuContext::outputs`), VT-switch pause/activate is wired
+//! (`udev/session.rs`'s `SessionEvent` handlers), and the real cursor
+//! renders on top of the clear color (`udev/render.rs`'s own GPU branch).
+//! Window content and decorations are the remaining gap - a GPU-driven
+//! head still shows no windows, just its own clear color and cursor.
 
 use std::os::fd::{AsFd, OwnedFd};
 
@@ -11,7 +17,6 @@ use smithay::backend::drm::exporter::gbm::GbmFramebufferExporter;
 use smithay::backend::drm::output::{DrmOutput, DrmOutputManager, DrmOutputRenderElements};
 use smithay::backend::drm::{DrmDevice, DrmDeviceFd, DrmDeviceNotifier};
 use smithay::backend::egl::{EGLContext, EGLDevice, EGLDisplay};
-use smithay::backend::renderer::element::memory::MemoryRenderBufferRenderElement;
 use smithay::backend::renderer::gles::GlesRenderer;
 use smithay::output::Output;
 use smithay::reexports::drm::buffer::DrmFourcc;
@@ -21,11 +26,16 @@ use smithay::utils::DeviceFd;
 
 use super::Card;
 
-/// The concrete render-element type this phase's (empty) element list uses
-/// - see [`GpuContext::initialize_output`]'s own doc comment for why the
-/// actual choice of `E` doesn't matter yet, since no real elements are
-/// passed through it.
-type GpuElement = MemoryRenderBufferRenderElement<GlesRenderer>;
+/// The render-element type real frames on the GPU path push through --
+/// `crate::elements::OverlayElement`, the same enum (Surface/Memory/Solid)
+/// the Pixman path's own `custom_elements` already uses, just instantiated
+/// for `GlesRenderer` instead of `PixmanRenderer`. Started out as a bare
+/// `MemoryRenderBufferRenderElement<GlesRenderer>` back when this phase's
+/// element list was always empty and the concrete choice genuinely didn't
+/// matter - widened once `render_udev_frame`'s GPU branch started pushing
+/// a real cursor (`cursor::render_elements`' own return type) through
+/// `render_frame`.
+type GpuElement = crate::elements::OverlayElement<GlesRenderer>;
 
 /// One head successfully driven through `DrmOutputManager::initialize_output`
 /// - see [`GpuContext::initialize_output`]'s own doc comment.