-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cursor constrained when using multiple monitors with deadspace. #5
Comments
I'm having the exact same problem. I'm using a notebook with an external display connected (resolution of notebook display is 1366x768, resolution of the external display is 1920x1080). When using x2x to connect to the xserver of another PC (resolution 1920x1080), there is an area in the lower right of the PCs display, where I'm not able to move the mouse to. If I disable the notebook display using xrandr (which leaves me with the notebooks external display of resolution 1920x1080 and the PCs display of resolution 1920x1080) and restart x2x, everything works fine. On my notebook I'm using Gentoo linux with x2x-1.27, and on the PC I'm using Arch linux with x2x-git 20130211-3 Any suggestions on how to fix this? |
It's due to how the cursor position is handled. It scales from the total width and hight of the local display to the w/h of remote, then the mouse is moved over the local display and get's to a point where a monitors of smaller height (or width depending on their layout) and the mouse cannot move any further on local leaving area's on remote that it cannot access. |
Plese fix this issue. As solution x2x may have new comand line argument with 3x3 matrix to transform mouse coordinates. |
Exactly the same problem. 3 screens on computer A, different sizes with dead-spaces. When using x2x to use computer B I can't access parts of computer B's screen due to those dead spaces. Any solutions yet? |
I ran into this exact problem and I worked around it by specifiying a virtual desktop (screen 1 is 1280x1024, screen 2 is 1920x1200, the virtual desktop is 3200x1200) this eleminates the dead area below screen 1 and as a consequence the dead space on the connected desktop. Another problem is that the mouse feels asymmetric on the remote screen (because the virtual desktop is 16:6 and the remote-screen is 16:9 and the mousemovements are scaled, as mytch444 pointed out). |
This issue still affects me. Are there any solutions available? |
@sisodiakaran same setup as me... exactly! :P I ended up just giving up on it :( |
Seems like synergy is only one solution. |
@akhilman same solution here. Just bought synergy... |
My setup looks like this: The "mouseless" screen is the rightmost screen With the recent commit 00a6a16 from @hamishcoleman I am now able to reach the full area on the rightmost screen (THANKS Hamish !) |
I even get this problem moving "North". It seems to constrain the mouse cursor on the remote to the limits of a similarly-sized area situated roughly in the middle of my dual monitor configuration. So if my left-hand monitor is shorter than the remote monitor and the right-hand monitor, I cannot access to top left hand corner of the remote screen. |
You could easily add a scale factor when the table is built. I believe the best direction is to add a command line option allowing to compute the cursor coordinates from relative mouse events using libxinput2, and then - in a second time and among other things - to use the screen size in mm (xrandr display it for mine) to keep the cursor speed constant ... This could also allow to get rid of the hidden window that need to be resurfaced (restarting ssh x2x) when (in gnome-shell) you maximize another window or trigger a drop down menu.. Try command |
If from-display is configured with multiple monitors and they have different resolution, few regions that don't belong to any monitor becomes dad space that mouse cannot move in. In the case, the dead spece becomes mapped to legal region of to-display. As consequence, user cannot move mouse into every region of to-display. Same problem has reported about 5 years ago[1]. This commit fixes the problem by let user specify complete rectangle region of from-display explicitly. If the region specified, x2x maps only the complete region to to-display. [1] dottedmag#5 Signed-off-by: SeongJae Park <sj38.park@gmail.com>
@bugdanov using -noscale fix partially my problem. It's indeed allow navigate on the previous deadspace, but now introduces new bugs since I use two monitors and it "sees" boths by navigating. Do you need provide some other flag like I'm using x2x like that: |
Since -noscale don't have the behavior I wants, I specified:
Now I have a uninnted side effect: My cursor when achieves the bottom go to the middle of screen. WHY? The second monitor is the lower bound coordinate restriction at 768. |
Running into the same problem too. 1920x1080 -> 1200x1920 (vertical) -> 4096x2160 -> 1920x1200 The first is a laptop, the second and third are external monitors connected to the laptop. My workaround was to move the mouse and keyboard from the laptop to the desktop. |
Yes, this is a known restriction of x2x design. |
Problem kinda solved by buying a bigger laptop... |
I had this problem, but solved it by making my main two monitors the same resolution. |
Solved by switching to barrier (Debian/Ubuntu package): https://github.com/debauchee/barrier |
Thanks @bernhardkaindl, I will add a pointer to the barrier package to the debian package description. |
Hello,
I have two computers that I connect with x2x. My mouse is plugged into computer A, and computer A has two monitors with differenht sizes. The X11 setup I have is smart enough to stop my mouse from entering the dead space caused by the different sizes. This creates a problem with x2x, though: when I move my mouse over to computer B's screen, there is an area of the monitor that I can't move my mouse to, and I think it's the same shape as the dead space on computer A.
I don't know how easy this is to fix. Is it possible to change x2x so that when the mouse on machine A is hidden, it doesn't let it leave the first screen?
Let me know if you want more details. If you give me a general idea of what needs to be changed, I might find some time to fiddle with the source myself, since I have the setup that triggers the bug.
Thanks for making x2x!
The text was updated successfully, but these errors were encountered: