discards the first key when unlocking screen/logging in from suspend state

Bug #133658 reported by Jeff Fortin Tam
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)

Bug Description

the first letter of the password is never registered on the first try when
coming back from suspend (or other power saving modes?)

Steps to reproduce:
1. suspend to ram
2. wake; the password screen shows up
3. type the first letter of your password; it will not be registered
4. continue typing your password thinking everything is normal

Actual results:
the prompt tells you it failed

Expected results:
grab the first key, don't discard it

Does this happen every time?
Yes. Yes. Yes. It has taken me so long to figure out I had to consult a
psychiatrist about my "I feel the urge to enter my password, erase it, and
enter it again" problems.

Other information:
I will attach a short ogg theora video demonstrating the problem. Oh, and I'm filing this bug report on GPM instead of gnome screensaver, because
this never happens if I simply lock the screen. It only happens if I come back from suspend.

Revision history for this message
Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. With which release of Ubuntu did you notice this? Thanks in advance.

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

all releases I could get my paws on: edgy, feisty, gutsy. I can reproduce it right now, at will.

Sorry for the duplicate, I blame this slow connection and various launchpad errors.
By the way, this whole bug report comes from upstream, they said they can't fix it and it's distro bug: http://bugzilla.gnome.org/show_bug.cgi?id=426917

Please see the upstream bug report for demonstration videos I shot with my camera, they are my proof :) I can't upload them to launchpad with this slow connection, I always get an error in the end, so if you want to, you are welcome to attach them to this bug report.

Revision history for this message
Brian Murray (brian-murray) wrote :

What happens if the first key you press is your "Caps Lock" key or "Num Lock" key? Additionally, it would be the most beneficial if you could continue to test this with Gutsy Gibbon. What type of system are you testing this with?

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

My primary machines are on gutsy gibbon, so no problem testing on that.

I just tried your capslock/numlock idea, and they behave exactly the same as if I pressed any other key (well, except the fn key I guess). This is on a laptop, so for the numlock I had to use an external keyboard to type the lettered password, and for caps lock I actually activated it before suspending, so when I unsuspended the capslock deactivated when I first pressed it; and then I could type in the password without problems.

So, in short, it seems the system needs some kind of first keyboard stroke to "wake" the keyboard, no matter what that stroke is; however, if it's capslock/numlock, that first stroke will ALSO activate/deactivate caps/numlock.

Any idea where the root of the problem might lie?

Revision history for this message
Brian Murray (brian-murray) wrote :

Is this only reproducable for you on one system? If so make and model of system is it? I was unable to reproduce it using Gutsy Gibbon and and an HP dv6000 laptop.

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

this is on my acer travelmate 2428 (the only one of my computers that actually can suspend... and resume correctly most of the times since sometimes the keyboard is borked on resume (weird keymap that makes me reset the machine).

Here is a full hardware dump (with hardinfo) that might help you, I hope.

Revision history for this message
Brian Murray (brian-murray) wrote :

Sorry for the delay in getting back to you. Is this still an issue at this point in time?

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

In the meantime, I tried using an alternate suspend method, that is using "uswsusp" (which allows the "s2ram" command if you install the debian package instead of the ubuntu one, bug 134238). The problem is gone with uswsusp, but it's still an issue for those who don't hack their computers into using a different suspend package yes.

Changed in gdm:
status: Unknown → Invalid
Revision history for this message
Brian Murray (brian-murray) wrote :

To determine whether or not this is a kernel problem it would be helpful if you were to boot into single user mode and then suspend via the command 'pmi action suspend'.

Revision history for this message
Kiri (kiri) wrote :

I had some occurrences of the first password not being accepted, which could be attributed to this bug. Experienced in Lucid with GNOME+GDM.

tags: added: lucid
Changed in gdm:
importance: Unknown → Medium
status: Invalid → Unknown
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

As per comment #10 this is gdm issue. Marking as such.

affects: ubuntu → gdm (Ubuntu)
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

As per upstream bug, this is not GNOME issue, marking new.

Changed in gdm (Ubuntu):
status: Incomplete → New
Revision history for this message
Thomas Hotz (thotz-deactivatedaccount) wrote :

Confirming because it happens to several users.

Changed in gdm (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.