Unnecessary Modesets are still performed #205
Description
I'm making this issue in response to feedback received on discussion 11560 in the Hyprland repository. Also, I'm far from an expert on DRM KMS on Linux, this investigation has been my first real attempt to dig into this sort of thing, so anyone whose more knowledgeable on the topic is free to chime in on why what I'm suggesting is stupid.
Overview
In order to provide a flicker-free experience, Hyprland should prevent itself from performing video modesets unless absolutely necessary. Obviously, a modeset is necessary when the current video mode doesn't match the requested one, but as shown with #184 and #198, there are additional situations in which modesets remain necessary. That being said Hyprland still performs modesets when it (seemingly) doesn't need to.
Known Examples
- Switching from a TTY back to Hyprland always causes a modeset, regardless of whether or not the current mode matches what Hyprland is configured fore
- Exiting Hyprland always causes a modeset, again regardless of the state of the TTY
- If there are more examples, feel free to comment them below
Suspected Causes
In order to test this, I injected a bunch of log statements into Atomic.cpp at commit 81584da on main. I haven't been able to track down the cause of the modesets on exit, but it's clear to me that the modesets on returning to Hyprland from the TTY stem from the fact that the DRM connector doesn't have a current mode assigned to it. My guess based on the commit history is that this happens because we call the DRM backend's reset function explicitly when switching back from a TTY.
Again, I'm way out of my depth here, but why are we doing this? What about switching TTY's requires a reset? Additionally, I'm curious about the link between DPMS and the reset function. MR #183 needed to be reverted because it broke DMPS, and as far as I can tell, that's because it gutted the reset function. #183 mentions that reset is called on VT switches and when the backend is initialized, though I can't seem to find the latter.
I don't really have a conclusion to this issue other, than to say that this issue fascinates me for some reason, and I'm curious if anyone has a good idea for a solution. My thought would be to rip reset out of restoreAfterVT, but I kinda doubt it's that simple.
Attachments
I've attached the logs of my session reproducing the issue, the aquamarine patch used to generate some custom log messages, and my system info for those interested.