Microphone has a mysterious keyboard

I would like to use my fancy audio system, but the little hub thing that I route the microphone and headset through has a keyboard on it according to the denied input notification. When I connect the usb device to a qube is there a way to isolate the keyboard so it doesn’t come with the device?

By connect I mean click the little usb thing on the top right and attach it to a qube.

The keyboard there is a part of your microphone, maybe it’s a microphone mute switch or something like this.
Your USB microphone is a composite USB device that has multiple interfaces: audio interface and HID interface (which acts as a keyboard).
You can’t attach just audio interface to another qube, you can only attach a whole USB device.
The message about denied input on microphone connection is about denying this microphone’s keyboard interface input to be passed from sys-usb to dom0. This is a default policy for USB keyboard that is set in Qubes Global Config → USB Devices tab.

1 Like

If I attach my USB mouse to dom0 does it also attaches the keyboard part of it? It says qubes.InputMouse as the operation.

No, it’s not attaching a USB device from sys-usb to dom0, the USB mouse stays in sys-usb but the mouse input actions are transfered from sys-usb to dom0 using RPC to the virtual mouse device in dom0.

2 Likes

The basic flow in Qubes OS with sys-usb goes something like this:

USB device is plugged into USB port
→ Linux kernel is sys-usb does its thing and registers the device
qubes-app-linux-input-proxy claims the device
qubes-app-linux-input-proxy sends a blind message to dom0
dom0 then checks to see what to do with such requests
dom0 asks the user whether to allow the mouse to send signals to dom0
→ the user allows the request
→ the “sanitized” signals from qubes-app-linux-input-proxy are sent to dom0
→ the mouse cursor moves as if the mouse is plugged directly into dom0

If the USB device re-registers itself as a different category of device, then qubes-app-linux-input-proxy will (should) pick up on that that start the entire process again.

Some USB devices will register themselves as multiple devices, based on their functionality.

Your USB headset/microphone probably has buttons on them. Rather than forcing you to install custom firmware/drivers that tell the computer what those buttons do, it’s often much easier for the manufacturer to make the device declare itself as a keyboard, and map those buttons to “Play/Pause” and volume controls on a keyboard.

Bluetooth headsets, USB sound cards, infrared receivers, and a whole bunch of other USB devices will take advantage of this aspect of USB. It means that every computer knows how to drive the device without installing custom firmware.

Unfortunately, a computer basically has no way (or very limited ways) to verify that a USB device actually is what it claims it is, so in order for this system to work, the computer basically has to blindly accept anything that says “I’m a keyboard”.


Is there anything to stop the USB microphone from injecting keystrokes that aren’t related to audio?

Nope, and your computer will blindly accept it as “user input”, too :stuck_out_tongue:

Does this occur in the real world?

Why, yes, yes it does. It is one of the main reasons why IT departments tell their non-technical employees “don’t plug in random things into the USB ports”. It’s just easier than trying to explain it to them :stuck_out_tongue:

The old “get them to plug a device in that looks like a harmless flash drive, and leave it plugged in, and then it turns into a keyboard at 2am when everyone is out of the office” trick…


It is simultaneously the greatest strength and the greatest weakness of the Universal Serial Bus :sweat_smile:


If you want to be able to use those buttons without passing them into dom0, you should be able to pass the keyboard input to whatever qube your audio is in. You can also configure this in the policy files in the /etc/qubes/ directory.

2 Likes