<p dir="ltr">I have no lag. The patches make the keyboard/mouse directly available on the guest as a real device. This way I have one keyboard and mouse for both host and guest. The technical bit is that the input buffers are forwarded to the guest. Synergy is nice but there is lag with that. These patches are real time! I play the latest AAA games too. I haven't noticed anything. It doesn't hurt to try. I can post my libvirt config if need be. I'll need to get the git address of the latest version.</p>
<p dir="ltr">Jon</p>
<div class="gmail_quote">On Feb 29, 2016 10:23 PM, "thibaut noah" <<a href="mailto:thibaut.noah@gmail.com">thibaut.noah@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What about input lag with the patch?<br>The point of using passthrough on usb controller is to get direct input for games<br><div class="gmail_quote"><div dir="ltr">On Mon, 29 Feb 2016 at 21:37, Jonathan Scruggs <<a href="mailto:j.scruggs@gmail.com" target="_blank">j.scruggs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Those patches are supposed to be added to mainline at some point. They are stable and work great!</p>
<div class="gmail_quote">On 29 Feb 2016 20:33, "Will Marler" <<a href="mailto:will@wmarler.com" target="_blank">will@wmarler.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Oh, good point, that is an option too (although I personally I stay away from patching)</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 1:29 PM, Jonathan Scruggs <span dir="ltr"><<a href="mailto:j.scruggs@gmail.com" target="_blank">j.scruggs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">For keyboard and mouse, grab the patches in this mailing list that pass through your host keyboard and mouse as a standard PS/2 device. You press both CTRL keys to switch between host and guest. Works very well. You also have full BIOS control of the guest and Windows UAC pop-ups can be clicked on where as synergy gets blocked by those prompts.</p><div><div>
<div class="gmail_quote">On 29 Feb 2016 17:44, "Will Marler" <<a href="mailto:will@wmarler.com" target="_blank">will@wmarler.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">a) I've never had Host or Guest crash problems. I have had problems with programs crashing in the guest with nebulous errors (or no errors) that seem related to graphics. They are reproducible, but not reliably so, and I have never tried to verify if those crashes exist on baremetal. <div><br></div><div>d) Synergy works great for simple functions (when you need keyboard & 2-button mouse). In my experience it is not a good solution for games, as some games will interpret the mouse inputs weirldy (small physical mouse movements resulting in HUGE cursor movements), and the full spectrum of buttons doesn't get translated through.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 27, 2016 at 1:02 AM, Rokas Kupstys <span dir="ltr"><<a href="mailto:rokups@zoho.com" target="_blank">rokups@zoho.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
b) VM even if qemu runs as root is still more secure than running
software in your own session. More things need to be broken to get
to the host with virtualisation in place.<br>
<br>
c) virt-manager can do almost all whats needed. Might need to edit
xmls by hand to switch it to uefi though. Or to add few flags not
supported by virt-manager, but as far as device assignment goes
virt-manager does handle it.<div><div><br>
<br>
<div>On 2016.02.26 23:09, Muted Bytes wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">From my experience:</p>
<p dir="ltr">I would consider usage stable for an average user,
but I'm not sure about set-up for a non-technical user.</p>
<p dir="ltr">a) In my specific case, I am forced to use Windows
because a lot of simulation and computational tools are only
available on that platform, but I chose to operate in a VM
rather than baremetal. As a result, I have both memory and cpu
intensive simulations running in the guest for days at a time,
and idle for weeks/months (shutdown only for host maintenance
etc). Have never had guest or host crash or freeze (even through
guest restarts).</p>
<p dir="ltr">b) I cannot provide comment, I am also running qemu
as root. I intend to look at how to move away from root
execution of qemu but haven't yet (virtsh makes this
easier/possible from what I've read but haven't looked in
detail).</p>
<p dir="ltr">c) I am also still using qemu from command-line so
cannot comment, but I have been watching progression of virtsh
and virt-manager. I think it already is at/getting to that
point.</p>
<p dir="ltr">d) I am using synergy to switch between screens/share
kb and mouse with guest. In my case, if the mouse is left on
guest side, the guest can lock but synergy prevents the host
from locking. The mouse needs to be on host side for me. Also,
my guest and host lock independently, so I'm not sure if there
is a way to synchronize this.<br>
Copy/paste generally works well with text in both directions,
however there seem to be some issues with more recent versions
of synergy upstream that makes the server portion to hang/crash
that seems to be related to the copy buffer (though I'm not 100%
sure this is the cause). I haven't encountered this in a while,
so it has been intermittent in my case. One good thing about
synergy is that you can set it up so that scroll lock key will
lock the mouse/kb to one side (guest or host) if you plan to
work or game in that environment for a long session, and don't
want the mouse to accidentally switch context on the screen
edge/boundary. This also makes fullscreen and FPS games playable
in the guest without the mouse going nuts from losing relative
position information.</p>
<div class="gmail_quote">On Feb 25, 2016 22:59, "Daniel Pocock"
<<a href="mailto:daniel@pocock.pro" target="_blank">daniel@pocock.pro</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Is a passthrough VGA configuration currently considered stable
and<br>
secure for widespread use, for example, where non-technical
users can<br>
work productively with applications running this way in an
office<br>
environment?<br>
<br>
Some specific things come to mind:<br>
<br>
a) crashes: I've seen crashes mentioned in a few discussions,
but are<br>
there many people running it for days and weeks at a time
without<br>
crashes? Are such issues specific to particular hardware and
can they<br>
be avoided by using hardware that is preferred/more heavily
tested by<br>
the developers?<br>
<br>
b) security: in my testing so far, I just run the qemu command
as root.<br>
To what extent can the use of root privileges be avoided? I
realize a<br>
VM is never 100% secure compared to a normal user session.<br>
<br>
c) control: some of the blogs and wikis mention that tools
like<br>
virt-manager and virt-install don't fully cope with
passthrough VGA<br>
configuration, is that still up to date? Can the user start
and manage<br>
the VM using some GUI from their X desktop on their host
display?<br>
<br>
d) interaction between VM and host desktop: when the user
locks the host<br>
display (screensaver), can this also lock the VM's passthrough
display,<br>
or the user will always need to lock both? How well does
something like<br>
Synergy work across the displays, especially for things like
cut-and-paste?<br>
<br>
_______________________________________________<br>
vfio-users mailing list<br>
<a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
vfio-users mailing list
<a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/vfio-users" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
vfio-users mailing list<br>
<a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
vfio-users mailing list<br>
<a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a><br>
<br></blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div>
_______________________________________________<br>
vfio-users mailing list<br>
<a href="mailto:vfio-users@redhat.com" target="_blank">vfio-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/vfio-users" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a><br>
</blockquote></div>
</blockquote></div>