Rokas, Gerd is the maker of the patches and I suggested something like this because I use a cheap and dirty program that I wrote to switch monitor inputs via i2c bus over the hdmi cable directly. I have a monitor with two hdmi inputs so I switch between them. He's thinking of adding that later. Currently you need to do something like autohotkey or manually switch the monitor over.
Jon On 1 Mar 2016 10:16, "Rokas Kupstys" <[email protected]> wrote: > Hey Jonathan, > Is there any way for host to manage keyboard/mouse switching with your > patches? What i mean is i use KVM switch to toggle between host/VM cards. > Be nice of keyboard/mouse could follow active display. Now i dont know how > to capture this display switch event but linux would not be linux if that > were not possible. With that said be nice if we could run some script on > host and toggle switching of keyboard/mouse to/from VM. Think that could be > possible? > > On 2016.03.01 12:08, Jonathan Scruggs wrote: > > 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. > > Jon > On Feb 29, 2016 10:23 PM, "thibaut noah" <[email protected]> wrote: > >> What about input lag with the patch? >> The point of using passthrough on usb controller is to get direct input >> for games >> On Mon, 29 Feb 2016 at 21:37, Jonathan Scruggs <[email protected]> >> wrote: >> >>> Those patches are supposed to be added to mainline at some point. They >>> are stable and work great! >>> On 29 Feb 2016 20:33, "Will Marler" <[email protected]> wrote: >>> >>>> Oh, good point, that is an option too (although I personally I stay >>>> away from patching) >>>> >>>> On Mon, Feb 29, 2016 at 1:29 PM, Jonathan Scruggs <[email protected]> >>>> wrote: >>>> >>>>> 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. >>>>> On 29 Feb 2016 17:44, "Will Marler" <[email protected]> wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> On Sat, Feb 27, 2016 at 1:02 AM, Rokas Kupstys <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> On 2016.02.26 23:09, Muted Bytes wrote: >>>>>>> >>>>>>> From my experience: >>>>>>> >>>>>>> I would consider usage stable for an average user, but I'm not sure >>>>>>> about set-up for a non-technical user. >>>>>>> >>>>>>> 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). >>>>>>> >>>>>>> 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). >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> 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. >>>>>>> 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. >>>>>>> On Feb 25, 2016 22:59, "Daniel Pocock" <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> Is a passthrough VGA configuration currently considered stable and >>>>>>>> secure for widespread use, for example, where non-technical users >>>>>>>> can >>>>>>>> work productively with applications running this way in an office >>>>>>>> environment? >>>>>>>> >>>>>>>> Some specific things come to mind: >>>>>>>> >>>>>>>> a) crashes: I've seen crashes mentioned in a few discussions, but >>>>>>>> are >>>>>>>> there many people running it for days and weeks at a time without >>>>>>>> crashes? Are such issues specific to particular hardware and can >>>>>>>> they >>>>>>>> be avoided by using hardware that is preferred/more heavily tested >>>>>>>> by >>>>>>>> the developers? >>>>>>>> >>>>>>>> b) security: in my testing so far, I just run the qemu command as >>>>>>>> root. >>>>>>>> To what extent can the use of root privileges be avoided? I >>>>>>>> realize a >>>>>>>> VM is never 100% secure compared to a normal user session. >>>>>>>> >>>>>>>> c) control: some of the blogs and wikis mention that tools like >>>>>>>> virt-manager and virt-install don't fully cope with passthrough VGA >>>>>>>> configuration, is that still up to date? Can the user start and >>>>>>>> manage >>>>>>>> the VM using some GUI from their X desktop on their host display? >>>>>>>> >>>>>>>> d) interaction between VM and host desktop: when the user locks the >>>>>>>> host >>>>>>>> display (screensaver), can this also lock the VM's passthrough >>>>>>>> display, >>>>>>>> or the user will always need to lock both? How well does something >>>>>>>> like >>>>>>>> Synergy work across the displays, especially for things like >>>>>>>> cut-and-paste? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> vfio-users mailing list >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> vfio-users mailing >>>>>>> [email protected]https://www.redhat.com/mailman/listinfo/vfio-users >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> vfio-users mailing list >>>>>>> [email protected] >>>>>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> vfio-users mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>>>> >>>>>> >>>> _______________________________________________ >>> vfio-users mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/vfio-users >>> >> > > _______________________________________________ > vfio-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/vfio-users > >
_______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
