按 Shift 时 XScreenSaver 出现延迟

Question

xscreensaver我在 Debian Bookworm版本 6.02+dfsg1-2上观察到类似的问题。这不是 5 秒的延迟，而是毫秒范围内的延迟，但足以xscreensaver反复丢弃我的大写密码字母，这让我很恼火。 5.45 并没有发生这种情况。

其他谈论的地方： https://github.com/Zygo/xscreensaver/issues/11

这可能是由xinput.c,引起的xinput_event_to_xlib_1，其中有解释种族的评论：

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.

我的键盘带有“点击层”，这解释了“时间紧迫”

编辑：经过一些调试并与 Jamie Zawinski（xscreensaver 作者）交换了几封电子邮件后，我通过duplicate_xinput_event_p修补xinput.c.它可能会以类似或不同的方式在上游得到修复。同时，我将在链接的 github 上发布补丁（在这里发布似乎太大了）。

Answer 1

xscreensaver我在 Debian Bookworm版本 6.02+dfsg1-2上观察到类似的问题。这不是 5 秒的延迟，而是毫秒范围内的延迟，但足以xscreensaver反复丢弃我的大写密码字母，这让我很恼火。 5.45 并没有发生这种情况。

其他谈论的地方： https://github.com/Zygo/xscreensaver/issues/11

这可能是由xinput.c,引起的xinput_event_to_xlib_1，其中有解释种族的评论：

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.

我的键盘带有“点击层”，这解释了“时间紧迫”

编辑：经过一些调试并与 Jamie Zawinski（xscreensaver 作者）交换了几封电子邮件后，我通过duplicate_xinput_event_p修补xinput.c.它可能会以类似或不同的方式在上游得到修复。同时，我将在链接的 github 上发布补丁（在这里发布似乎太大了）。

按 Shift 时 XScreenSaver 出现延迟

答案1

相关内容