Skip to content
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

Open
falsifian opened this issue Oct 2, 2011 · 21 comments
Open
Labels

Comments

@falsifian
Copy link

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!

@reissmann
Copy link

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?

@mytchel
Copy link

mytchel commented Dec 10, 2014

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.

@akhilman
Copy link

Plese fix this issue. As solution x2x may have new comand line argument with 3x3 matrix to transform mouse coordinates.

@hozza
Copy link

hozza commented Jun 5, 2015

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?

@inkeso
Copy link

inkeso commented Dec 19, 2015

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).

@fechnert
Copy link

fechnert commented Jun 3, 2016

This issue still affects me. Are there any solutions available?

@sisodiakaran
Copy link

Same issue with my vertical screen. Upper left and lower left corners are not accessible.

My workstation setup

@hozza
Copy link

hozza commented Jun 21, 2016

@sisodiakaran same setup as me... exactly! :P I ended up just giving up on it :(

@akhilman
Copy link

Seems like synergy is only one solution.

@fechnert
Copy link

fechnert commented Jul 3, 2016

@akhilman same solution here. Just bought synergy...

@bugdanov
Copy link

My setup looks like this:

images 6

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 !)

@VikOlliver
Copy link

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.

@luxigo
Copy link

luxigo commented Sep 1, 2016

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 :-)

sjp38 added a commit to sjp38/x2x that referenced this issue Sep 25, 2016
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>
@ryukinix
Copy link

@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

@ryukinix
Copy link

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:

bug

My cursor when achieves the bottom go to the middle of screen. WHY?

image

The second monitor is the lower bound coordinate restriction at 768.

@richfromm
Copy link

richfromm commented Jun 8, 2019

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.)

@dottedmag
Copy link
Owner

Yes, this is a known restriction of x2x design.

@VikOlliver
Copy link

Problem kinda solved by buying a bigger laptop...

@frohro
Copy link

frohro commented May 1, 2020

I had this problem, but solved it by making my main two monitors the same resolution.

@bernhardkaindl
Copy link

Solved by switching to barrier (Debian/Ubuntu package): https://github.com/debauchee/barrier

@barak
Copy link
Collaborator

barak commented Nov 6, 2022

Thanks @bernhardkaindl, I will add a pointer to the barrier package to the debian package description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests