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

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.

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.

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?

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?

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.

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.

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

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.

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'.

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

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

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

Confirming because it happens to several users.