On 5/31/19, Raj Kiran Grandhi <grajki...@gmail.com> wrote: > Hi, > > In a fresh install of Buster with XFCE desktop, locking the screen > blanks the monitor and the monitor enters a power save state. After > that, neither moving the mouse nor typing on the keyboard would turn > the monitor back on. > > Typing the password without any visual feedback (while the monitor > continues to be in the power save state) unlocks the screen and my > session is displayed normally. > > Also, switching to another VT when the monitor turns off and switching > back displays the unlock prompt normally. > > The closest I could find online was this: > https://bbs.archlinux.org/viewtopic.php?id=240200 wherein installing > the nouveau video driver appeared to have fixed the issue. However, > that solution is not applicable in my case as I have an integrated > intel graphics controller. > > Is anybody else experiencing this bug? Any workaround?
Hi, sorry, no direct answer, BUT... #1 this just came up fairly recently. If it was you, never mind, grin. If not, it was the same deal where they had the presence of mind to try that trick of typing in the password anyway... and #ItWORKS (as a temporary work-around). Maybe that thread's easily findable in the archive if it was not you previously? I don't remember the outcome for that one. #2 A WEIRD coincidence of a stumbled upon late last night. I was wanting to commiserate with a different thread related to Wifi and failed modules "polling". That landed me at /var/log/syslog and friends. While scouring that, I noticed this ODD message in there: linux intel_powerclamp: No package C-state available *hm!* Um.. *hm?* :D Researching it landed the following among a lot of other things (*waving at kernel[newbies]): https://www.kernel.org/doc/Documentation/thermal/intel_powerclamp.txt I THINK that just kind of talks about it. WHY I'm not hesitating to post it at this point is because I'm seeing references like "sleep state" in the various blurbs that pulled up for my own search last night. "Sleep" and "wakeups" do get a head nod in that Kernel doc there. Oh, and that word "intel" in mine and then you mentioned it, too, is why I went ahead and shared this here. May not be directly related, but it *does* seem to be in the nearby sleep and hibernate and *successfully (emphasis on "fully")* resume, yada-yada ballpark. If not appropriate for this, it's a thought seed planted as a checkpoint for past and future threads of this type. :) If nothing else, it's like what happened with mine last night. Go poking around at one thing... like just how DOES C-state get addressed under the hood... and maybe in the meantime, someone accidentally trips on the trigger line of code that's causing an occasional sleep/hibernate session to not bring that password prompt GUI back into view.. Could that be a line of code residing in each, our personal CHOICE of login manager? As I'm still thinking on this before sending: Lockscreen doesn't necessarily imply hibernate/sleep state. Maybe that's a place for a glitch to occur. Maybe... there's a missing line of code that would tell it that hey, you weren't asleep but let's pretend you were so we need to do what we do if you HAD been asleep > push this button/release that one so that yada-yada is freed up enough to trigger that password prompt GUI to squeeze its way through and back onto the screen... PS For newbies'ish wondering what you might learn next about your own setups, if you haven't found it already, check out that.. /var/log/syslog in its various forms (.1, .gz, etc). Never know what you might find in there that could lead to more learning about how your own system works. I forget to peek in there when I'm bored, but it's been a helpful self-education trigger for me over time. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *