Re: Buster/lightdm - after locking screen, unlock prompt not visible
- Date: Fri, 31 May 2019 13:12:39 -0400
- From: Cindy Sue Causey <butterflybytes@xxxxxxxxx>
- Subject: Re: Buster/lightdm - after locking screen, unlock prompt not visible
On 5/31/19, Raj Kiran Grandhi <grajkiran@xxxxxxxxx> wrote:
> 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
#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]):
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
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
Could that be a line of code residing in each, our personal CHOICE of
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.
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *