This is exactly what I’ve been unable to figure out. How to determine which USB “plug” goes to which controller. There are command-line methods to see a list of controllers. There are command line methods to see a list of plugs. No command line method to tell you which one goes with which one.
This is where maunal tests are needed. AFAIK you can attach only one controller to your sys-usb and boot it up, then see what does the devices widget see
.
Unfortunately my attempts to do that resulted in a frozen keyboard and mouse and I couldn’t check.
Can’t you use dmesg?
The PCI device for the PS/2 controller on my systems is not the same as the USB controller.
I never even heard of dmesg. If I have to type or click on something to invoke it, then no.
Furthermore, I don’t HAVE PS/2 on this…if I did, I wouldn’t care. The point of learning the different controllers would be to give the keyboard and mouse to one of them, and putting all others under the control of sys-usb without any bypass logic for the keyboard and mouse.
I am sure it is possible to find out in dom0 of Qubes OS (logs, dmesg, some tools), but another way is to download Kubuntu distro to flashdrive and boot from it (in livecd mode, even without ssd/hdd being connected).
It has GUI tools that show info about system including the information about USB Controllers and devices connected to them.
Thanks. I had largely forgotten about this. to be honest. until reminded in the thread this was split from. I’ve just been using sys-usb with whatever setting (I don’t recall what it is) to let the keyboard and mouse work.
The verbose option on lsusb has an iSerial property that corresponds to the controller’s PCI BDF number.
lsusb -v 2>/dev/null | grep 'root hub\|iSerial'
I’m not sure what you’re asking for.
If you’re asking for a way to link physical ports on your motherboard to a particular controller, the only way I know of is from the BIOS/UEFI, and I dunno if it’s available for all brands.
On MSI, it’s called “board explorer”.
Else, there is the combination of “lspci | grep -i USB” and “lsusb -tv”, from which you may infer things.
Post your results.
Thanks for the response!
I note that the command you give apparently must be done on sys-usb.
Unfortunately I can’t copy the output to the clipboard on sys-usb for some reason (neither mousing nor control C do it), so I’ll have to report what I see here.
OK, “Bus 003 Device 001” apparently has all of my “always plugged in” USB devices (keyboard, mouse and printer). Serial numbers where given (for keyboard and printer) match what’s in qui-devices. This appears to be a USB 3 controller. There are devices on there with serial number zero, I’m guessing the mouse is one of those.
There are two “2.0 root hubs” as well but I have no idea what they’re connected to. One of them has an iserial 10 42 on it.
Moving the mouse and keyboard to unoccupied plugs leaves them on the same controller.
So it appears every single “plug” on my home system goes to the SAME controller. The two USB 2.0 controllers (which would be ideal for a mouse and keyboard) don’t seem to connect to anything.
And I still wouldn’t know how to correlate that to the numbers in lspci on dom0; I can’t find any matches between that listing and the other one. But that’s moot; all plugs go to the same controller, whichever one it is.
If you want to know how much physical controllers you have, run “lspci | grep -i usb” in dom0.
Also, in sys-usb, you have to run “lsusb -tv”.
To link results from lspci and lsusb, you have to run “dmesg | grep -i usb” in dom0 and sys-usb.
You will get a correlation between the devices/hubs and the PCI device ids.
Example from dmesg :
input: my own USB Keyboard as /devices/pci0000:00/0000:00:27.0/0000:38:00.3/usb3/1-2/1-2:1.1/0123:0456:D794.0008/input/input12
PS: to copy/paste between qubes, you have to use “Ctrl+SHIFT+c” and “Ctrl+SHIFT+v”, it’s the secure copy/paste mechanism of Qubes
Thanks!!
OK, my bad for neglecting to mention that I had done lspci…that was what I was trying to correlate. It’s the numbers from lspci that need to be used to attach controllers to sys-usb.
Running lsusb -tv on sys-usb shows me a VERY different picture. It now appears as though everything is on one of the 2.0 root hubs.
dmesg on dom0 only finds my mouse…not my keyboard or printer. The dmesg output on sys-usb is quite large and I’m going to have to pick over it to find any reference to stuff that appears in lspci on dom0.
Re: your PS Yes, I know about control shift C/V (but maybe down the road someone reading this won’t, so thanks!). The problem was, in sys-usb I couldn’t get anything into sys-usb’s clipboard for ctrl-shift C to copy to the “qubes” clipboard in the first place. In other words the problem was within sys-usb. Neither mouse-selecting or hitting control C would do it; when I did shift control C zero bytes were copied (and right mousing after highlighting with the mouse simply changed the bounds of the selection). OK that was a side issue.
If the sys-usb dmesg provides too much info, you may restrict the output even further with :
dmesg | grep -i usb | grep -i /devices/pci.
But now I’m thinking about it, IIRC the PCI devices ids are not the same in dom0 and when PT to a qube. You may have to translate numbers one more time …
Huh … It would really help if you could post the full outputs (redacted if you want) of both lsusb -tv and the one from frank_sullivan.
Ah, sorry 
But the right mousing stuff is strange o_O Maybe create another post about that ?
Another possibility to “transfer text” could be to save logs to a file in sys-usb permanent storage and get it back from dom0 (i mean like “dmesg > sys-usb.log”).
Or, as it’s sys-usb, to save it to a usb drive and post here from another computer ?
@Sven @marmarek @Demi
Maybe HCL report tool should include some code that finds out major information about USB Connectors including which one has keyboard, mouse and touchpad, wifi, bluetooth and etc. I mean lspci -v and lsusb -v outputs often are not attached (sometimes due to privacy reasons) and are not that easy to read anyway.
It will be great to see this valuable information in comparison table at some point.
That could be very useful…but it sounds like you’re assuming the keyboard and mouse are hardwired somehow.
I can literally move the mouse and keyboard to another plug on the outside of the box. How would the HCL report account for that? Someone else is going to read that report and possibly assume their mouse is plugged in to the same place the report-generator’s mouse is.
If the report were to say something like “the two USBs on the front of the box are connected to 01:e and the ones on the back are connected to…” then we’d have something that a person could use to assign only some USB ports to sys-usb.
My impression, based on the fragmentary bits and pieces I’ve been gleaning, is that even though four controllers are listed in lspci (though three of them have very similar numbers and might just be the same controller showing up three different ways)…every single physical plug on the box (all six of them) goes to the SAME individual controller–though I can’t tell which one of the four it is! I don’t know what the other three are there for, in that case. But it also means I can’t control only some of my physical plugs with sys-usb; it’s all or nothing.
Fortunately my system functions with “all” so this isn’t critical from a functional standpoint, even if from a security standpoint it’s less than ideal.
It sounds like you only have 1 USB controller then. If you already have sys-usb working, you can look at the Devices tab for the qube and see what hardware is passed through. If there is only 1 USB controller listed and you don’t have any USB ports that can’t be passed through to another qube it’s just the 1 controller.
If you have another USB controller, you should be able to see it with lspci in dom0, or as an available passthrough device in Qube Manager.
The reason you see 2 controllers in sys-usb is that every HVM qube gets an emulated USB controller in addition to any that are passed through. The “USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 10)” is what the emulated controller currently appears as, but it’s possible future qubes versions would emulate a different device. The emulated controller will also have an “Adomax Technology Co., Ltd QEMU USB Tablet” attached and visible in lsusb.
Also it’s worth noting that the PCI BDF numbers you see inside a qube like sys-usb are not the real ones you would use to passthrough the device to another qube, but you could use the iSerial entry for that controller to figure out which USB Buses correspond to each controller. If there were 2 controllers, hopefully the descriptions would differ to easily identify which real devices and BDF number to remove from sys-usb and passthrough to another qube. There’s probably a way in dom0 to determine the mapping between guest and real BDF numbers, but I haven’t checked.
Well, it was about laptops, of course.
It is really hard to choose a laptop for Qubes OS nowadays. Especially taking into account that Qubes OS is not able to play flawlessly 1080p youtube videos even on modern CPUs, that removes old and slow thinkpads out of list.
And in laptop user cannot just reconnect touchpad or keyboard to another USB Controllers, nor add extra one in PCI slot.
About laptops…yes, that makes sense. Thanks.
I think you might have missed the part where I said that lspci shows four controllers. On the other hand, I failed to clarify that that’s lspci run on dom0 (I don’t think the command even exists on my sys-usb.)
I’ve known about lspci for months. It’s trying to figure out which of the ones on that list goes to a specific physical plug on the box that has been perpetually beyond my grasp. I really don’t give a damn about how it’s mapped somewhere. I just want to know, which controller runs which plug? The numbers given by lspci are the same numbers you use to give a qube control of a PCI device; no other numbers are of any value to me unless they will help me figure this out. But alas there is NO TOOL that will simply tell me my mouse is currently under the control of 1:e, or 0:2, or whatever, so I can connect the mouse to different plugs to see which one is controlled by which controller. Dmesg gives me a long, long hex number (provided I run it on sys-usb…on dom0 it only sees my mouse)…that does nothing to help me out.
If I could prove that (say) the two plugs paired together on the upper left of the back of the box went with controller #1 OUT OF THE LIST GIVEN BY LSPCI, not some fake logical controller on sys-usb, and all other plugs went to other controllers, I could connect my usb keyboard and mouse to those two plugs, NOT give sys-usb control of controller #1, and not have to tell sys-usb to pass those devices through to dom0.
But as near as I have been able to determine, lspci shows four controllers, yet just one of the four controls ALL of the plugs on the outside of the box. I can’t tell which one, but they all seem to group together somehow in sys-usb. Of course that could just be the (useless to me) mapping that goes on within sys-usb.
Since I’m trying to determine how not to give sys-usb control of some subset of my devices, I really have no need to know what sys-usb is doing to them after it has been given control.