It appears this issue is also being tracked upstream [1].
The issue was fixed by adding firmware code that powers off the HDMI port, which in turn causes most monitors to go into suspend mode and turning off [2]. The fkms driver was modified to make use of that firmware feature [3]. Since I can't reproduce the issue, I can't verify this myself, but my assumption would be that the issue does not present itself when the fkms overlay is being used.
With regards to the full kms driver, I don't see how this could be fixed, considering that using a firmware feature is required. So as far as I can see, if using the fkms driver is not an option, there is nothing we could do to solve this issue.
It appears this issue is also being tracked upstream [1].
The issue was fixed by adding firmware code that powers off the HDMI port, which in turn causes most monitors to go into suspend mode and turning off [2]. The fkms driver was modified to make use of that firmware feature [3]. Since I can't reproduce the issue, I can't verify this myself, but my assumption would be that the issue does not present itself when the fkms overlay is being used.
With regards to the full kms driver, I don't see how this could be fixed, considering that using a firmware feature is required. So as far as I can see, if using the fkms driver is not an option, there is nothing we could do to solve this issue.
[1]: https:/ /github. com/raspberrypi /linux/ issues/ 3050 /github. com/raspberrypi /firmware/ commit/ 00ea13eff012e6c a1488dc84e73bfe a7fd6a0612 /github. com/raspberrypi /linux/ pull/3289
[2]: https:/
[3]: https:/