[GH-ISSUE #476] scroll reverse on client

gitea-mirror commented

2026-05-05 06:10:30 -06:00

Owner

Originally created by @technovangelist on GitHub (Oct 22, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/476

Operating Systems

Server: Mac OS Catalina
Client: Mac OS Mojave

Barrier Version

2.3.1 release 58d8f020

Steps to reproduce bug

when using a trackpad, the scrolling direction is reverse of whatever is set in the settings on the client. so what i would expect to be up is down and what i would expect to be right is left

Originally created by @technovangelist on GitHub (Oct 22, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/476 ### Operating Systems ### Server: Mac OS Catalina Client: Mac OS Mojave ### Barrier Version ### 2.3.1 release 58d8f020 ### Steps to reproduce bug ### when using a trackpad, the scrolling direction is reverse of whatever is set in the settings on the client. so what i would expect to be up is down and what i would expect to be right is left

gitea-mirror

2026-05-05 06:10:30 -06:00

closed this issue
added the
macOS

bug
labels

gitea-mirror commented

2026-05-05 06:10:36 -06:00

Author

Owner

@technovangelist commented on GitHub (Oct 22, 2019):

update to this. the left/right direction is always wrong. but it seems that now up/down is correct. Not sure if I just remember wrong, or if it is inconsistent for up/down being reversed.

@technovangelist commented on GitHub (Oct 22, 2019): update to this. the left/right direction is always wrong. but it seems that now up/down is correct. Not sure if I just remember wrong, or if it is inconsistent for up/down being reversed.

gitea-mirror commented

2026-05-05 06:10:38 -06:00

Author

Owner

@technovangelist commented on GitHub (Oct 23, 2019):

and a further update. now up/down is reversed. so the problem is that it isn't consistent. Not sure what the steps are to switch from being the way i expect and then reversed. It is now the next day and both macs did sleep, but couldn't say for certain that had anything to do with it

@technovangelist commented on GitHub (Oct 23, 2019): and a further update. now up/down is reversed. so the problem is that it isn't consistent. Not sure what the steps are to switch from being the way i expect and then reversed. It is now the next day and both macs did sleep, but couldn't say for certain that had anything to do with it

gitea-mirror commented

2026-05-05 06:10:41 -06:00

Author

Owner

@ctsrc commented on GitHub (Nov 9, 2019):

I normally use an external mouse when seated at my desk where I use two computers with Barrier, but I did some testing with the trackpad.

Server: MacBook Air 2018 running macOS Catalina 10.15.1

Client: Running macOS High Sierra 10.13.6

Barrier version: 2.3.2 with 7 additional commits from master (07a1c31, current HEAD of master) and a few commits of my own on top of that (https://github.com/ctsrc/barrier/tree/ctsrc-2019-11-08). My own commits in the version of Barrier that I run are unrelated to the issue at hand.

Normally I also use a piece of software named Scroll Reverser to allow the trackpad and the external mouse to have opposite scroll direction of one another. During testing I disabled (exited) this software, so as to match the setup that one would normally use.

macOS has configurable scroll direction. Scroll direction is configured on macOS as either natural or not. In the macOS help docs they describe the "Scroll direction: Natural" option as:

Select this option to move the contents of a window in the same direction as your fingers.

Below I test and report results for the four different possible combinations of scroll directions between server host and client host.

All tests were performed by changing the host settings for scroll direction on each of the two computers without restarting Barrier. I comment on this at the end of this comment.

This first group of tests will be referred to as "test group A".

A1) "Scroll direction: Natural" option enabled on both hosts

Server host

[x] Scroll direction: Natural

Client host

[x] Scroll direction: Natural

Content tracks finger movement?	Vertically	Horizontally
Server	Yes	Yes
Client	Yes	No!
According to expectations?	Yes. Same direction.	No! Opposite direction.

Result: Bad. Observed horizontal scroll direction on client is opposite to that of server. In this situation we would expect both server and client to have the same scrolling directions (here: "natural") in both the horizontal and the vertical direction.

A2) "Scroll direction: Natural" option disabled on both hosts

Server host

[ ] Scroll direction: Natural

Client host

[ ] Scroll direction: Natural

Content tracks finger movement?	Vertically	Horizontally
Server	No	No
Client	No	Yes!
According to expectations?	Yes. Same direction.	No! Opposite direction.

Result: Bad. Observed horizontal scroll direction on client is opposite to that of server. In this situation we would expect both server and client to have the same scrolling directions (here: inverse of "natural") in both the horizontal and the vertical direction.

A3) "Scroll direction: Natural" option enabled on server host, disabled on client host

Server host

[x] Scroll direction: Natural

Client host

[ ] Scroll direction: Natural

Content tracks finger movement?	Vertically	Horizontally
Server	Yes	Yes
Client	Yes	No
According to expectations?	Maybe Y/N. Same direction.	Maybe N/Y. Opposite direction.

Comment: In this situation, where settings on server and on client are opposite of one-another, it is not obvious what should be the expected behavior – different people might have different opinions or expectations for this situation. However, we can all agree that in this situation either both horizontal and vertical direction of the client should match that of the server, or both should be opposite.

Result: Bad. In this situation, either both horizontal and vertical direction should be opposite to that of server on the client (that is: server "natural", client inverse of "natural"), or both should be the same as that of server (that is: server "natural", client "natural"), or both should be the same as that of client (that is: server inverse of "natural", client inverse of "natural"). Instead, vertical scroll direction is the same on both but horizontal is opposite.

A4) "Scroll direction: Natural" option disabled on server host, enabled on client host

Server host

[ ] Scroll direction: Natural

Client host

[x] Scroll direction: Natural

Content tracks finger movement?	Vertically	Horizontally
Server	No	No
Client	No	Yes
According to expectations?	Maybe Y/N. Same direction.	Maybe N/Y. Opposite direction.

Comment: In this situation, as with the situation right above this one (situation A3), where settings on server and on client are opposite of one-another, it is not obvious what should be the expected behavior – different people might have different opinions or expectations for this situation. However, just as with the aforementioned situation, we can all agree that in this situation either both horizontal and vertical direction of the client should match that of the server, or both should be opposite.

Result: Bad. In this situation, as with the one above (situation A3), either both horizontal and vertical direction should be opposite to that of server on the client (that is: server inverse of "natural", client "natural"), or both should be the same as that of server (that is: server inverse of "natural", client inverse of "natural"), or both should be the same as that of client (that is: server "natural", client "natural"). Instead, vertical scroll direction is the same on both but horizontal is opposite.

Discussion of observations

In all of the four cases I observed the following:

Observed vertical scroll direction always matches the setting of the server host on both server and client, regardless of setting on the client host.
Observed horizontal scroll direction is always opposite on the client to the setting of the server host, regardless of setting on the client host.

On what is meant by observed scroll direction

When I speak of observed scroll direction here, I am speaking strictly of using the trackpad on the server host (the MacBook Air 2018 running macOS Catalina 10.15.1) to control the server and to control the client. I am not using any trackpad, mouse or other kind of pointing device to control the client directly.

This leads me to my first question, which you will find at the end of this comment.

On methodology of testing

Like I mentioned in the beginning of this comment, I changed the host settings of each of the computers during this test with Barrel running the whole time and without restarting Barrel at any point nor sleeping or restarting any of the two computers during testing. This is a weakness of my testing that I chose to accept in order to keep the amount of information in this already quite lengthy comment down to an amount that I consider reasonable.

Now that I have commented extensively on everything surrounding my initial testing, it is possible to do more tests with conditions like stopping Barrel between each change of host settings and starting Barrel again after making those changes, and sleeping each of the computers between changes. The results for each of those groups of tests (each consisting of the four possible configurations of scroll directions along with whatever other kind of things like those things that I mentioned just now) can then be posted in separate comments following the format of the initial tests I performed.

On difference in observed behavior resulting from "interference" from other software

I mentioned at the beginning of this comment that normally I use a piece of software named Scroll Reverser that makes it possible to customize scroll behavior beyond the options included in macOS itself.

This leads me to another question, also written at the end of this comment.

Questions

@technovangelist First question. When you speak of up/down becoming reversed, are you using the trackpad of the server the whole time or are you switching between using the trackpad of the server and another pointing device connected to either the server or the client?

@technovangelist Secondary to the question above, are you the only person using these two computers or are you sharing them with anyone else that might change the settings for the scroll direction because they have an opposite preference?

@technovangelist Furthermore to the above, are you always using the computer that is running Barrel server alongside the one that is running Barrel client when you use the computer running Barrel client? Or do you sometimes use the computer running as Barrel client alone without the computer running as Barrel server? (Note that this question is similar to, but different from, the first question.)

@technovangelist Another question. About other pieces of software, like Scroll Reverser that I mentioned, do you use any software like that on either the client or the server?

Please respond to these questions individually and quoting each of the questions that you are responding to, as doing so makes it easy to see which of these several questions you are responding to at each time.

I intend to delay posting any further results from testing until these questions are answered, so that I don't drown out these questions with more comments. I hope that you agree that this is the most reasonable in order to keep the comments tidy.

@ctsrc commented on GitHub (Nov 9, 2019): I normally use an external mouse when seated at my desk where I use two computers with Barrier, but I did some testing with the trackpad. Server: MacBook Air 2018 running macOS Catalina 10.15.1 Client: Running macOS High Sierra 10.13.6 Barrier version: 2.3.2 with 7 additional commits from master (07a1c31, current HEAD of master) and a few commits of my own on top of that (https://github.com/ctsrc/barrier/tree/ctsrc-2019-11-08). My own commits in the version of Barrier that I run are unrelated to the issue at hand. Normally I also use a piece of software named [Scroll Reverser](https://pilotmoon.com/scrollreverser/) to allow the trackpad and the external mouse to have opposite scroll direction of one another. During testing I disabled (exited) this software, so as to match the setup that one would normally use. macOS has configurable scroll direction. Scroll direction is configured on macOS as either *natural* or not. In the macOS help docs they describe the "Scroll direction: Natural" option as: > Select this option to move the contents of a window in the same direction as your fingers. Below I test and report results for the four different possible combinations of scroll directions between server host and client host. All tests were performed by changing the host settings for scroll direction on each of the two computers without restarting Barrier. I comment on this at the end of this comment. This first group of tests will be referred to as "test group A". ## A1) "Scroll direction: Natural" option enabled on both hosts <dl> <dt>Server host</dt> <dd><ul><li>[x] Scroll direction: Natural</li></ul></dd> <dt>Client host</dt> <dd><ul><li>[x] Scroll direction: Natural</li></ul></dd> </dl> <table> <tr><th>Content tracks finger movement?</th><th>Vertically</th><th>Horizontally</th></tr> <tr><th align=left>Server</th><td>Yes</td><td>Yes</td></tr> <tr><th align=left>Client</th><td>Yes</td><td>No!</td></tr> <tr><th align=left>According to expectations?</th><td>Yes. Same direction.</td><td>No! Opposite direction.</td></tr> </table> **Result**: Bad. Observed horizontal scroll direction on client is opposite to that of server. In this situation we would expect both server and client to have the same scrolling directions (here: "natural") in both the horizontal and the vertical direction. ## A2) "Scroll direction: Natural" option disabled on both hosts <dl> <dt>Server host</dt> <dd><ul><li>[ ] Scroll direction: Natural</li></ul></dd> <dt>Client host</dt> <dd><ul><li>[ ] Scroll direction: Natural</li></ul></dd> </dl> <table> <tr><th>Content tracks finger movement?</th><th>Vertically</th><th>Horizontally</th></tr> <tr><th align=left>Server</th><td>No</td><td>No</td></tr> <tr><th align=left>Client</th><td>No</td><td>Yes!</td></tr> <tr><th align=left>According to expectations?</th><td>Yes. Same direction.</td><td>No! Opposite direction.</td></tr> </table> **Result**: Bad. Observed horizontal scroll direction on client is opposite to that of server. In this situation we would expect both server and client to have the same scrolling directions (here: inverse of "natural") in both the horizontal and the vertical direction. ## A3) "Scroll direction: Natural" option enabled on server host, disabled on client host <dl> <dt>Server host</dt> <dd><ul><li>[x] Scroll direction: Natural</li></ul></dd> <dt>Client host</dt> <dd><ul><li>[ ] Scroll direction: Natural</li></ul></dd> </dl> <table> <tr><th>Content tracks finger movement?</th><th>Vertically</th><th>Horizontally</th></tr> <tr><th align=left>Server</th><td>Yes</td><td>Yes</td></tr> <tr><th align=left>Client</th><td>Yes</td><td>No</td></tr> <tr><th align=left>According to expectations?</th><td>Maybe Y/N. Same direction.</td><td>Maybe N/Y. Opposite direction.</td></tr> </table> **Comment**: In this situation, where settings on server and on client are opposite of one-another, it is not obvious what should be the expected behavior – different people might have different opinions or expectations for this situation. However, we can all agree that in this situation either both horizontal and vertical direction of the client should match that of the server, or both should be opposite. **Result**: Bad. In this situation, either both horizontal and vertical direction should be opposite to that of server on the client (that is: server "natural", client inverse of "natural"), or both should be the same as that of server (that is: server "natural", client "natural"), or both should be the same as that of client (that is: server inverse of "natural", client inverse of "natural"). Instead, vertical scroll direction is the same on both but horizontal is opposite. ## A4) "Scroll direction: Natural" option disabled on server host, enabled on client host <dl> <dt>Server host</dt> <dd><ul><li>[ ] Scroll direction: Natural</li></ul></dd> <dt>Client host</dt> <dd><ul><li>[x] Scroll direction: Natural</li></ul></dd> </dl> <table> <tr><th>Content tracks finger movement?</th><th>Vertically</th><th>Horizontally</th></tr> <tr><th align=left>Server</th><td>No</td><td>No</td></tr> <tr><th align=left>Client</th><td>No</td><td>Yes</td></tr> <tr><th align=left>According to expectations?</th><td>Maybe Y/N. Same direction.</td><td>Maybe N/Y. Opposite direction.</td></tr> </table> **Comment**: In this situation, as with the situation right above this one (situation A3), where settings on server and on client are opposite of one-another, it is not obvious what should be the expected behavior – different people might have different opinions or expectations for this situation. However, just as with the aforementioned situation, we can all agree that in this situation either both horizontal and vertical direction of the client should match that of the server, or both should be opposite. **Result**: Bad. In this situation, as with the one above (situation A3), either both horizontal and vertical direction should be opposite to that of server on the client (that is: server inverse of "natural", client "natural"), or both should be the same as that of server (that is: server inverse of "natural", client inverse of "natural"), or both should be the same as that of client (that is: server "natural", client "natural"). Instead, vertical scroll direction is the same on both but horizontal is opposite. ## Discussion of observations In all of the four cases I observed the following: * Observed vertical scroll direction always matches the setting of the server host on both server and client, regardless of setting on the client host. * Observed horizontal scroll direction is always opposite on the client to the setting of the server host, regardless of setting on the client host. ### On what is meant by observed scroll direction When I speak of observed scroll direction here, I am speaking strictly of using the trackpad on the server host (the MacBook Air 2018 running macOS Catalina 10.15.1) to control the server and to control the client. I am not using any trackpad, mouse or other kind of pointing device to control the client directly. This leads me to my first question, which you will find at the end of this comment. ### On methodology of testing Like I mentioned in the beginning of this comment, I changed the host settings of each of the computers during this test with Barrel running the whole time and without restarting Barrel at any point nor sleeping or restarting any of the two computers during testing. This is a weakness of my testing that I chose to accept in order to keep the amount of information in this already quite lengthy comment down to an amount that I consider reasonable. Now that I have commented extensively on everything surrounding my initial testing, it is possible to do more tests with conditions like stopping Barrel between each change of host settings and starting Barrel again after making those changes, and sleeping each of the computers between changes. The results for each of those groups of tests (each consisting of the four possible configurations of scroll directions along with whatever other kind of things like those things that I mentioned just now) can then be posted in separate comments following the format of the initial tests I performed. ### On difference in observed behavior resulting from "interference" from other software I mentioned at the beginning of this comment that normally I use a piece of software named Scroll Reverser that makes it possible to customize scroll behavior beyond the options included in macOS itself. This leads me to another question, also written at the end of this comment. ## Questions @technovangelist First question. When you speak of up/down becoming reversed, are you using the trackpad of the server the whole time or are you switching between using the trackpad of the server and another pointing device connected to either the server or the client? @technovangelist Secondary to the question above, are you the only person using these two computers or are you sharing them with anyone else that might change the settings for the scroll direction because they have an opposite preference? @technovangelist Furthermore to the above, are you always using the computer that is running Barrel server alongside the one that is running Barrel client when you use the computer running Barrel client? Or do you sometimes use the computer running as Barrel client alone without the computer running as Barrel server? (Note that this question is similar to, but different from, the first question.) @technovangelist Another question. About other pieces of software, like Scroll Reverser that I mentioned, do you use any software like that on either the client or the server? Please respond to these questions individually and quoting each of the questions that you are responding to, as doing so makes it easy to see which of these several questions you are responding to at each time. I intend to delay posting any further results from testing until these questions are answered, so that I don't drown out these questions with more comments. I hope that you agree that this is the most reasonable in order to keep the comments tidy.

gitea-mirror commented

2026-05-05 06:10:43 -06:00

Author

Owner

@alepape commented on GitHub (May 25, 2020):

Hi
2 macs - both on Catalina
v2.3.2

Same issue on the horizontal scroll, and because it might be linked, I wanted to highlight that scroll acceleration is off. Normal on server, but too much on client, which I assume is because the device input is taken too high in the OS stack (after preferences, after acceleration, etc.) therefore adding acceleration twice.

So maybe so the solution would be to take the device input one level down (closer to the USB input). Not sure it's possible as it's classic issue with virtual KVMs (very similar experience on Synergy back in the days), but IIRC, ShareMouse did a better job.

NOTE: Good work to all devs working on this - I'm new to Barrier but really pleased!!!

@alepape commented on GitHub (May 25, 2020): Hi 2 macs - both on Catalina v2.3.2 Same issue on the horizontal scroll, and because it might be linked, I wanted to highlight that scroll acceleration is off. Normal on server, but too much on client, which I assume is because the device input is taken too high in the OS stack (after preferences, after acceleration, etc.) therefore adding acceleration twice. So maybe so the solution would be to take the device input one level down (closer to the USB input). Not sure it's possible as it's classic issue with virtual KVMs (very similar experience on Synergy back in the days), but IIRC, ShareMouse did a better job. NOTE: Good work to all devs working on this - I'm new to Barrier but really pleased!!!

gitea-mirror commented

2026-05-05 06:10:46 -06:00

Author

Owner

@halter73 commented on GitHub (Jun 5, 2020):

I have a Windows 10 server and macOS Catalina client. When working on the mac, I prefer natural scrolling for the trackpad and normal scrolling for the mouse. There's no built-in way on macOS to configure this, so I use BetterTouchTool to make this work. There are other apps like Scroll Reverser that do the same thing.

The problem I have is when I use barrier and try to scroll on macOS, it effectively undoes what BetterTouchTool is doing and gives me natural scrolling with my normal mouse which I don't want.

For now, disabling BetterTouchTool's mouse scroll reversing when using Synergy fixes the issue. The problem is I have to remember to reenable the mouse scroll reversing when I'm using a mouse connected directly to the mac.

I'd prefer if there was just an option in barrier to configure whether or not it reverses scroll direction on specific clients. I get my situation is a little unique, but I think this kind of option would fix a lot of these similar issues.

@halter73 commented on GitHub (Jun 5, 2020): I have a Windows 10 server and macOS Catalina client. When working on the mac, I prefer natural scrolling for the trackpad and normal scrolling for the mouse. There's no built-in way on macOS to configure this, so I use BetterTouchTool to make this work. There are other apps like Scroll Reverser that do the same thing. The problem I have is when I use barrier and try to scroll on macOS, it effectively undoes what BetterTouchTool is doing and gives me natural scrolling with my normal mouse which I don't want. For now, disabling BetterTouchTool's mouse scroll reversing when using Synergy fixes the issue. The problem is I have to remember to reenable the mouse scroll reversing when I'm using a mouse connected directly to the mac. I'd prefer if there was just an option in barrier to configure whether or not it reverses scroll direction on specific clients. I get my situation is a little unique, but I think this kind of option would fix a lot of these similar issues.

gitea-mirror commented

2026-05-05 06:10:48 -06:00

Author

Owner

@prediscover commented on GitHub (Dec 7, 2020):

I have a Windows 10 server and macOS Catalina client. When working on the mac, I prefer natural scrolling for the trackpad and normal scrolling for the mouse. There's no built-in way on macOS to configure this, so I use BetterTouchTool to make this work. There are other apps like Scroll Reverser that do the same thing.

The problem I have is when I use barrier and try to scroll on macOS, it effectively undoes what BetterTouchTool is doing and gives me natural scrolling with my normal mouse which I don't want.

For now, disabling BetterTouchTool's mouse scroll reversing when using Synergy fixes the issue. The problem is I have to remember to reenable the mouse scroll reversing when I'm using a mouse connected directly to the mac.

I'd prefer if there was just an option in barrier to configure whether or not it reverses scroll direction on specific clients. I get my situation is a little unique, but I think this kind of option would fix a lot of these similar issues.

I have the same situation as you. W10 server, macOS Catalina client. Instead of BetterTouchTool though, I use Mos (which does the same thing). It does have a whitelist section but it doesn't affect barrier. I think Barrier is sending scroll events to the client in a different way not captured by BetterTouchTool/Mos/Scroll Reverser.

@prediscover commented on GitHub (Dec 7, 2020): > > > I have a Windows 10 server and macOS Catalina client. When working on the mac, I prefer natural scrolling for the trackpad and normal scrolling for the mouse. There's no built-in way on macOS to configure this, so I use BetterTouchTool to make this work. There are other apps like Scroll Reverser that do the same thing. > > The problem I have is when I use barrier and try to scroll on macOS, it effectively undoes what BetterTouchTool is doing and gives me natural scrolling with my normal mouse which I don't want. > > For now, disabling BetterTouchTool's mouse scroll reversing when using Synergy fixes the issue. The problem is I have to remember to reenable the mouse scroll reversing when I'm using a mouse connected directly to the mac. > > I'd prefer if there was just an option in barrier to configure whether or not it reverses scroll direction on specific clients. I get my situation is a little unique, but I think this kind of option would fix a lot of these similar issues. I have the same situation as you. W10 server, macOS Catalina client. Instead of BetterTouchTool though, I use Mos (which does the same thing). It does have a whitelist section but it doesn't affect barrier. I think Barrier is sending scroll events to the client in a different way not captured by BetterTouchTool/Mos/Scroll Reverser.

gitea-mirror commented

2026-05-05 06:10:50 -06:00

Author

Owner

@warrendt commented on GitHub (Jan 6, 2021):

I have a similar issue.
But I am using a MacOS 11 (Big Bur) Server with a Windows 10 Client.
The horizontal scrolling is inverted, everything else is fine.

But on the plus side, at least the scrolling works unlike Synergy which is a million years away from fixing anything :(

@warrendt commented on GitHub (Jan 6, 2021): I have a similar issue. But I am using a MacOS 11 (Big Bur) Server with a Windows 10 Client. The horizontal scrolling is inverted, everything else is fine. But on the plus side, at least the scrolling works unlike Synergy which is a million years away from fixing anything :(

gitea-mirror commented

2026-05-05 06:10:51 -06:00

Author

Owner

@jaykaplon commented on GitHub (Feb 15, 2021):

Having the same general issue here with macOS Catalina on a MacBook with am external trackpad (as well as the unused built-in trackpad) as a server going to macOS Catalina on a Mac mini that has no display, no mouse, no keyboard. The Scroll Natural Direction is checked on the server MacBook and testing on the Mac mini it doesn't seem to matter as I check and uncheck Scroll Natural Direction on the Mac mini. (To even see the option to changing natural direction I have to plug in a mouse that I don't use to just make the control panel show options instead of saying that there is no mouse!) To make this all more complex to troubleshoot, the display of the Mac mini is actual a observe-only Screen Share session from an iMac running macOS High Sierra. Changing the natural scroll option on either of the iMac or Mac mini do not solve the issue. Vertical scrolling works correctly in the natural way (push up stuff goes up) and horizontal scrolling is reversed (push left stuff goes right) no matter what I do. (Other than if I turn off natural direction on the Trackpad control panel on the server MacBook but then vertical scrolling is unnatural and horizontal scrolling is natural. No mix gets both working the same direction.)

I support the above "I'd prefer if there was just an option in barrier to configure whether or not it reverses scroll direction on specific clients" but that setting needs to be two settings of "Reverse Vertical Scroll Direction" as well as "Reverse Horizontal Scroll Direction" as two separate checkboxes. One combined control will just flip which axis has the issue!

This really does not sound like something that code is going to fix because users may want trackpads and mice to work differently and there are many layers in there of what is 'right' or not. A simple pair of checkboxes solves the whole thing!

@jaykaplon commented on GitHub (Feb 15, 2021): Having the same general issue here with macOS Catalina on a MacBook with am external trackpad (as well as the unused built-in trackpad) as a server going to macOS Catalina on a Mac mini that has no display, no mouse, no keyboard. The Scroll Natural Direction is checked on the server MacBook and testing on the Mac mini it doesn't seem to matter as I check and uncheck Scroll Natural Direction on the Mac mini. (To even see the option to changing natural direction I have to plug in a mouse that I don't use to just make the control panel show options instead of saying that there is no mouse!) To make this all more complex to troubleshoot, the display of the Mac mini is actual a observe-only Screen Share session from an iMac running macOS High Sierra. Changing the natural scroll option on either of the iMac or Mac mini do not solve the issue. Vertical scrolling works correctly in the natural way (push up stuff goes up) and horizontal scrolling is reversed (push left stuff goes right) no matter what I do. (Other than if I turn off natural direction on the Trackpad control panel on the server MacBook but then vertical scrolling is unnatural and horizontal scrolling is natural. No mix gets both working the same direction.) I support the above "I'd prefer if there was just an option in barrier to configure whether or not it reverses scroll direction on specific clients" but that setting **needs to be two settings** of "Reverse Vertical Scroll Direction" _as well as_ "Reverse Horizontal Scroll Direction" as _two separate checkboxes_. One combined control will just flip which axis has the issue! This really does not sound like something that code is going to fix because users may want trackpads and mice to work differently and there are many layers in there of what is 'right' or not. A simple pair of checkboxes solves the whole thing!

gitea-mirror commented

2026-05-05 06:10:54 -06:00

Author

Owner

@jkleckner commented on GitHub (May 14, 2021):

Could the negative signs for xScroll in OSXScreen.mm be the cause?
If so, I suppose it could be parameterized.

Thoughts @ctsrc or @technovangelist ?

For example:

fc045fc793/src/lib/platform/OSXScreen.mm (L678-L681)

fc045fc793/src/lib/platform/OSXScreen.mm (L1031-L1034)

@jkleckner commented on GitHub (May 14, 2021): Could the negative signs for xScroll in `OSXScreen.mm` be the cause? If so, I suppose it could be parameterized. Thoughts @ctsrc or @technovangelist ? For example: https://github.com/debauchee/barrier/blob/fc045fc79326cef966405b1cc578e8f062ae5294/src/lib/platform/OSXScreen.mm#L678-L681 https://github.com/debauchee/barrier/blob/fc045fc79326cef966405b1cc578e8f062ae5294/src/lib/platform/OSXScreen.mm#L1031-L1034

gitea-mirror commented

2026-05-05 06:10:55 -06:00

Author

Owner

@jkleckner commented on GitHub (Jun 3, 2021):

I managed to get a build (I don't develop Mac Apps) that removed those two minus signs.
When I run it as the client application, the horizontal scrolling is no longer reversed.

@jkleckner commented on GitHub (Jun 3, 2021): I managed to get a build (I don't develop Mac Apps) that removed those two minus signs. When I run it as the client application, the horizontal scrolling is no longer reversed.

gitea-mirror commented

2026-05-05 06:10:57 -06:00

Author

Owner

@warrendt commented on GitHub (Jun 3, 2021):

Could the negative signs for xScroll in OSXScreen.mm be the cause?
If so, I suppose it could be parameterized.

Thoughts @ctsrc or @technovangelist ?

For example:

fc045fc793/src/lib/platform/OSXScreen.mm (L678-L681)

fc045fc793/src/lib/platform/OSXScreen.mm (L1031-L1034)

Any ideas where this would be on the windows side ? I cannot find it anywhere

@warrendt commented on GitHub (Jun 3, 2021): > Could the negative signs for xScroll in `OSXScreen.mm` be the cause? > If so, I suppose it could be parameterized. > > Thoughts @ctsrc or @technovangelist ? > > For example: > > https://github.com/debauchee/barrier/blob/fc045fc79326cef966405b1cc578e8f062ae5294/src/lib/platform/OSXScreen.mm#L678-L681 > > https://github.com/debauchee/barrier/blob/fc045fc79326cef966405b1cc578e8f062ae5294/src/lib/platform/OSXScreen.mm#L1031-L1034 Any ideas where this would be on the windows side ? I cannot find it anywhere

gitea-mirror commented

2026-05-05 06:11:01 -06:00

Author

Owner

@jkleckner commented on GitHub (Jun 5, 2021):

@warrendt Sorry, I don't. I took a look at the options configuration and it is nearly impossible to figure out how to add an options for this...

@jkleckner commented on GitHub (Jun 5, 2021): @warrendt Sorry, I don't. I took a look at the options configuration and it is nearly impossible to figure out how to add an options for this...

gitea-mirror commented

2026-05-05 06:11:05 -06:00

Author

Owner

@ElhemEnohpi commented on GitHub (Jun 6, 2021):

@jkleckner would you describe how you built it? Or maybe upload your build somewhere?

I started using Barrier a few days ago and found this problem, horizontal scrolling with two fingers on the Mac trackpad is reversed on the remote machine.

I downloaded a zip of the master and tried to build it with sh -x ./clean_build.sh (I have qt5 installed with Homebrew), but I'm running into errors about missing gmock etc.

@ElhemEnohpi commented on GitHub (Jun 6, 2021): @jkleckner would you describe how you built it? Or maybe upload your build somewhere? I started using Barrier a few days ago and found this problem, horizontal scrolling with two fingers on the Mac trackpad is reversed on the remote machine. I downloaded a zip of the master and tried to build it with `sh -x ./clean_build.sh` (I have qt5 installed with Homebrew), but I'm running into errors about missing gmock etc.

gitea-mirror commented

2026-05-05 06:11:08 -06:00

Author

Owner

@jkleckner commented on GitHub (Jun 7, 2021):

@ElhemEnohpi I did an uninstall of qt and reinstall of qt@5 from a git clone of the repo and with an up to date brew.

brew uninstall qt
brew install qt@5
brew reinstall qt@5
brew link qt@5
./clean_build.sh

I'm using Catalina 10.15.7 (19H1217).

git diff:

diff --git a/osx_environment.sh b/osx_environment.sh
old mode 100644
new mode 100755
diff --git a/src/lib/platform/OSXScreen.mm b/src/lib/platform/OSXScreen.mm
index 2b4594ff..1be6edf1 100644
--- a/src/lib/platform/OSXScreen.mm
+++ b/src/lib/platform/OSXScreen.mm
@@ -675,10 +675,17 @@ OSXScreen::fakeMouseWheel(SInt32 xDelta, SInt32 yDelta) const
 	if (xDelta != 0 || yDelta != 0) {
 		// create a scroll event, post it and release it.  not sure if kCGScrollEventUnitLine
 		// is the right choice here over kCGScrollEventUnitPixel
+		/*
+		 * wip experiment with not multiplying xDelta by -1
 		CGEventRef scrollEvent = CGEventCreateScrollWheelEvent(
 			NULL, kCGScrollEventUnitLine, 2,
 			mapScrollWheelFromBarrier(yDelta),
 			-mapScrollWheelFromBarrier(xDelta));
+		 */
+		CGEventRef scrollEvent = CGEventCreateScrollWheelEvent(
+			NULL, kCGScrollEventUnitLine, 2,
+			mapScrollWheelFromBarrier(yDelta),
+			mapScrollWheelFromBarrier(xDelta));
 		
         // Fix for sticky keys
         CGEventFlags modifiers = m_keyState->getModifierStateAsOSXFlags();
@@ -1029,8 +1036,14 @@ OSXScreen::handleSystemEvent(const Event& event, void*)
 			}
 
 			if (xScroll != 0 || yScroll != 0) {
+			    /*
+			     *
 				onMouseWheel(-mapScrollWheelToBarrier(xScroll),
 								mapScrollWheelToBarrier(yScroll));
+				* wip experiment with not multiplying xDelta by -1
+			     */
+				onMouseWheel(mapScrollWheelToBarrier(xScroll),
+								mapScrollWheelToBarrier(yScroll));
 			}
 		}
 		}

@jkleckner commented on GitHub (Jun 7, 2021): @ElhemEnohpi I did an uninstall of `qt` and reinstall of `qt@5` from a git clone of the repo and with an up to date `brew`. ``` brew uninstall qt brew install qt@5 brew reinstall qt@5 brew link qt@5 ./clean_build.sh ``` I'm using Catalina 10.15.7 (19H1217). git diff: ``` diff --git a/osx_environment.sh b/osx_environment.sh old mode 100644 new mode 100755 diff --git a/src/lib/platform/OSXScreen.mm b/src/lib/platform/OSXScreen.mm index 2b4594ff..1be6edf1 100644 --- a/src/lib/platform/OSXScreen.mm +++ b/src/lib/platform/OSXScreen.mm @@ -675,10 +675,17 @@ OSXScreen::fakeMouseWheel(SInt32 xDelta, SInt32 yDelta) const if (xDelta != 0 || yDelta != 0) { // create a scroll event, post it and release it. not sure if kCGScrollEventUnitLine // is the right choice here over kCGScrollEventUnitPixel + /* + * wip experiment with not multiplying xDelta by -1 CGEventRef scrollEvent = CGEventCreateScrollWheelEvent( NULL, kCGScrollEventUnitLine, 2, mapScrollWheelFromBarrier(yDelta), -mapScrollWheelFromBarrier(xDelta)); + */ + CGEventRef scrollEvent = CGEventCreateScrollWheelEvent( + NULL, kCGScrollEventUnitLine, 2, + mapScrollWheelFromBarrier(yDelta), + mapScrollWheelFromBarrier(xDelta)); // Fix for sticky keys CGEventFlags modifiers = m_keyState->getModifierStateAsOSXFlags(); @@ -1029,8 +1036,14 @@ OSXScreen::handleSystemEvent(const Event& event, void*) } if (xScroll != 0 || yScroll != 0) { + /* + * onMouseWheel(-mapScrollWheelToBarrier(xScroll), mapScrollWheelToBarrier(yScroll)); + * wip experiment with not multiplying xDelta by -1 + */ + onMouseWheel(mapScrollWheelToBarrier(xScroll), + mapScrollWheelToBarrier(yScroll)); } } } ```

gitea-mirror commented

2026-05-05 06:11:10 -06:00

Author

Owner

@jkleckner commented on GitHub (Jun 7, 2021):

Here is a temporary link to a zip of the built bundle:

https://drive.google.com/file/d/1FTSSJMskqfgqS9Yrr8g1Xkgtet_xof4a/view?usp=sharing

@jkleckner commented on GitHub (Jun 7, 2021): Here is a temporary link to a zip of the built bundle: - https://drive.google.com/file/d/1FTSSJMskqfgqS9Yrr8g1Xkgtet_xof4a/view?usp=sharing

gitea-mirror commented

2026-05-05 06:11:12 -06:00

Author

Owner

@ElhemEnohpi commented on GitHub (Jun 8, 2021):

I can't get it to build on Mojave, it's still complaining about gmock and gtest, not sure what I'm doing wrong... Anyway, I got your build and it works, thanks!

@ElhemEnohpi commented on GitHub (Jun 8, 2021): I can't get it to build on Mojave, it's still complaining about gmock and gtest, not sure what I'm doing wrong... Anyway, I got your build and it works, thanks!

gitea-mirror commented

2026-05-05 06:11:14 -06:00

Author

Owner

@kleurbleur commented on GitHub (Feb 7, 2022):

Here is a temporary link to a zip of the built bundle:

https://drive.google.com/file/d/1FTSSJMskqfgqS9Yrr8g1Xkgtet_xof4a/view?usp=sharing

Thanks for hosting and making the effort but your build is more than twice the size of the official one. Also it keeps nagging for accessibility rights where it already got it from the original client. Or at least, I can't select the new one in the System Prefs.

@kleurbleur commented on GitHub (Feb 7, 2022): > Here is a temporary link to a zip of the built bundle: > > * https://drive.google.com/file/d/1FTSSJMskqfgqS9Yrr8g1Xkgtet_xof4a/view?usp=sharing Thanks for hosting and making the effort but your build is more than twice the size of the official one. Also it keeps nagging for accessibility rights where it already got it from the original client. Or at least, I can't select the new one in the System Prefs.

gitea-mirror commented

2026-05-05 06:11:15 -06:00

Author

Owner

@ElhemEnohpi commented on GitHub (Feb 7, 2022):

@kleurbleur You can try removing it from the privacy / accessibility rights in System Prefs and re-adding the new one.

You might want to try to build it yourself. That one on Google Drive is 2.3.3, and there have been a lot of security updates since then - see the release notes. There are instructions in the Wiki for building it. I had to use an Intel machine, I couldn't get it to build on an Apple Silicon one. There are two build options, the "release" one is smaller than the "debug" one, so that's probably the explanation about the size.

@ElhemEnohpi commented on GitHub (Feb 7, 2022): @kleurbleur You can try removing it from the privacy / accessibility rights in System Prefs and re-adding the new one. You might want to try to build it yourself. That one on Google Drive is 2.3.3, and there have been a lot of security updates since then - see the release notes. There are instructions in the Wiki for building it. I had to use an Intel machine, I couldn't get it to build on an Apple Silicon one. There are two build options, the "release" one is smaller than the "debug" one, so that's probably the explanation about the size.

gitea-mirror commented

2026-05-05 06:11:17 -06:00

Author

Owner

@jkleckner commented on GitHub (Feb 7, 2022):

For the record, I no longer use barrier. For my purposes, teleport [1] is much more functional since I'm not using Windows.

[1] https://github.com/johndbritton/teleport

@jkleckner commented on GitHub (Feb 7, 2022): For the record, I no longer use barrier. For my purposes, teleport [1] is much more functional since I'm not using Windows. [1] https://github.com/johndbritton/teleport

gitea-mirror commented

2026-05-05 06:11:20 -06:00

Author

Owner

@bgbruno commented on GitHub (May 30, 2022):

@jkleckner thx for this tip for #macos

#barrier
• better transition between screens
• corners
• see fingerprint
• icon
• works with fullscreen video

#teleport
• correct mouse+touch directions - even in "macos dashboard" where #barrier collapse
• clipboard
• copy files
• start minimized

@bgbruno commented on GitHub (May 30, 2022): @jkleckner thx for this tip for #macos #barrier • better transition between screens • corners • see fingerprint • icon • works with fullscreen video #teleport • correct mouse+touch directions - even in "macos dashboard" where #barrier collapse • clipboard • copy files • start minimized

gitea-mirror commented

2026-05-05 06:11:22 -06:00

Author

Owner

@simonsnow commented on GitHub (Sep 28, 2022):

@warrendt check out the MSWindowsScreen.cpp file in src/lib/platform. I searched around for a few things and got results for 'wheel' and 'xDelta'. Hopefully that's a good starting point for you

@simonsnow commented on GitHub (Sep 28, 2022): @warrendt check out the MSWindowsScreen.cpp file in src/lib/platform. I searched around for a few things and got results for 'wheel' and 'xDelta'. Hopefully that's a good starting point for you

gitea-mirror commented

2026-05-05 06:11:25 -06:00

Author

Owner

@qwqcode commented on GitHub (Aug 26, 2024):

I used Barrier on macOS as the server side and modified the Server::onMouseWheel(SInt32 xDelta, SInt32 yDelta) function in src/lib/server/Server.cpp, changing m_active->mouseWheel(xDelta, yDelta); to m_active->mouseWheel(xDelta, -yDelta); (adding a negative sign to yDelta). After recompiling and running it, the issue was successfully resolved. macOS as the server and Linux as the client are working well together.

@qwqcode commented on GitHub (Aug 26, 2024): I used Barrier on macOS as the server side and modified the `Server::onMouseWheel(SInt32 xDelta, SInt32 yDelta)` function in `src/lib/server/Server.cpp`, changing `m_active->mouseWheel(xDelta, yDelta);` to `m_active->mouseWheel(xDelta, -yDelta);` (adding a negative sign to `yDelta`). After recompiling and running it, the issue was successfully resolved. macOS as the server and Linux as the client are working well together.

gitea-mirror referenced this issue

2026-05-05 06:27:43 -06:00

[GH-ISSUE #584] barrierd has compatibility issues with Windows 10. #459

Rows
Columns

[GH-ISSUE #476] scroll reverse on client #370

Operating Systems

Barrier Version

Steps to reproduce bug

A1) "Scroll direction: Natural" option enabled on both hosts

A2) "Scroll direction: Natural" option disabled on both hosts

A3) "Scroll direction: Natural" option enabled on server host, disabled on client host

A4) "Scroll direction: Natural" option disabled on server host, enabled on client host

Discussion of observations

On what is meant by observed scroll direction

On methodology of testing

On difference in observed behavior resulting from "interference" from other software

Questions