Re: [qubes-users] Re: Qubes OS screensharing
On Thursday, April 25, 2019 at 3:41:43 PM UTC-3, brend...@gmail.com wrote: > On Thursday, April 25, 2019 at 1:54:38 PM UTC-4, Fernando wrote: > > The fix from Marmarek worked for me as soon as it was released, but then > > after a few updates (I don't remember exactly when) it stopped working for > > me. > > > > Do you have any suggestions on where I can start looking to debug this > > issue? From what I see, no one else has reported problems. > > Is release repo up to date with the related changes from testing? > > I'm using testing and it worked on and off recently, but worked ok the last > two attempts. Hard to pin down, though, as I'm updating dom0 daily-ish. > > Just tried a few device attach/detach/attach/VM restart/VM start/attach of an > ISOstick with -testing updates and it seems to be working today... > > Brendan Thanks, Brendan. At least I know it's not just my local config. I'm not using testing repo since I need my work laptop to be quite stable, and I run weekly updates in dom0. That would explain why it consistently doesn't work for me. I guess I'll just have to wait for it to become stable. Nando. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9478ccd4-189e-420d-a00c-36e1af04f2a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
On Thursday, April 25, 2019 at 1:54:38 PM UTC-4, Fernando wrote: > The fix from Marmarek worked for me as soon as it was released, but then > after a few updates (I don't remember exactly when) it stopped working for me. > > Do you have any suggestions on where I can start looking to debug this issue? > From what I see, no one else has reported problems. Is release repo up to date with the related changes from testing? I'm using testing and it worked on and off recently, but worked ok the last two attempts. Hard to pin down, though, as I'm updating dom0 daily-ish. Just tried a few device attach/detach/attach/VM restart/VM start/attach of an ISOstick with -testing updates and it seems to be working today... Brendan -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fafde20d-d111-4ab2-bea6-ce605d3078f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
On Tuesday, December 11, 2018 at 2:00:56 PM UTC-3, Dave C wrote: > On Thursday, October 18, 2018 at 5:52:31 AM UTC-7, Vít Šesták wrote: > > Marmarek has identified the issue and fixed it: > > https://github.com/QubesOS/qubes-issues/issues/4351 > > > > I haven't been vocal on this thread in a while... but I appreciate the > comments from v6ak and the bugfix from Marmarek. > > I had a moment to update my blog post about screensharing in Qubes: > https://www.dave-cohen.com/blog/qubes-vnc-screenshare/, please check it out > if interested. I welcome any constructive feedback. > > Cheers, -Dave The fix from Marmarek worked for me as soon as it was released, but then after a few updates (I don't remember exactly when) it stopped working for me. Do you have any suggestions on where I can start looking to debug this issue? From what I see, no one else has reported problems. Thanks, Nando. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9542060b-6ba1-4b4c-9f25-bea9916bc70e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
On Thursday, October 18, 2018 at 5:52:31 AM UTC-7, Vít Šesták wrote: > Marmarek has identified the issue and fixed it: > https://github.com/QubesOS/qubes-issues/issues/4351 > I haven't been vocal on this thread in a while... but I appreciate the comments from v6ak and the bugfix from Marmarek. I had a moment to update my blog post about screensharing in Qubes: https://www.dave-cohen.com/blog/qubes-vnc-screenshare/, please check it out if interested. I welcome any constructive feedback. Cheers, -Dave -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/56a60b96-eb1d-4134-9673-708ee694af03%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
Marmarek has identified the issue and fixed it: https://github.com/QubesOS/qubes-issues/issues/4351 So if you are patient, you can just wait until you see it in current repository. (There will be likely Gihtub comment.) If you are eager, you can wait until it is in testing repository. (Again, we will probably see a Github comment.) If you are supereager, you can compile it yourself 😉 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4438d31f-d9df-448c-b4cd-f62baafb27e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/11/2018 04:03 PM, Vít Šesták wrote: > I am sorry for the monolog, but I have some further ideas and > findings. Hehe, I'm following your progress but I don't have currently the need of share my screen. I enjoy reading it and maybe I will test when I have some free time for spend on it :) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqAXpoACgkQFBMQ2OPt CKW+AQ/9HGkyV9vb/SupPzaxu/wDQQmDoCRlFMYqF5YMyLQzh721m0dOGIqyJiUS 0968aRoeLPAnj+kBXlTxeUIH7r6CGpkhsrFdoAZVLPX5iTZ/8T16p8kXE5wRKG0W POhYma3Wp8F0S9VOB8Duco+xyahpy8oB2jRFFuYDAhVG3v9NniOwzPwhgclJu0oo wj3dLDkCaBz19BCZHe7dhBnjoKxPXQW4j5NXi6dtNgcWNpSxNKDlpXMs2ovVSR2d M3lzctOzGel8fKRxQXAf3TFibOVmIF2V7bXqcGbhKfo3QY0YaC3tqjHf8HUVsh41 NkTRi7RGQbuYQ4DXMnVxLSzhaA7cF7lIa375vx7RSPXLmlvxPwaM5WlCDICYZauN u2w2l6GzDIyCUG4V7Ei1zuGYQLBHo5bFpOhjbc0hXoeHXCDDPgJIOKawiA43Gqbb SLWvika6Wbs4sTfYNsFZY1jBi1a8DvOOkI7wWrqu4uxX5iTRdnMJl6jIH13iChql yvuWbqgN7b8/mzNgsoEY8s4P1YDvAa4o7JLjPJqtaOoJzLhjtAidAPq6Cb9FwRYg KfyAdq5R4GNRAshYiZcsO/SC1r5g1DB+v0pf8Q71+dux6fkMgobyjljuO4eTv0wY MxhV7eyTBjKzbkneddB81DReQPGI/QFXxz09fwNe+HCitpv6pg8= =+c3d -END PGP SIGNATURE- -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2ad577b1-4cef-9b89-9c67-7d13b9d0302b%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
I am sorry for the monolog, but I have some further ideas and findings. I see two promising options to make screensharing great again: a. VM screensharing: It would share the screen of the current VM and nothing else. We need to get in-VM screenshots working for this. Or you can use a VNC loopback session with its drawbacks. b. Full screensharing. This requires to pipe screen contents from dom0 to a specific domU. Maybe we need to stream it to some window that cover everything while being ignored by qubes-gui. Technical findings: When considering the most common VMs in Qubes, none of those two variants currently works well. When I try to screenshot the main X11 of a PV domU, I get a solid white image. This is true for any screenscrapping technique I have tried. I am not sure what is the reason of white screenshot, but I've traced it a bit: * The color is not related to xsetroot call in /usr/bin/qubes-session (i.e., you can change it to some other color in a StandaloneVM and reboot it, but you will still get white screenshot). * It is not related to xorg.conf and/or the dummyqbs driver. First, changing “dummyqbs” to “dummy” does not help. Second, when I copy /etc/X11/xorg-qubes.conf to /etc/X11/xorg.conf run a second X11 session (as :1) and screenshot it (e.g., env DISPLAY=:1 scrot out.png && feh out.png), the screenshot works. (Maybe you will want to run something there to see it, e.g., env DISPLAY=:1 xterm&.) * It is not related to window manager. When i run a WM (Openbox) in standard Qubes session, it does not help. I believe it is also true vice versa. * It seems to be related to qubes-gui process. When I kill it, screenshots (and thus screensharing) starts working. But obviously, you cannot interact with the GUI. You can see it on a simple experiment. I've used two sessions of a DVM started by command qvm-run '$dispvm' bash. This creates some inconvenient Bash session (e.g., you cannot see prompts and error messages), but it is good enough to run few commands as follows: sudo apt install scrot # Install screenshoting app. Adjust this if you are not on Debian. xterm& # run some app that will be seen on screenshot # sudo killall qubes-gui # Run this in one VM only in order to see differences. ps aux | grep qubes-gui # See if it is killed (rm -f out.png && scrot out.png && cat out.png | qvm-run '$dispvm' 'feh -') 2>&1 # Look at the result. Since the VM might be incapable of showing some GUI, I start a new VM. You might need to adjust the commands or your environment a bit (e.g., install feh if not installed), but it should be trivial and obvious. I do not know why qubes-gui makes such difference. The source is at https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/gui-agent/vmside.c , but I still don't know why it behaves this way. There are two occurrences of “white” (case-insensitive), but I don't understand the code much. But I have found some interesting part: “/* pretend that GUI agent is window manager */”. So, it tries to look like some window manager. This is strange, as Openbox does not complain that some WM is already running when I run it within a Qubes session. But I don't understand X11 details much, which is probably the reason I don't understand the linked source code much. No, I don't have a solution. I have few intermediate results that might be useful for someone to find something more. 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/626cd5a7-97b0-497b-8d85-2eb7df9e9402%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. 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.
Re: [qubes-users] Re: Qubes OS screensharing
I've implemented my approach of screensharing. It pipes content scrapped from dom0 to a VM. I don't call it a success, because the FPS is terribly low. But maybe someone can try to get it even further. Recording: * VLC and ffmpeg could be good choices (with probably many options for adjusting it for your needs), but they aren't available in Fedora unless you use some third-party repository, which is not what I wanted. * recordMyDesktop works with some hacks and config, but its FPS is terribly low (at least when using --on-the-fly-encoding). It also does not have much encoding options. It would be probably ideal to use uncompressed video, because transfer is cheap and encoding/decoding is GPU/CPU-intensive. (Actually, GPU can at least theoretically help with encoding, as it happens in dom0. It can't help with video decoding.) I haven't tried to adjust video quality, because I am not sure about the effect on encoding performance. * Not sure about other alternatives available in Fedora without additional repositories. I am not aware about any. * Maybe we could try the software intended to pipe windows from domUs to dom0 for the other way? Playback: * I use MPlayer, but any player capable of playing a pipe can do the job. * If you want to use it in a VNC session, you will probably want to add something like “env DISPLAY=:1”. But now, it is too early. * In my experiment, the domU part was Debian 9, but I don't think this matters much. The script with comments: https://gist.github.com/v6ak/1678244cd71a0ebd019531d02a149c8f 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/43dae632-d8a9-4735-bb40-a6ed71053501%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
On February 1, 2018 6:42:08 PM GMT+01:00, Dave C wrote: >Indeed, I stand corrected. This point could apply to a restrictive >firewall, but the VM would need to network with the local VM running >vncserver. BTW, you could also pipe the network communication through qrexec. This could be more secure than restrictive firewall. >I can imagine opening a terminal in the VM running vncserver and the >window manager. Could attacker open a terminal in other vm that has >opened some application in that display? (Application that is not a >terminal, I mean. I do see how an attacker could use any application >shown in the display.) It depends on what application you mean. I can see how a webbrowser can be used as a gadget to open terminal and some other applications (e.g., Libreoffice) can be used to open webbrowser. (And maybe LibreOffice supports macros or something similar, so attacker does not need to browser/terminal. Also, a text editor like Geany can be abused for editing files like .bashrc. I am not sure about generic applications with no such option of saving files and opening them in some apps. I remember statements that X11 is not designed for isolation and some those statements look like this is possible generally by design. I was able to neither confirm nor deny it in a short time. Regards, Vít Šesták 'v6ak' Maybe top-posting is bad. However, quoting whole message (including quotes of quotes and quotes of quotes of quotes etc.) before your message is even worse. Please don't let others scroll extensively. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0254EE1B-EC02-453F-BC96-A9D7218CFBA9%40v6ak.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
On Sunday, January 28, 2018 at 12:24:08 PM UTC-8, Vít Šesták wrote: > On January 27, 2018 7:57:02 AM GMT+01:00, Dave C wrote: > >* VMs that can't access the conference site (i.e. bluejeans.com) or > >can't access the net at all > > How can a VM without network access open a window in the X11 accessible from > network? Indeed, I stand corrected. This point could apply to a restrictive firewall, but the VM would need to network with the local VM running vncserver. [snip] > > >My approach lowers security while screensharing. But the rest of the > >time, not screensharing, the VMs are running with normal firewall > >settings. > > It is likely that a VM can infect any other of the VMs (or the screensharing > VM). There are multiple potential ways to do so: > > a. Exploit some vulnerability in X11 protocol implementation. > b. Open a terminal (if not already opened) and type a command. This is > possible, because any client can inject any input events to other client. I can imagine opening a terminal in the VM running vncserver and the window manager. Could attacker open a terminal in other vm that has opened some application in that display? (Application that is not a terminal, I mean. I do see how an attacker could use any application shown in the display.) > c. Download some file using webbrowser and run/install it (e.g., using some > packaging system). > d. I remember I have read that X11 effectively provides no isolation between > apps and I had an impression that any app can by design even run some code in > another client. However, don't take this point as verified unless you verify > it from some other source. You make some great points. Thanks. I'm re-thinking my approach. -Dave > > Regards, > Vít Šesták 'v6ak' > > General note: Maybe top-posting is bad. However, quoting whole message > (including quotes of quotes and quotes of quotes of quotes etc.) before your > message is even worse. Please don't let others scroll extensively. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/777001bc-545b-419f-ab74-c1b160e1b48a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
On January 27, 2018 7:57:02 AM GMT+01:00, Dave C wrote: >* VMs that can't access the conference site (i.e. bluejeans.com) or >can't access the net at all How can a VM without network access open a window in the X11 accessible from network? >* VMs that don't have vncserver installed, or don't have a plugin >needed to screenshare IMHO a minor gain. >My approach lowers security while screensharing. But the rest of the >time, not screensharing, the VMs are running with normal firewall >settings. It is likely that a VM can infect any other of the VMs (or the screensharing VM). There are multiple potential ways to do so: a. Exploit some vulnerability in X11 protocol implementation. b. Open a terminal (if not already opened) and type a command. This is possible, because any client can inject any input events to other client. c. Download some file using webbrowser and run/install it (e.g., using some packaging system). d. I remember I have read that X11 effectively provides no isolation between apps and I had an impression that any app can by design even run some code in another client. However, don't take this point as verified unless you verify it from some other source. Regards, Vít Šesták 'v6ak' General note: Maybe top-posting is bad. However, quoting whole message (including quotes of quotes and quotes of quotes of quotes etc.) before your message is even worse. Please don't let others scroll extensively. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/85D57652-4F14-41F7-9020-506468F33FEC%40v6ak.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS screensharing
On Thursday, January 25, 2018 at 1:34:03 AM UTC-8, Vít Šesták wrote: > Dave, why you start a new VM and not just use a loopback? Is the reason > sharing apps from multiple VMs? If si, you are at least significantly > weakening isolation. Maybe you are not keeping any, not sure. X11 was not > designed for isolation at all. I run the vncserver in a new VM so that I can screenshare from... * multiple app VMs * VMs that can't access the conference site (i.e. bluejeans.com) or can't access the net at all * VMs that don't have vncserver installed, or don't have a plugin needed to screenshare My approach lowers security while screensharing. But the rest of the time, not screensharing, the VMs are running with normal firewall settings. I realize X11 is a weak link in what might be an otherwise secure desktop. One of the reasons I am a fan of Qubes! -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b9567fb7-af2f-4e12-8421-21a9ef6168c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS screensharing
Dave, why you start a new VM and not just use a loopback? Is the reason sharing apps from multiple VMs? If si, you are at least significantly weakening isolation. Maybe you are not keeping any, not sure. X11 was not designed for isolation at all. Nuno, this is probably possible, but not so trivial. You would need Grub (as HVMs and PVs have different boot mechanisms) and you would need to adjust some things made for PVs - probably some startup services and some X11 config files. Those changes (especially the Grub change) would require a modification of the template. And you would also need to reboot to change it. I have some idea for full screensharing (considering Qubes-agnostic generic screensharing apps): 1. Scrap the screen in dom0 and send it to a VM through Qubes RPC. It seems that VLC can be used for that. Uncompressed video could be ideal for low latency and lower CPU usage. Compression does not make much sense within a physical computer. But compressed video could be also acceptable. I believe video encoding is not a risky operation, so it can be done in dom0 without any additional real risk. 2. In the VM, play the video in a VNC-loopback X11 session. 3. Run the screensharing app of your choice in the same X11 session. 4. Make the screensharing video fullscreen. Of course, this would make some fractal effect when the VNC client is visible on screen ☺ I haven't tried it yet, but it seems 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/624034b4-6326-4a7a-9484-1eda6bfc5bea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes OS screensharing
I was under the impression that 4.0, by virtue of running on HVM, would allow for native screensharing (webex, zoom, skype, etc) by simply disabling seamless mode on the VM you want to share - is this not the case ? On 01/24/2018 07:25 AM, Dave C wrote: > I hope no one minds reviving an old thread... > > I recently needed to screenshare in Qubes (4.x, but 3.2 should work the > same). I wrote up my notes: > > https://www.dave-cohen.com/blog/qubes-vnc-screenshare/ > > Feedback welcome, especially if the method can be improved. Thanks. > -- Best regards, Nuno Branco -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/53832a2a-0ece-3239-fdca-ae795f85bacf%40mulligans.pw. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS screensharing
I hope no one minds reviving an old thread... I recently needed to screenshare in Qubes (4.x, but 3.2 should work the same). I wrote up my notes: https://www.dave-cohen.com/blog/qubes-vnc-screenshare/ Feedback welcome, especially if the method can be improved. Thanks. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7c9de595-73db-4251-a5c8-e317cab6cc30%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.