[GH-ISSUE #1005] Mouse rotation blocked in fullscreen fps game #804

Open
opened 2026-05-05 07:09:41 -06:00 by gitea-mirror · 7 comments
Owner

Originally created by @AlbertBaubleDeem on GitHub (Jan 6, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1005

Describe the bug
When in fullscreen fps game on a client screen, the mouse cannot turn the player view rightwards and leftwards for more than approx 400°. The mouse gets stopped by perceived screen edge. Observed in Minecraft.

To Reproduce

Steps to reproduce the behavior:

  1. Move mouse to the client screen and start the game in a fullscreen mode.
  2. Lock the mouse in the client screen using Scroll lock
  3. Observe you cannot turn for more than approx. 400°

Expected behavior
4. I can make several turns leftwards or rightwards with no perceived barrier.

Desktop (please complete the following information):

  • Client screen is a Macbook Pro running MacOS Big Sur 11.1
  • Server screen is a laptop running Ubuntu 18.04.5 LTS
  • Barrier version 2.3.3

Additional context
Also happens on the client in a window mode.

Originally created by @AlbertBaubleDeem on GitHub (Jan 6, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1005 **Describe the bug** When in fullscreen fps game on a client screen, the mouse cannot turn the player view rightwards and leftwards for more than approx 400°. The mouse gets stopped by perceived screen edge. Observed in Minecraft. **To Reproduce** Steps to reproduce the behavior: 1. Move mouse to the client screen and start the game in a fullscreen mode. 2. Lock the mouse in the client screen using Scroll lock 3. Observe you cannot turn for more than approx. 400° **Expected behavior** 4. I can make several turns leftwards or rightwards with no perceived barrier. **Desktop (please complete the following information):** - Client screen is a Macbook Pro running MacOS Big Sur 11.1 - Server screen is a laptop running Ubuntu 18.04.5 LTS - Barrier version 2.3.3 **Additional context** Also happens on the client in a window mode.
Author
Owner

@sethdmoore commented on GitHub (Jan 7, 2021):

Have you tried relativeMouseMoves? That usually overcomes any issues with games reading absolute mouse position.
Keep in mind that this option requires the mouse to be locked to the screen (default key: ScrlLock)

See #663

<!-- gh-comment-id:756358070 --> @sethdmoore commented on GitHub (Jan 7, 2021): Have you tried `relativeMouseMoves`? That usually overcomes any issues with games reading absolute mouse position. Keep in mind that this option requires the mouse to be locked to the screen (default key: ScrlLock) [See #663](https://github.com/debauchee/barrier/issues/663)
Author
Owner

@AlbertBaubleDeem commented on GitHub (Jan 7, 2021):

Have you tried relativeMouseMoves? That usually overcomes any issues with games reading absolute mouse position.
Keep in mind that this option requires the mouse to be locked to the screen (default key: ScrlLock)

See #663

I did try relative mouse moves. It did not make any difference.

Also starting today hotkeys stopped working on Mac client, so I cannot use Scroll lock. I tried mapping the screen lock to a different key, but that also doesn't work at the moment.

Log from using Scroll Lock on the Client:
[2021-01-07T21:36:55] DEBUG1: recv key down id=0x0000ef14, mask=0x2000, button=0x004e
[2021-01-07T21:36:55] DEBUG1: ignored key ef14 2000
[2021-01-07T21:36:56] DEBUG1: recv key up id=0x0000ef14, mask=0x2000, button=0x004e

<!-- gh-comment-id:756369568 --> @AlbertBaubleDeem commented on GitHub (Jan 7, 2021): > Have you tried `relativeMouseMoves`? That usually overcomes any issues with games reading absolute mouse position. > Keep in mind that this option requires the mouse to be locked to the screen (default key: ScrlLock) > > [See #663](https://github.com/debauchee/barrier/issues/663) I did try relative mouse moves. It did not make any difference. Also starting today hotkeys stopped working on Mac client, so I cannot use Scroll lock. I tried mapping the screen lock to a different key, but that also doesn't work at the moment. Log from using Scroll Lock on the Client: [2021-01-07T21:36:55] DEBUG1: recv key down id=0x0000ef14, mask=0x2000, button=0x004e [2021-01-07T21:36:55] DEBUG1: ignored key ef14 2000 [2021-01-07T21:36:56] DEBUG1: recv key up id=0x0000ef14, mask=0x2000, button=0x004e
Author
Owner

@AlbertBaubleDeem commented on GitHub (Jan 17, 2021):

After some testing, I found out that Scroll lock button activating screen lock on the client works or doesn't based on which keyboard language is set on the server.

When keyboard language is Czech on the server the Scrlock doesn't work on the Client. Xev log gives:
"FocusOut event, serial 37, synthetic NO, window 0x2600001,
mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 37, synthetic NO, window 0x2600001,
mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 37, synthetic NO, window 0x0,
keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"

When keyboard language is English on the server the Scrlock does work on the Client. Xev log gives:
"FocusOut event, serial 37, synthetic NO, window 0x2600001,
mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 37, synthetic NO, window 0x2600001,
mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 37, synthetic NO, window 0x0,
keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"

In both cases there the expected outcome of xev should be KeyPress, KeyRelease kind of log and it isn't.

I run Keycodes on OSX client and there is no record on scroll lock pressed when either language is set on the keyboard.

<!-- gh-comment-id:761838291 --> @AlbertBaubleDeem commented on GitHub (Jan 17, 2021): After some testing, I found out that Scroll lock button activating screen lock on the **client** works or doesn't based on which keyboard language is set on the **server**. When keyboard language is Czech on the server the Scrlock doesn't work on the Client. Xev log gives: "FocusOut event, serial 37, synthetic NO, window 0x2600001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 37, synthetic NO, window 0x2600001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 37, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0" When keyboard language is English on the server the Scrlock does work on the Client. Xev log gives: "FocusOut event, serial 37, synthetic NO, window 0x2600001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 37, synthetic NO, window 0x2600001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 37, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0" In both cases there the expected outcome of xev should be KeyPress, KeyRelease kind of log and it isn't. I run Keycodes on OSX client and there is no record on scroll lock pressed when either language is set on the keyboard.
Author
Owner

@AlbertBaubleDeem commented on GitHub (Jan 17, 2021):

Have you tried relativeMouseMoves? That usually overcomes any issues with games reading absolute mouse position.
Keep in mind that this option requires the mouse to be locked to the screen (default key: ScrlLock)
See #663

I did try relative mouse moves. It did not make any difference.

Also starting today hotkeys stopped working on Mac client, so I cannot use Scroll lock. I tried mapping the screen lock to a different key, but that also doesn't work at the moment.

Log from using Scroll Lock on the Client:
[2021-01-07T21:36:55] DEBUG1: recv key down id=0x0000ef14, mask=0x2000, button=0x004e
[2021-01-07T21:36:55] DEBUG1: ignored key ef14 2000
[2021-01-07T21:36:56] DEBUG1: recv key up id=0x0000ef14, mask=0x2000, button=0x004

relativeMouseMoves did indeed start working after a system reboot - client and server restart wasn't enough.

However, the anomaly with scroll lock key persists. I might raise it as a new issue, not to mix the two.

<!-- gh-comment-id:761838801 --> @AlbertBaubleDeem commented on GitHub (Jan 17, 2021): > > Have you tried `relativeMouseMoves`? That usually overcomes any issues with games reading absolute mouse position. > > Keep in mind that this option requires the mouse to be locked to the screen (default key: ScrlLock) > > [See #663](https://github.com/debauchee/barrier/issues/663) > > I did try relative mouse moves. It did not make any difference. > > Also starting today hotkeys stopped working on Mac client, so I cannot use Scroll lock. I tried mapping the screen lock to a different key, but that also doesn't work at the moment. > > Log from using Scroll Lock on the Client: > [2021-01-07T21:36:55] DEBUG1: recv key down id=0x0000ef14, mask=0x2000, button=0x004e > [2021-01-07T21:36:55] DEBUG1: ignored key ef14 2000 > [2021-01-07T21:36:56] DEBUG1: recv key up id=0x0000ef14, mask=0x2000, button=0x004 relativeMouseMoves did indeed start working after a system reboot - client and server restart wasn't enough. However, the anomaly with scroll lock key persists. I might raise it as a new issue, not to mix the two.
Author
Owner

@FireCulex commented on GitHub (Jan 31, 2021):

I can confirm this issue in windows as well. You can't turn your character around in an FPS, relative mouse moves does nothing. I also don't have scroll lock button on my keyboard so I remapped it. However the lock screen gets stuck once it's on another client. The only way to bring the mouse back is to turn off the client. I tried using hotkeys to specifically tell which screen to put the cursor on, but that doesn't work either because if I move the mouse too far to the left, the server starts pressing buttons. Its a bit of a mess. Win10

<!-- gh-comment-id:770303442 --> @FireCulex commented on GitHub (Jan 31, 2021): I can confirm this issue in windows as well. You can't turn your character around in an FPS, relative mouse moves does nothing. I also don't have scroll lock button on my keyboard so I remapped it. However the lock screen gets stuck once it's on another client. The only way to bring the mouse back is to turn off the client. I tried using hotkeys to specifically tell which screen to put the cursor on, but that doesn't work either because if I move the mouse too far to the left, the server starts pressing buttons. Its a bit of a mess. Win10
Author
Owner

@ChiAkuma commented on GitHub (Aug 13, 2022):

Is there any news on this?
I got that issue, too and its annoying

<!-- gh-comment-id:1214212022 --> @ChiAkuma commented on GitHub (Aug 13, 2022): Is there any news on this? I got that issue, too and its annoying
Author
Owner

@bline commented on GitHub (Sep 5, 2022):

Not being able to rotate fully in-game happens to me regardless of relativeMouseMoves but only in MacOS, when I boot to windows relativeMouseMoves solves it.

<!-- gh-comment-id:1236446458 --> @bline commented on GitHub (Sep 5, 2022): Not being able to rotate fully in-game happens to me regardless of relativeMouseMoves but only in MacOS, when I boot to windows relativeMouseMoves solves it.
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#804
No description provided.