Just another idea: Since the video approach is sooo slow, I've tried another approach. This one is suboptimal by design, but it is much faster than the recordMyDesktop variant. This one requires a VNC loopback session or other way of getting another session with its own background. (This is something that would be required for real screensharing anyway.) You can easily get it by apt install tigervnc-standalone-server tigervnc-viewer openbox (or similar command on non-Debian system), running vncpasswd (configure any password, you don't have to remember it), running tigervncserver and then running the viewer command mentioned it server's output.
There is my hack. It assumes that: * /tmp/out.bmp is a symlink to /dev/stdout. The reason is the same as with the video approach. * You have scrot installed in dom0. * You have feh installed in the target VM. * Your VNC loopback session has display :1. (You can change it.) * You want to pipe it to disp3. (You can change it.) The command to run in dom0: while true; do (scrot /tmp/out.bmp | qvm-run disp3 -p 'env DISPLAY=:1 feh --bg-center --no-fehbg -'); done It is suboptimal for many reasons: * It forks several processes in both dom0 and domU for each screenshot. * It opens a new RPC call for each frame. (Which causes previous unoptimality.) * All screenshots are saved in /tmp (internal behavior of feh). This probably matters less when /tmp is tmpfs, but still. * Works fully synchronously. Actual performance on my laptop was about 2 FPS (measured by my eyes), which is not great, but it works much better than the video. For some purposes, 2FPs might be useable. Not sure why this is better than the video, maybe it is due to missing compression and decompression, maybe it is due to missing buffering. How the performance can be improved: 1. Use a single pipe, don't open a new RPC call for each frame. (This might get tricky due to buffering. It might be important to verify that it works well even if the consumer is slower than producer.) 2. Use a single process as producer instead of looped scrot. 3. Use a single process as consumer instead of looped feh. Another idea is to use half-duplex VNC, but this might be also tricky. The goal is not to allow to pass any input from the untrusted VM to VNC server in dom0, maybe except information about potential congestion (i.e., situation when consumer is slower than producer). I am not sure if VNC is designed for that, but Wireshark capture of session with -ViewOnly on client-side looks still a bit chatty. There are many Authentication Response messages for some time (WTF?) and many Fence messages (hmm, probably synchronization). Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4a8bff52-744b-4233-b87a-ddebe23a52c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
