I would start with the graphics stacks and teach them to
runtime-suspend the HW when the displays go off. No firmware
notifications are needed for this to work.
Well the problem with this is there is a sizable latency to runtime
suspend hardware when displays go off. For example you would need to
redo link training when you spin the hardware back up.
What we do today (AMD *dGPU* centric) is runtime suspend the hardware
when no displays are connected and nothing else is using the GPU (for
offload purposes).
On AMD APU we don't use runtime suspend. If you ignore the latency I
could see an argument for proxying the status of displays to indicate
runtime suspended, but I don't know what it really buys you.
Then, I would teach
graphics drivers to leave the devices in runtime-suspend if they are
runtime-suspended when system suspend starts and to leave them in
runtime-suspend throughout the system suspend and resume, so they are
still runtime-suspended whey system resume is complete. I'm not sure
how far away graphics stacks are from this, but at least some of them
support runtime PM, so maybe the fruits don't hang very high. With
that, you'd just need a way to trigger a system suspend after a period
of inactivity when the displays are off and you have your "dark mode".
I think even without kernel changes this can be accomplished today with
userspace.
There will be change events when the displays are turned off and you can
listen to and set a timer to enter system suspend based upon how long
they are off.
