<skip> > Thinking some more about this I am having second doubts about > moving the LPS0 display power off call to before devices are suspended, > doing so would mean that the display might still be on when that call > is made and that call could disable power-resources which are necessary > for the display causing issues when the display driver's suspend method > runs. Is there any device where that is used for display powersaving? > So I think that we need something closer to Mario's POC from: > > https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/log/?h=superm1/dsm-screen-on-off > > here where the call is made when the last display is turned off. > > IOW have the drm modesetting core call this. I can see two problems with this approach: 1) it would happen in a random point in the suspend sequence, introducing race conditions with sensitive modern standby devices (e.g., Ally). 2) It would not be gated and debounced properly, so a drm driver could call it 5 times when you e.g., plug in an HDMI cable. And indeed that is the case, that PR horribly breaks the Ally even while any asus-wmi quirk was active. Perhaps DRM can be consulted though, see below. > Maybe have something like a enabled_displays counter in the > drm-core which gets increased / decreased by helpers and > have the drm-core call platform_suspend_screen_off() / > platform_suspend_screen_on() when the counter goes from 1 -> 0 > resp. 0 -> 1, ignoring the very first 0 -> 1 transition > which will be done when the first GPU with an enabled > output is found ? To quote Microsoft [1], "This _DSM Function will be invoked when the operating system has entered a state where all displays—local and *remote*, if any—have been turned off." Since it says remote, binding it to DRM could prove difficult. In addition, the call in Windows is made 5 seconds after the displays turn off due to inactivity. To mirror this behavior you would need userspace. If there is strong indication that the Display On/Off calls interfere with the DRM subsystem, e.g., turn off a GPU in certain laptops, the call could be gated with a counter similar to Mario's PR and error out. In that way, it is still controllable by userspace while ensuring the device display is off. Is there such an indication/do we know of such a device? The Ally and Legion Go which I tested happily had their display turn on after I yanked their display on and sleep exit callbacks. The Legion Go even had its suspend light blink while the screen was on. And both had disabled controllers. This behavior was sticky even after a reboot. I suppose this is due to the fact that the device might hibernate, so the EC would have to remember the last state before power off. > The idea being that the first increase() call gets made when > a drm/kms driver probes a display and finds outputs which are > light up during probe() and then further increase / decrease > calls are made either when all displays go off; or maybe > per crtc when the crtc gets enabled / disabled. > > Anyways how best to do this at display off time should be > discussed with the drm/kms community on the dri-devel list. I can cc on the next version. Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications#display-off-notification-function-3 [1] Antheas
