For some time now, I’ve been using x2x to combine two X servers to one virtual workspace. It’s nice, because you can move your mouse off the display (say, your desktop machine) to the X server of another computer (in my use case: my laptop), and continue typing and clicking with your main mouse/keyboard. However, x2x gave me a few headaches, since the copypasting (middle mouse button) would not always work correctly between the two monitor setup you get.
However, I found out that synergy does the right thing when it comes to copypasting, so I switched to using synergy instead of x2x, and if you’re seeing the same problems with x2x, I can only recommend trying synergy. Most likely it should “just work” for you, too.
2 comments ↓
Thank you for this Tip.
Greeting 4k3nd0
Decent tip. I am attempting to do the same now. Here’s what I’ve seen:
x2x and synergy seem to use different algorithms for detecting mouse motion:
– x2x appears to hide the cursor, then maps each location of the local display to a location on the remote display, scaling the displays as necessary. This works well, even if they have different geometries, but fails when parts of the local display are not accessible to normal cursor movement.
– synergy appears to capture cursor motion by “fixing” the cursor into the centre of one of the the local displays’ screens/xinerama-monitors, then captures motions by seeing how far the local cursor moves from that centre fix point. Periodically (appears to be multiple times per second), it returns the local cursor to that point. This allows one to completely separate the geometries of the local display from the remote display. Inaccessible areas of the local display do not appear to affect the remote display.
The difference between the capture methods is important when the local display is a xinerama-based dual-head display with heterogeneous monitor resolutions. In my setup, I have a 1920×1200 monitor next to a 1280×1024 monitor. This means that my display is 3200×1200, with a 1280×176 strip below my smaller monitor that is not visible. in RHEL5, the cursor was allowed to travel into that bar. in RHEL6, it appears to be forbidden to enter that area, resulting in an inaccessible region.
With x2x, I have an inaccessible region on my remote display that corresponds directly to the local screen’s inaccessble area. Synergy does not have this limitation. (+1 point for synergy)
x2x uses less cpu and is less sluggish/jittery when tunnelled over ssh. (+1 point for x2x)
synergyc can use a lot of CPU (~75% on my system) when the synergy server is inaccessible. Likely, this can be circumvented using –no-restart? (+1 point for x2x)
My installed version of synergys seems to occasionally forget to hide the local cursor while doing motion capture. This causes really annoying flicker in the middle of the local display while using a remote display. (+1 point for x2x)
x2x does a mediocre job of clipboard synchronisation. synergy does better (+1 point for synergy).
Perhaps some of these points are important to you; perhaps they are not. Your mileage may vary wildly.
Leave a Comment