Cursor constrained when using multiple monitors with deadspace.
Opened this issue · 21 comments
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!
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.
I fixed it in my fork (I wouldn't recommend trying it) by opening a small window when conneted and listening to movements on that, moving the curser to the center of the window after each movment and adding the distance changed to the location. This has it's drawbacks such as when the remote display has a monitor that's smaller than the max height x2x thinks it's moving the mouse into the missing area. This isn't much of a problem though.
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.
The drawback is, that screen 1 now scrolls a bit up or down, when I move the mouse to the upper and lower border (even when I'm on the x2x-conneted screen).
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?
Same issue with my vertical screen. Upper left and lower left corners are not accessible.
@sisodiakaran same setup as me... exactly! :P I ended up just giving up on it :(
Seems like synergy is only one solution.
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 xinput test-xi2 in a terminal window and move the mouse, get the source code and think about it :-)
@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 -from?
I'm using x2x like that: ssh -Y lerax@celeste -t "x2x -west -noscale to :0.0
Since -noscale don't have the behavior I wants, I specified:
ssh -Y lerax@celeste -t "x2x -west -completeregionlow 768 -to :0.0"
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.
Trying out the following config, left to right:
1920x1080 -> 1200x1920 (vertical) -> 4096x2160 -> 1920x1200
The first is a laptop, the second and third are external monitors connected to the laptop.
The fourth is connected to a desktop.
Mouse and keyboard are plugged into the laptop.
The boundary between 3 and 4 is totally screwed up, and I can't get to the upper left corner of 4.
Trying noscale solved things somewhat, but caused other more serious issues.
My workaround was to move the mouse and keyboard from the laptop to the desktop.
And instead of ssh'ing from the laptop to the desktop to run x2x, ssh from the desktop to the laptop.
(Which was what I had previously, but I was hoping to do otherwise.)
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.