Allow to specify target xinerama number

[Patagonicus]

screenclone defaults to outputting on the first screen of the target display (or simply starting at (0,0)). The T530 can use two displays connected to the Nvidia card, but screenclone is unable to clone to the second screen. See also this bug for the relevant issue with the Intel driver patch.

[lmbrt]

this is affecting me as well... I managed to get two screens displaying by specifying an x offset here and running two copies of screenclone (one without this mod, one with) for each xinerama server.

void copy_if_damaged() {
if ( !damaged )
    return;

TC( XShmGetImage( src->dpy, src_window.win, src_image,
    src_screen->info.x_org, src_screen->info.y_org, AllPlanes) );
TC( XShmPutImage( dst->dpy, dst_window.win, dst_gc, dst_image, 0, 0, 1921, 0,
    dst_image->width, dst_image->height, False ) );
TC( XFlush( dst->dpy ) );

DBG( std::cout << "damaged" << std::endl );

damaged = false;
}

Now the issue is the cursor... I think screenclone is tracking twice now across both destination screens. Is there a way to restrict which region it tracks for the cursor?

[liskin]

Well, you may comment out mouse wiggling and turning the cursor off, that should be sufficient for the two screenclones not to fight for the cursor.

[lmbrt]

That doesn't seem to be working... I end up losing the cursor all together; It seems that detecting when the mouse of outside of the window and ignoring mouse events then would work... I'm having trouble putting that together. The dual clone works great except for the mouse issues.

[lmbrt]

I've put together some code that allows this to work. I had to ignore mouse events outside the screen being displayed. This works for my use case: Cloning both the primary and a virtual display to two screens on the nvidia display. I use this when my machine is docked and all my dock outputs are tied to the nvidia chip.

I added two parameters: -t (xoffset) and -u (yoffset) as options to pass into screen clone. They both default to 0.

I haven't done any testing other than my specific use case. I'm also not sure how to submit the patch file properly, so I've put the commit here:
lmbrt@6564ea9

Thanks for this great product!

[lmbrt]

found a few more issues in the code... new commit here lmbrt@a15bdd8

This also adds support for y_offset with the mouse cursor for those who have dual monitors stacked vertically. I'm a novice with xorg, but all the issues I've seen so far are related to the cursor getting out of sync. I've been using this version for a few hours without issue. Please let me know your findings.

[FortranFlo]

I am avoiding this issue by creating, for the virtual intel display, a mode that is large enough to encompass both monitors, then fixing the monitor setup using xrandr -d :8 . This seems to allow me to use two monitors, with all
freedom to configure on the fly. Screenclone simply copies the entire virtual display.

[liskin]

That's an interesting approach, although a lot of applications, including window managers, profit greatly from having accurate Xinerama information.

[amilsted]

I tried a slightly different approach: amilsted@d5f10d8

Gives me a nice three-headed setup!

[strayer]

Patched version of @amilsted works for me too. Horribly performance with compositing though, but I guess thats another problem.

[puetzk]

And I've forked yet another variation at https://github.com/puetzk/hybrid-screenclone (before finding/reading this thread). Since liskin's virtual_crtc patch now supports multiple virtual CRTC's, and nVidia provides Xinarama/XRandR info about the screens, I approached it as mapping each one to a different Xinerama screen in the source to one in the target. Each gets a separate image_replayer, but mouse replay is handled togethe so that the cursor show/hide can work.

So far the only glitch I've got is when the mouse cursor spans a physical edge. There are two glitches here:

1. If the edge is between the screens intel is physically driving and the ones which are virtual, it will only show on the screen the hot spot is on, and will not paint anything on the others.
2. If you are using multiple virtual outputs and the mouse cursor overlaps a, the destination Xserver will span the cursor image across the border according to its RandR layout, not the one of our virtual CRTCs. If they don't match, you can get rather odd results. But since you can make them match by just making sure both X server's RandR layouts match what's going on physically, I don't think this is very important.

I also added integration a -b flag for integration with bumblebee, that both gets it to start/stop the server appropriately, and automatically figures out which X display number it's using.