On Sat, Jun 18, 2022 at 11:21 PM Fulko Hew fulko.hew@gmail.com wrote:
On Sat, Jun 18, 2022 at 8:55 PM Robert McBroom via users < users@lists.fedoraproject.org> wrote:
On 6/18/22 20:10, Fulko Hew wrote:
On Sat, Jun 18, 2022 at 7:34 PM Robert McBroom via users < users@lists.fedoraproject.org> wrote:
On 6/2/22 09:08, stan via users wrote:
On Wed, 1 Jun 2022 10:54:50 -0400 Fulko Hewfulko.hew@gmail.com wrote:
I just had it again, it's very rare. And it's happened over the last number of Fedora versions (-1 to -n)
If I come back to use my computer and hit a key at exactly the same time as the screen decides to blank (I don't use screensavers) then the screen does blank, but no key or mouse activity (I've tried) will cause the screen to wake up again. I know the machine is still active because one of the keystrokes I tried, woke up and started to play a Youtube video that was paused on one of my browser instances.
So everything is still working, but nothing (I've found) will un-blank the screen.
Idea's anyone?
[It's hard to replicate, but I seem to be able to time it right/wrong every few months.]
What you describe is being caused by a race condition of some kind. The screensaver is not using locks to ensure atomic actions. So, two events are occurring at roughly the same time, and depending on which one wins the race, the screen recovers or thinks it is already recovered, even though it is blank [blank loses the race]. You could open a bugzilla against the screensaver, just so they are aware of the issue. It probably won't get fixed on its own, but if they are in the code anyway for something else, they might look at this too, if they know about it.
Have you tried switching to a virtual console, Ctl-Alt-F[3-6]? That should trigger a context switch to the framebuffer driver, which refreshes the monitor. Then, if you switch back to the gui, usually Ctl-Alt-F1, the context switch back to the desktop should initialize things properly, because it thinks it is already active. Worth a try, but no guarantees. The virtual consoles have been losing functionality [1] as fewer and fewer developers use them, and recently started using simplefb from the kernel, so I'm not sure if that might not short circuit any context switching.
- The latest was losing the scrollback buffer. That meant that
screen lost its scrollback as well. I really miss it, any one know of
a
user space replacement, I'm tired of typing ' | less' after everything, the second time, when things scroll off the screen the first time. :-) Searching hasn't turned up a viable alternative. _______________________________________________
Can use pkill, pgrep to query and restart the gui from the virtual console.
Except that when this happens, I don't think I can switch to a virtual console. Or at least if I did, the screen is still blanked and I'd be typing blind.
Terminology problem. Ctl-Alt-F[3-6] gives you a command line session that is completely separate from your original. Requires login.
Yes, I am aware of that. It was the 2nd thing I tried. No matter what keystrokes I tried including screen switches, I could not get anything that would light up the screen again.
Are you using vncserver started by systemd?
I normally use VNC on servers so I can work from one workstation. Recently the workstation had an SSD fail. When I tried logging in on a server, I got a blank screen. <Ctrl-Alt-FN> for N>1 all gave blank screens, but <Ctrl-Alt-F1> got me back to the login screen where I could log in as a different user and kill the vncserver for my regular login.
I've had monitors with multiple inputs that would switch to the other input when the screen blanked and require manually switching back using the buttons on the monitor. This was a while ago, but I suspect a KVM may have been involved.