shadow outputs to different windows

[stdedos]

I am trying to xpra shadow my Ubuntu 16.04.3 working environment when I am using my laptop (Windows 10). Environment is 3 screens wide.

I'd prefer if this was 3 windows instead of one window of ~5k x 1080 p.
I fail to think how that'd be possible. I think that fakexinerama could be useful here, but I have no actual clue.

As a bonus: under the same Xpra process?

[Antoine Martin]

This should be done under the same xpra process by detecting the different outputs (through randr?) then creating a different root window model for each output. All the models would share the same underlying window, with a different offset for each.

@stdedos: can you please post the output of the script:

python ./xpra/scripts/gtk_info.py

And:

xrandr -q

So we can see how your outputs are detected by gtk (probably nothing), and X11 randr.

[stdedos]

Apologies for the delay. For future readers, I had to manually download sources, it's not included in the apt-get installation

Well, your intuition was ... halfway right. GTK sees one screen, but multiple monitors ;-)

[Antoine Martin]

I had to manually download sources, it's not included in the apt-get installation

Good catch, it will now be included: r18993.

GTK sees one screen, but multiple monitors

I've got the same result here, so I was able to hack together a patch:

• r18992: preparatory work fixing an ugly code dependency, which I had wanted to tackle for a long time anyway, just needed a good reason
• r18998: relatively small code for handling the offsets

It works!

Still TODO:

• option to revert to the old behaviour
• fix nvfbc capture (#1317) without copying extra buffers
• don't copy the pixel buffer just to adjust the offset! (add setters for x and y?)
• screenshot code: either paste the individual monitors onto one large black image, or directly access the large root window model directly as we did before
• handle screens disappearing, hard: will need to generate lost-window / new-window packets accordingly
• somewhat related: when shadowing itself, the clipboard loop is not detected (#1312)

[stdedos]

Kudos for the prototype :-D

• I'm not sure why would someone prefer the old behavior, but if you can do it - why not?

don't copy the pixel buffer just to adjust the offset! (add setters for x and y?)

Maybe you mean getters? :/

• I am not sure how you are actually implementing screenshot. It could be easier to shoot it at client and fetch the file. Or, if you are fetching the root window and then splitting it - then simply save it

[Antoine Martin]

Maybe you mean getters? :/

No.

It could be easier to shoot it at client and fetch the file. Or, if you are fetching the root window and then splitting it - then simply save it

I don't understand any of this, anyway:

Updates:

• r19003: make it possible to revert to single window mode with XPRA_SHADOW_MULTI_WINDOW=0 xpra shadow
• r19004: handle server resizing and monitors added or removed
• r19005: screenshot for X11 shadow servers using the "slow" GTK capture code

Still TODO:

• share nvfbc (#1317) capture instance for multiple window models (made easier by r19004) - will require moving graphics cards around for testing...
• avoiding pixel copying: only needed for X11 with xshm, so I may just special case it and be done with it - shadowing is already slow anyway
• clipboard loop not detected (#1312)
• macos and win32 shadow server support: #1805

[Antoine Martin]

The unnecessary pixel coping is fixed in r19080.
Only left to do for this release: re-check nvfbc.

[Antoine Martin]

Works well enough, will follow up in #1825 for nvfbc.

[stdedos]

Question: Should this still work now (r21873):
XPRA_SHADOW_MULTI_WINDOW=0 xpra shadow

I am trying to debug an issue that, separate windows point to the same spot on the leftmost monitor.
(I think I have mentioned it to a ticket somewhere, but I cannot seem to find the ticket now) --> mentioned here ​http://xpra.org/trac/ticket/2249#comment:1

[Antoine Martin]

Question: Should this still work now

Yes.