Mouse Capture

General Discussion
1

Context

When I connect my mouse to my computer, I’m prompted to allow sys-usb to call qubes.InputMouse on dom0. Permitting this operation allows me to control the mouse pointer in dom0 using the connected USB mouse.

This works fine for general desktop use. However, it doesn’t work for games like Minecraft running in a VM. This is because the VM receives absolute mouse coordinates instead of relative movements. Since absolute coordinates are always positive, moving the mouse causes Steve’s head to spin continuously and look downward—making the game unplayable.

After testing with qubes-app-linux-input-proxy, I was able to resolve this issue. I installed qubes-input-proxy in the target VM (the one running Minecraft) and manually started the proxy using a qvm-run command chain from dom0. This allowed the VM to receive relative mouse input instead.

Idea

I’m considering the following configuration changes to streamline this setup:

  1. In dom0, append the following line to the bottom of /etc/qubes/policy.d/50-config-input.policy:

    qubes.InputMouse * sys-usb @anyvm ask

  2. Install the qubes-input-proxy package from the appropriate Qubes repository into the TemplateVMs (or StandaloneVMs) of any VMs I want to capture the mouse. This package installs /etc/qubes-rpc/qubes.InputMouse in the VM automatically.

Then:

  • Shut down the TemplateVMs, and restart any VMs based on them.
  • Unplug and replug the USB mouse.

At this point, I should receive the usual [Dom0] Operation execution dialog when the mouse is connected. However, this time I’ll be able to choose a VM other than dom0 as the target. If I select the Minecraft VM, it will receive raw mouse input directly—allowing proper in-game behavior.

Bugs / Quirks

Invisible Pointer

When the mouse is captured by a VM, the pointer inside the VM becomes invisible. This appears to be by design—likely to avoid showing two cursors when a VM window is focused.

Denied, Denied, Denied…

The target VM will likely have a systemd unit called qubes-input-sender-mouse@.service. When a new mouse is detected (even if it’s the result of an input proxy), the VM tries to call qubes.InputMouse on dom0. Since this is not allowed from VMs that aren’t sys-usb, it results in denied RPC attempts and pop-up notifications.

This is harmless, but the repeated “Denied” messages are annoying. To silence them, I can add the following policy at the end of /etc/qubes/policy.d/50-config-input.policy in dom0:

qubes.InputMouse * @anyvm dom0 deny notify=no

This suppresses the notification but still denies the RPC.

Infinite Recursion → Crash?

I haven’t tested this and strongly discourage anyone from trying it.

Imagine if I changed the policy from “ask” to “allow”, and allowed sys-usb to call qubes.InputMouse on itself. Since I installed qubes-input-proxy in TemplateVMs used by sys-usb, it would now have a qubes.InputMouse handler.

I suspect Qubes has safeguards for this scenario, but just in case, I recommend proactively denying this with a policy entry at the beginning of /etc/qubes/policy.d/50-config-input.policy in dom0:

qubes.InputMouse * sys-usb sys-usb deny

Question

What are the security implications of this configuration in Qubes OS?

Are there risks I’m overlooking by letting sys-usb proxy mouse input into potentially untrusted VMs via the qubes.InputMouse RPC?

Let me know if anything seems dangerous or ill-advised in this approach.