expand a desktop

[totaam]

Taking advantage of #3320, make it possible to modify an existing "real" desktop session to add a new virtual output that we then shadow somewhere else, effectively expanding a desktop onto a remote output. Something like:

xpra expand :0,size=1920x1080 

Even better would be if we could do this from the client:

xpra expand ssh://host/0

And have the expanded area match that of the client's display. The client could run in full-screen mode from the start.

The are virtual adapters for most OSes: https://github.com/Xpra-org/xpra/issues/3320#issuecomment-996245905

[totaam]

The commit above adds a work in progress evdi capture codec, which requires these extra files to build on Fedora 34 which provides libevdi in fedora-multimedia, but no libevdi-devel:

$ more /usr/lib64/pkgconfig/evdi.pc 
prefix=/usr
libdir=${prefix}/lib64
includedir=${prefix}/include

Name: evdi
Description: Extensible Virtual Display Interface
Version: 1.10
Libs: -L${libdir} -levdi
Cflags: -I${includedir}

/usr/include/evdi_lib.h can just be copied from the evdi source.

It doesn't capture any pixel data and seems to hang my local X11 session for many seconds! Perhaps looking at what evdipp is doing would help? (their example does work - though not perfectly either..)

The evdi docs aren't very clear on the sequence of events needed to start capturing pixels.

Pre-requisite: modprobe evdi initial_device_count=2 as per Unable to add a VIRTUAL display to Xorg

[totaam]

Difficult to test when the latest release (many months ago) doesn't support the latest kernels.. https://github.com/displaylink-rpm/displaylink-rpm/releases

[totaam]

Using the glue commits above, here is the updated platform support.

• Debian and Ubuntu are all missing the evdi.pc pkgconfig file
• Debian Buster: evdi 1.6.0, too old: no amount of glue can fix that
• Debian Bullseye: evdi 1.9.0, OK
• Debian Bookworm: no evdi anywhere in the repositories! And somewhat hard to build from source..
• Ubuntu 20.04: evdi 1.9.1 OK
• Ubuntu 22.04: evdi 1.9.1 OK
• Fedora: no evdi packages in the repos
• Fedora 37: needed an updated Cython first 58ef3e049d1154c8cb8d0047de127a2b145a91e2

[totaam]

Still TODO:

• figure out why it hangs the X11 server for many seconds at a time!
• why can't we hot unplug the driver? (use xrandr to remove the provider first?)
• get the select.select mode to work somehow? (is this related to the hangs?)
• don't inherit from shadow mode, get closer to seamless mode since we should be using the damage rects
• use the damage rects (if we get them... maybe with the select mode?)
• sometimes it doesn't work at all and we never get pixel data, detect this with a timeout and bail out
• disable clipboard when the client and server are using the same display
• show the remote pointer
• more helpful error message when the kernel module is not loaded (especially when running remotely via ssh)
• too many problems with outdated Debian builds (now disabled): f9d33b23d0b867d7e2f7506ce0a7d217acb92695, d1b8a7c99b4bf5c9d24437b1c9a2f9dfe482d990

[normanr]

Did you figure out why it hangs the X11 server? When I tried it (over a year ago) I wondered if it might be that something in X11 is trying to callback into the application which is running with an X11 event loop (so causing a deadlock and eventually something times out).

[totaam]

@normanr perhaps, I just tried it now and have some new data points:

• the evdi virtual display was automatically added to my local Wayland desktop session rather than the X11 display I wanted to test it with
• there are no hangs this time (so perhaps you are correct and the problem comes from the X11 event loop) but the pointer is leaving a mess behind it and the screen updates are often slightly corrupted

I don't have time to look into this further, which is a shame because this looks almost usable and extremely useful.

[normanr]

fwiw, I tried this recently and also discovered that it hung less. The evdipp example app didn't hang at all; only the monitorsim app did, and even then it was for a "shorter" time (15s maybe).

Doing it manually (with xrandr, etc) caused the messy screen, but using the example & monitorsim apps didn't have that issue. The monitorsim app even showed the pointer (even though xpra did not).

Setup: debian testing with Xorg 21.1.7 with evdi 1.12, I had to change evdipp/CMakeLists.txt GIT_TAG to v1.11.0 to get the example apps to run correctly.

[normanr]

fwiw, I did the above testing with xpra shadow. I've now also tried xpra expand, which seems to hang slightly longer/worse (I had to compile & install the evdi codec library for xpra v4.4.5 to get it to work). Oddly hangs seem to be triggered more when the cursor transitions into-or-outof of the virtual screen. I did manage to get the pointer to display by commenting out the call to enable_cursor_events() (which makes evdi compose the cursor into the framebuffer).

[normanr]

So I came across https://github.com/pavlobu/deskreen/discussions/86, and ended up trying https://dri.freedesktop.org/docs/drm/gpu/vkms.html and, although I had to enable and compile the kernel module, once it was loaded X11 detected the display and it just worked flawlessly. No hangs, no weirdness, it just worked. Gnome display settings could position it, and change the display resolution.

update: I spoke too soon. My laptop with Intel graphs worked flawlessly, but my desktop with Nvidia graphics doesn't init the vkms device properly and x11/gnome can't change the display resolution :-(

[totaam]

For Wayland desktops, there's also RecordVirtual: Record a virtual area that will be represented as a virtual monitor.