Shift を押すと XScreenSaver が遅延します。

Question

xscreensaverDebian 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

xscreensaverDebian 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

関連情報