@BrodieOnLinux If the display server crashes without being able to clean up (and if it actually has cleanup code; For example wlroots-based compositors don't have cleanup code even on VT switch, so if you eg. use Cosmic or Anvil and Sway in two VTs you'll get windows stuck on the screen), the display controller simply persists the current state and keeps rendering the cursor framebuffer which is still in VRAM.
See also https://docs.kernel.org/gpu/drm-kms.html
(3/? 🧵)
@BrodieOnLinux
The framebuffer console (which is the text console terminal emulator in the kernel, fbcon.c), which uses the legacy framebuffer subsystem for rendering, which is then driven with a driver that implements the legacy framebuffer API on top of the DRM subsystem, doesn't have any cleanup code for planes, so this is what you get :P
We don't remember the name of the DRM compatibility driver on the top of our head, would have to check back.
(4/4 🧵)
@BrodieOnLinux
The framebuffer console (which is the text console terminal emulator in the kernel, fbcon.c), which uses the legacy framebuffer subsystem for rendering, which is then driven with a driver that implements the legacy framebuffer API on top of the DRM subsystem, doesn't have any cleanup code for planes, so this is what you get :P