Linuxロック画面へのVNC接続が「ロック」されていてパスワードを入力できないのはなぜですか？

VNCWindowsコンピュータからLinuxコンピュータに接続するためにViewer / Serverを使用しています。

Linuxシステムでセッションがタイムアウトしてロック画面が起動した後、後でVNCを介してGUIを使用してロックを解除しようとすると、画面にテキストパスワードプロンプトを入力できないように永久に「ロックされた」ように見えます。具体的には、特定のEnter文字ストリームがVNCを介して継続的に送信され、ログインプロンプトをトリガーして、ユーザーが長さ0のパスワードを入力し続けていると思うようにします。添付のスクリーンショットの「認証エラー」ステートメントを参照してください。ログイン画面が考えていることを示します。何すでに入力されています。そしてここでストレステストをすると、すばやく入力すると「隠された文字」の記号が1〜2個表示され、再びすぐに消えます。続いて「認証エラー」が出ます。

この状況で私が見つけた解決策は、Linuxボックスに直接ログインして次のスクリプトを実行することでした。

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done

...その数字は2私の「セッションID」です。このスクリプトは、ロック画面が表示されると（1秒以内に）閉じる効果があります。これは最善の解決策ではありませんが、パスワードを入力できない永続ロックよりも優れています。

これはなぜ必要ですか？VNCビューア/サーバー、Linuxボックスのロック画面、または他の関連ソフトウェアで何が起こっているのか、そしてLinuxログイン画面（または何が起こっているのか）に特別に転送される永続的なストリームがあるEnter理由を説明できる人はいますか？VNCロック画面で間違ったパスワードを入力したように、「認証エラー」を報告し続けますか？

ロック画面を通過すると、bashシェルから不要なキーストロークが送信されたように見えなくなります。つまり、予期しないキーストロークに干渉せずに入力、コマンドの実行などを行うことができます。

関連質問：これがトピックを混同しない場合は、私が実行しているスクリプトが前景にあることに注意してください。つまり：

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done

...いいえ...

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done &

...スクリプトのバックグラウンドバージョンを試してみると、ロック画面が最初に実行されたときにのみ解放され、その後は解放されないワンタイム効果が表示されます。これは、ロック画面を保持しているように見えるスクリプトのフォアグラウンドバージョンと比較されます。永遠に消えます。この場合、解決スクリプトが背景にあるのか、前景にあるのかはなぜ重要ですか？

環境の詳細：

$ uname -a
Linux linuxbox 5.3.11-100.fc29.x86_64 #1 SMP Tue Nov 12 20:41:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

。

$ vncserver -list

TigerVNC server sessions:

X DISPLAY # PROCESS ID
:1  2958

。

$ loginctl list-sessions
SESSION   UID USER    SEAT   TTY
      2  1000 user    seat0  tty2

1 sessions listed.