Mouse and Keyboard passthrough to Windows HVM

User Support General
21

I had this issue and I cannot remember what I did to be honest. Ill have to look and see if I omitted something. Make sure your keyboard and mouse are not swapped in the event0 event1 part of the stub domain. Also make sure you are passing the right device in dom0.

22

I’ve checked and they’re not being swapped and they’re the right events, the mouse works fine the clicks also work but when I click it teleports to the top left, did you change anything in the libvirt config? This might have to do with the qubes gui? The only thing I’ve done is set the guivm to none and pass the gpu, also when I pass the same event to sys-gui it works fine

23

@khmartinsen Turns out the mouse doesn’t only go to top left whenever I click or scroll, it teleports to whatever place the “primary” mouse input is. For example if I move the mouse with the window emulated mouse on dom0 (the default way) and than use the evdev mouse that QEMU uses and move it and click or scroll, it goes back to whatever position the other mouse is.

I think having a look at how you set up your input devices on the libvirt config would help but I’m not sure, hopefully you can tell what’s going on based on what I tried to explain. (I’m awful at explaining things)

24

That is exactly the issue I had. Its from the qubes_drv. In my windows 10 vm I don’t need the emulated window that qubes provides so I disable that by using qvm-features. I am not sure if all of these need to be turned off but i the following set:

gui 0
gui-emulated 0
video-model none

I don’t think you would want to change anything in libvirt but if you did you would want to remove the tablet input I think. Maybe in the VM you can disable that input device that is related to the qubes gui window tablet inputs.

1 Like
25

@khmartinsen Thank you simply removing tablet input solves the problem in dom0, for some reason the same setup while using sys-gui doesn’t.

Unfortunately I can’t remove the emulated window because I need to force MSI on my NVIDIA graphics card in Windows otherwise the display glitches and blacks out (making it unusable) and the VM eventually shutdowns.

I’ve been booting Windows in safe mode and adding a registry entry every time the address changes, but if I change the features you mentioned I won’t be able to force MSI because the GPU address will be different and I won’t be able to change it.

Do you know of an alternative to set my GPU to use MSI by default?

On dom0 lspci -v shows that MSI is disabled:

Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+

Would that capability even be passed to the VM?

26

I am not sure. I have not used sys-gui yet. I would think there would be some way to just disable the tablet input in whatever VM you are in. So in sys-gui can you disable the tablet input by identifying which device it is in /dev/input/…?

27

Shouldn’t removing <input type='tablet' bus='usb'/> from the VM xml be enough? I find it strange that the outcome isn’t the same as it is in dom0, I should mention that it doesn’t display anything on the screen I think it’s related to the MSI shenanigans, I’ll double check

28

I would think that is enough. Which xml are you editing? The ones located in /etc/libvirt/libxl/ are auto-generated. You need to follow this: Custom libvirt config — core-admin v4.2.7-0-gf40e8c21-dirty documentation.

29

It looks like I had messed up somewhere else, it wasn’t related to any of your fixes I just had to reinstall the NVIDIA drivers and manually enable MSI again, not really sure how that happened but anyhow it’s working now and the performance seems better than with the usb proxy but that might be placebo, thank you for your patience and for your time!

1 Like
30

Can you elaborate on step 1?

Specifically:

  1. Where does the 60-input file go in the directory structure?
  2. What build target(s) did you use, or just ‘make qubes’ to make everything?

Also, can you explain what you’re doing with all the cat-ing?

Thanks for this guide! :slight_smile:

31

After a deep examination of the qubes-builder tree, it looks like it should go in:
qubes-builder/qubes-src/vmm-xen-stubdom-linux/linux/config

and it can be built just with the component target vmm-xen-stubdom-linux

Is this correct?

32

Apparently not. I can’t get anything to build completely with qubes-builder. Missing internal dependencies, and make qubes dies with a warnerror in qrexec-daemon.c. I’ve probably done something wrong setting up the build environment, or pulled the wrong version of qubes or something. Just going by the qubes-builder doc and guessing at the proper way to achieve this step.

Ultimately, this is pretty much what I am aiming for. A hotkey-reassignable KBM switch that switches between dom0 and configured domUs. I don’t need the screen flipping that the libvirt-evdev does, just move my KBM to different VMs, is all.

33

You are correct on the placement of the 60-input file and using just that part for qubes builder. I also had issues when using qubes builder. I will find my notes. There was a command I had to change when following the official documentation.

I gutted the screen changing part of Libvirt-evdev and it works well for just mouse and keyboard as you described.

34

Yeah, that’s what I was thinking of doing as well. It’s pretty easy to whack that part out and leave the rest.

Thanks for getting back to me! :smiley: