[GH-ISSUE #322] Keyboard input on server doesn't work after client is shut down/slept/etc. until mouse moved #253

Open
opened 2026-05-05 05:51:47 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @retnikt on GitHub (May 26, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/322

Operating Systems

Server: Ubuntu 18.04

Client: Windows 10 v1809

Barrier Version

2.2.0

Steps to reproduce bug

  1. Move mouse cursor to client screen
  2. Shutdown/sleep/etc the client without moving the mouse
  3. Do some keyboard input without moving the mouse
  4. Observe that the keyboard input is ignored
  5. Move the mouse
  6. Keyboard input now works

Other info

  • When did the problem start to occur? Always I think
  • Is there a way to work around it? Yes, you can... move the mouse
  • Does this bug prevent you from using Barrier entirely? No

This also applies to the power button, and probably other input devices.

See also #316.

Originally created by @retnikt on GitHub (May 26, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/322 ### Operating Systems ### Server: Ubuntu 18.04 Client: Windows 10 v1809 ### Barrier Version ### 2.2.0 ### Steps to reproduce bug ### 1. Move mouse cursor to client screen 2. Shutdown/sleep/etc the client without moving the mouse 3. Do some keyboard input without moving the mouse 4. Observe that the keyboard input is ignored 5. Move the mouse 6. Keyboard input now works ### Other info ### * When did the problem start to occur? Always I think * Is there a way to work around it? Yes, you can... move the mouse * Does this bug prevent you from using Barrier entirely? No This also applies to the power button, and probably other input devices. See also #316.
gitea-mirror added the
bug
label 2026-05-05 05:51:47 -06:00
Author
Owner

@AdrianKoshka commented on GitHub (May 26, 2019):

This is my opinion, but barrier is about sharing the keyboard and mouse, not other auxiliary inputs like power buttons and such.

<!-- gh-comment-id:496025034 --> @AdrianKoshka commented on GitHub (May 26, 2019): This is my opinion, but barrier is about sharing the _keyboard_ and _mouse_, not other auxiliary inputs like power buttons and such.
Author
Owner

@retnikt commented on GitHub (May 26, 2019):

I think you are misunderstanding the issue. The problem is that the
keyboard doesn't work. The note about power buttons on the server was
because Barrier currently shares the power button (but it shouldn't - see
#316) which means it doesn't work either without having moved the mouse.

<!-- gh-comment-id:496026356 --> @retnikt commented on GitHub (May 26, 2019): I think you are misunderstanding the issue. The problem is that the keyboard doesn't work. The note about power buttons on the server was because Barrier currently shares the power button (but it shouldn't - see #316) which means it doesn't work either without having moved the mouse.
Author
Owner

@noisyshape commented on GitHub (May 26, 2019):

  1. Are you waiting long enough for control to return to the server? There's a delay of several seconds before control switches from a dead client to the server.
  2. Are you sure the keyboard is unresponsive? If no window has focus, you should be testing window manager actions like alt-tab.

If the answer to both of these is yes, post your log starting with the line that says the client is dead.

<!-- gh-comment-id:496030317 --> @noisyshape commented on GitHub (May 26, 2019): 1. Are you waiting long enough for control to return to the server? There's a delay of several seconds before control switches from a dead client to the server. 2. Are you sure the keyboard is unresponsive? If no window has focus, you should be testing window manager actions like alt-tab. If the answer to both of these is yes, post your log starting with the line that says the client is dead.
Author
Owner

@retnikt commented on GitHub (May 27, 2019):

Ok, the keyboard does actually work, so the issue is that focus is not
returned to the originally active window. This is definitely less of an
problem, but still present.

On Sun, May 26, 2019 at 9:47 PM noisyshape notifications@github.com wrote:

  1. Are you waiting long enough for control to return to the server?
    There's a delay of several seconds before control switches from a dead
    client to the server.
  2. Are you sure the keyboard is unresponsive? If no window has focus,
    you should be testing window manager actions like alt-tab.

If the answer to both of these is yes, post your log starting with the
line that says the client is dead.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/debauchee/barrier/issues/322?email_source=notifications&email_token=AF3RNCSVERDBHHKTUOY6PK3PXLZPRA5CNFSM4HPXIINKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWINE3I#issuecomment-496030317,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF3RNCTFSOJFS2TANBW7AWDPXLZPRANCNFSM4HPXIINA
.

<!-- gh-comment-id:496126679 --> @retnikt commented on GitHub (May 27, 2019): Ok, the keyboard does actually work, so the issue is that focus is not returned to the originally active window. This is definitely less of an problem, but still present. On Sun, May 26, 2019 at 9:47 PM noisyshape <notifications@github.com> wrote: > > 1. Are you waiting long enough for control to return to the server? > There's a delay of several seconds before control switches from a dead > client to the server. > 2. Are you sure the keyboard is unresponsive? If no window has focus, > you should be testing window manager actions like alt-tab. > > If the answer to both of these is yes, post your log starting with the > line that says the client is dead. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/debauchee/barrier/issues/322?email_source=notifications&email_token=AF3RNCSVERDBHHKTUOY6PK3PXLZPRA5CNFSM4HPXIINKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWINE3I#issuecomment-496030317>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AF3RNCTFSOJFS2TANBW7AWDPXLZPRANCNFSM4HPXIINA> > . >
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#253
No description provided.