That's an impressive game crash, I swap TTY and the game cursor is still visible
Can anyone with more GPU knowledge tell me how that should even be possible
@BrodieOnLinux The part of a graphics chip that handles the HDMI output, aka the display controller, has several registers containing pointers into GPU memory. It composites several "planes" on top of each other in order to create the final output, each plane has an input framebuffer pointer configured in the registers. There are three main types of planes usually present -> the primary plane, which contains the output of the display server, the overlay plane, which usually contains (1/?
@BrodieOnLinux directly scanned-out surfaces (On Smithay-based compositors, this is usually the Wayland surface that's in focus), this allows eg. video playback with lower latency, and lastly, cursor planes, where you configure the location of the cursor with registers, and the bound framebuffer is the contents of the cursor plane. Linux lacks any kind of general DRM (Direct Rendering Manager) state management, so cleaning up into a known state is usually the job of a display server (2/?
@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
@sanity @BrodieOnLinux haha we like infodumping about things a lot, esp GPUs :P
@sanity you made us wanna infodump even more reeeeee, the 500 character limit is tortureeeeee
@ity @BrodieOnLinux So this is basically the “hardware cursor”?
Yea this is the "hardware cursor" that display servers talk about when they offer an option between a software cursor (compositing the cursor themselves into the primary plane) and hardware cursor (managing a cursor plane) :P
@BrodieOnLinux framebuffer ouput
@BrodieOnLinux GPUs have a small number of "hardware overlay planes" or "crtc planes". Basically you can render something on a different plane instead of the framebuffer, and the GPU will draw the planes on top of each other when sending the output to the screen.
In ye olden days they used them for videos, because they are good at handling mismatching refreshrates. You would render a square on another plane that was placed where the video player window is.
@BrodieOnLinux it was a nightmare to track the position of the player so they decided it's easier to deal with the weird refresh rates than dealing with that.
So nowadays they are used (I'm sure on windows, I think also on Linux) for swapchain tricks.
One of their main features, which also has extra hardware support is "hardware accelerated cursors". Where the os loads an image on a plane and the rendering of the cursor is handled by the GPU.
@BrodieOnLinux if you ever had situations like "the system is frozen but the cursor moves" or "the nightlight is on but the cursor is still white", they are all caused by hardware cursors.
@BrodieOnLinux like others have already said, this looks a lot like a leftover overlay plane / cursor plane to me.
Usually the tty doesn't draw cursor planes though, so something must have messed up the planes in the display driver.
@BrodieOnLinux X still running
@BrodieOnLinux they left their foot on the somoflange.
@BrodieOnLinux Can it move or is it stuck?
@durchaus It appears to just be a rendering artifact, it doesn't work
@BrodieOnLinux@mstdn.social My games would never crashed like this…it’s always a hard crash for me