![]() This is also proven by using the Client's local keyboard and mouse on an identical machine which has the same keyboard shortcuts or mouse tools as the Server. ![]() There's still no solution available for this issue.ģ) Mission Control, by keyboard shortcut or mouse tools (like MagicPrefs), does not work. This can be proven by using the Client's local keyboard and mouse on an identical machine which has the same keyboard shortcuts as the Server. ![]() (You may search past Synergy related forums, like those on Google Boards, to verify that these two issues have been known and discussed for years!) The only solution that I've found, is to connect all Server and Client machines via wired ethernet and ethernet switch.Ģ) Keyboard shortcuts entered from the Server do not work reliably on the Client. The WiFi lag is also the reason for failed or delayed cut&paste between server and client. And all are connected via gigEthernet and ethernet switch.ġ) The lag over WiFi has been a known issue for years. Fyi, I use 2-3 identical iMacs, same high-end model hardware and software on all machines. After my first post on ("Synergy & Moom (MacOS)"), I read many posts made by other users regarding issues that I've been experiencing for years, and that are apparently still unresolved (smh). Hi, I've used Synergy for several years (5+), but am new to these newer forums. This would be potentially at the expense of higher update frequency. Haven't examined the source but one quick way to fix might be to limit the server to use the same update frequency regardless of mouse movement direction (making it look more like the example right/down movement example above). DEBUG2: recv mouse move 843,919īased on the above, it looks like the server is sending an increased frequency of updates in the left/up direction, causing the "drift" behavior. DEBUG2: readf: read 2 byte integer: 919 (0x397) On Windows client, mouse moves are "aligned" as single coordinate updates regardless of movement direction: Noticed that in the log, mouse movements to the left and up arrive in "bursts" of up to 8 coordinate updates, whereas right and down mouse movements are only one or two coordinate updates, viz. * Increased loglevel to DEBUG2 on server. * Disabling SSL on both machines has no effect. * Enabling "use relative mouse moves" on server has no effect on the drifting behavior. * This "up and to the left" drift occurs regardless of the client/server screen orientation in server settings. Simplest way to reproduce is to move pointer to Windows machine and then move the mouse in small circles - pointer drifts up and to the left. Problem still occurs with "official" 1.8.6 build (1.8.6-stable-2ab21aa, built Dec 12). Tl dr: seems like the server is sending more mouse updates in left and up directions. I haven't yet tried the 1.8.5 stable build, but may do that next. I'll search the forum to see if I can find anyone else with a suggestion. I imagine Sierra is doing something very different than what Yosemite was doing in the realm of the mouse. What I experience is when I go into the Ubuntu monitor and then move back the mouse shows up in the center of the built-in MacBook monitor. However, I have another issue which is regarding my desktop arrangement. I got around it by installing a tool provided by SteelSeries called ExactMouse, which disabled acceleration only for the SteelSeries devices. It had worked fine before I updated to Sierra with 1.8.4. I was seeing odd behavior where the mouse movement was both faster, and the mouse acceleration only seemed to be applied in the vertical up direction (hilariously frustrating). I have seen this too with the following setup:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |