First key typed is ignored and other input related issues.

[johnfound]

The first character entered as an unlock password is always ignored. For example, if the first character is "A", actually the shift key activates the unlock dialog, but the "A" key is ignored and must be entered twice.

But if you press "Shift", wait a little and then press "A" it is accepted. IMHO, this have something with the window initialization process, which seems to be very slow.

Sometimes when you type the password the whole window flashes (seems like becomes invisible and then back visible).

In addition, the auto-repeat of the keyboard is not working at all. So, when you type the whole password and realize that the first key is ignored, you should press backspace many times in order to correct it. Other editing tricks like selecting all and then delete by the "Del" key are not working as well.

Because of the above misbehavior, after updating XScreenSaver to v6.0 I was never able to type the password correctly from the first time. The only reason why I am still not downgrading is because of the implemented display of the current keyboard layout, which was not available on the 5.x versions.

[naihe2010]

yes. I have these same problems.

[blaa]

xinput.c, xinput_event_to_xlib_1 seems to suggest a reason:

The closest thing to actual documentation on XInput2 seems to be a series
of blog posts by Peter Hutterer.  There's basically nothing about it on
www.x.org.  In http://who-t.blogspot.com/2009/07/xi2-recipes-part-4.html
he says: 

  "XIDeviceEvent [...] contains the state of the modifier keys [...]
  The base modifiers are the ones currently pressed, latched the ones
  pressed until a key is pressed that's configured to unlatch it (e.g.
  some shift-capslock interactions have this behaviour) and finally
  locked modifiers are the ones permanently active until unlocked
  (default capslock behaviour in the US layout). The effective modifiers
  are a bitwise OR of the three above - which is essentially equivalent
  to the modifiers state supplied in the core protocol events."

However, I'm seeing random noise in the various XIDeviceEvent.mods fields.
Nonsensical values like base = 0x6045FB3D.  So, let's poll the actual
modifiers from XQueryPointer.  This can race: maybe the modifier state
changed between when the server generated the keyboard event, and when
we receive it and poll.  However, if an actual human is typing and
releasing their modifier keys on such a tight timeframe... that's
probably already not going well.

I'm also seeing random noise in the event_xy and root_xy fields in
motion events.  So just always use XQueryPointer.

My keyboard has tap-layer on the shift, so when I hit letter it releases the shift event and the key event at the same time in a tight timeframe.

I guess that should be reported to the author.

edit: I described the issue and sent a note to jwz.

[blaa]

I've exchanged some emails with JWZ. Must say - he is very responsive. He suggested some debugging switches and I've found possible culprit (for me at least) and fixed it with following patch. Final fix might differ.

diff --git a/driver/xinput.c b/driver/xinput.c
index c9e8b91..7858e66 100644
--- a/driver/xinput.c
+++ b/driver/xinput.c
@@ -128,7 +128,12 @@ init_xinput (Display *dpy, int *opcode_ret)
 static Bool
 duplicate_xinput_event_p (int evtype, XIDeviceEvent *in)
 {
-  static unsigned long dups[50] = { 0, };
+  typedef struct {
+    int evtype;
+    int detail;
+    unsigned long serial;
+  } key_t;
+  static key_t dups[50] = { 0, };
   int i;
 
   /* Great news, everybody: XEvent.xany.serial is apparently not unique.  Wny?
@@ -151,14 +156,18 @@ duplicate_xinput_event_p (int evtype, XIDeviceEvent *in)
      I'm starting to suspect that maybe, just maybe, the XInput2 library is
      extremely careless about memory management!
    */
-  unsigned long key = (in->serial & 0xFFFF) | (evtype << 16);
+  key_t key;
+  key.evtype = evtype;
+  key.detail = in->detail;
+  key.serial = in->serial;
 
   for (i = 0; i < countof(dups); i++)
-    if (dups[i] == key)
+    if (dups[i].serial == in->serial && dups[i].evtype == evtype
+        && dups[i].detail == in->detail)
       {
         if (debug_p)
-          fprintf (stderr, "%s: discard duplicate XInput event %08lx\n",
-                   blurb(), key);
+          fprintf (stderr, "%s: discard duplicate XInput event %d-%ld-%d\n",
+                   blurb(), evtype, in->serial, in->detail);
         return True;
       }
   for (i = 0; i < countof(dups)-1; i++)

[atpage]

I just ran into this problem after switching from XScreenSaver 5.45 on Ubuntu to 6.06 on Debian. It was never an issue on the old version. Let me know if I can help troubleshoot.