I’m on an intel NUC. (It’s almost perfect…if it were twice as tall it would be cubical.) It’s a desktop, a very small one, and has no ps2 ports.
Both keyboard and mouse froze. On rebooting, both were frozen at the password prompt; fortunately I found the skip_autostart suggestion via my phone. (I’ve now written it down.) I’ve restored things back the way they were, so the next reboot shouldn’t be so problematic. (And if it is, I have my cheat sheet now.)
Does it have 2 standard USB ports and one USB-C with a lightning icon?
Picture of the back:
And the front has two more of those 3.0 type A ports, both labeled with the superscript 10:
I use the two “mere” USB-3 ports on the back for the mouse and keyboard. The type C ports go to other peripherals (one of them a printer). That leaves the front two, which I can actually SEE, for things like sticks, a plug in blueray, etc.
I think 00:14.0 is controlling the 4 standard USB ports, and 00:0d.x is only controlling the thunderbolt/USB-C port.
You can pass the 4 ports directly to dom0 and use them for mouse and keyboard, but without a port replicator you can connect to the USB-C port you lose the ability to connect any USB devices to qubes though sys-usb.
Totally.
That’s interesting because the two USB-C ports are the ones conected to peripherals, and I have no trouble hooking them up to my printer and a camera I operate in “tethered” mode, via sys-usb.
The thought occurred to me that this might explain why I can’t get the scanner (integrated with the printer) to work…but then I realized it does work with my Windows 7 qube. Still it might be worth an experiment some day; move the printer/scanner to one of the front ports. (From what I can see, the printer/scanner doesn’t see a “computer” on the other end of its USB cable when it’s a Linux qube. So it can certainly receive a print job, but it doesn’t think it has any place to send scan data to.) I gave up a couple of months ago on scanning into a Linux system; I just use Windoze for that.
You can use the thunderbolt ports in sys-usb, they should function as regular USB ports, you just can’t connect USB-A devices.
If all your devices use USB-C it shouldn’t be a problem.
Steve, I don’t know if you’ve resolved all your issues here.
I did notice that when you were testing, you said that you were locked
out after 1e - was this just a typo ?
You also say that d wont start by itself.
You didn’t say which ports are working when you started the qube with
only 00:14.0 attached. (I may have missed that.)
Can you confirm?
Actually since all of my peripherals use USB-A (only my phone has USB-C) I have bought a ton of female USB-A to male USB-C adapters. And I’m using them on my system as my peripherals are all quite old.
(For some reason, most of the adapters out there are the other way around…and you cannot get Google to NOT show you those even with quotes around the phrases ‘male USB-C’ and ‘female USB-A’; I’ve tried. I guess most people are finding themselves using new USB-C devices with USB-A outlets; unfortunately I’m in the opposite situation; my car is entirely USB-C.)
You can use rd.qubes.dom0_usb=00:14.0 if you want to attach it to dom0, and then add 00:0d.x to sys-usb.
That is similar to how I use USB on my desktop PC, I have connected the controller I have in sys-usb to the extra USB ports on my monitors to get extra ports.
I’ve “resolved” them to the point where I am back to refusing to mess around with sys-usb just because someone suggests I try experimenting.
I know I got no useful information from 14 (not 1e, though e is 14 decimal so that’s probably why I flubbed that). I think it’s because my mouse and keyboard froze; I simply don’t remember any more; I was doing a bunch of salt-related stuff that day (much more successfully). I can try again tonight. But I probably won’t. And as I said just trying to run 0d: simply resulted in it throwing up error messages in the balloon notifications.
Honestly I find it profoundly irritating that there’s no simple command that will show you which physical USB “socket” is on which controller (or alternatively, which physical device is on which controller, which would at least let me move, say, my printer around to each plug and look and see). Commands will show you “port” numbers for USB objects, or list controllers, but never connect the two. All I’m trying to figure out is which controllers control which plugs, so that MAYBE I can get my keyboard and mouse out from under sys-usb. It isn’t worth this donkey derby just to figure it out. I spent an hour and a half this weekend in a cold sweat because I couldn’t quickly figure out how to log in after I got locked out.
As a partial aside, I’ve been working on being able to build everything from minimal templates (and then “salt” them), and one of the three things left is sys-usb. I’m now questioning whether I even want to try that now.
I still haven’t established to my satisfaction, which controller owns which physical USB plugs on my system. That’s what I’m trying to accomplish, here.
No one suggested you at any moment to experiment. Everything we wrote was based on info we got from you and no info was wrong according to that. And we got it on the “tea spoon” like “pulling the teeth” from you. We still don’t know which NUC you have and I can bet there’s full info out there about your specific NUC in details.
Renehoj already told you which controller controls which ports, xHCI was never and will never be thunderbolt, so I really don’t know what is unknown regarding this anyway.
You were locked out yourself because you changed the name of sys-usb qube and didn’t change that in respected policy to allow keyboard and mouse to be passed to dom0.
Why at the end you created two additional sys-usbs? Wasn’t it enough to create additional one and to pass the other controller to it?
The easiest way was to leave xHCI to sys-usb and to assign 00:d.0 to a qube named sys-usb-d.
Everything would work then.
We just don’t know what you know, and more important - what you don’t know. And exactly the latter one brought you to lockdown.
There’s a Chinese saying: don’t do good if you don’t have to.
I couldn’t resist. I just have to post my favorite link.
I created two USBs, to leave the original in an unaltered state, so it’d be easier to go back to.
I was urged to “think” about my earlier statement that I couldn’t switch off controllers without shutting down sys-usb and removing them from sys-usb (which would be with a mouse and keyboard that just stopped working). That was the solution I came up with–create two non running qubes with one controller apiece, then I wrote a script to shut down sys-usb and start the two new qubes. Lockup.
I didn’t even know until now there was some line in policy I have to change, as well. (I could probably figure out which one, if were I in front of my qubes machine right now [I’ve done things to those files before]…but last weekend, I didn’t know to look for such a thing.)
You’re right…I didn’t give you a specific model number for my NUC. I had to look it up, myself, to find those pictures. I actually filed an HCL on it (that’s how I found out, since I’ve lost the quick start guide that came with it). But I don’t believe anyone asked for it either. All I got was comments that assumed it only had two total ports on it (which I said, no, it has six), then one asking about the lightning bolts…which caused me to bring in the pictures. (That was easier than unplugging everything and looking.)
There’s a Chinese saying: don’t do good if you don’t have to.
I’m not sure what the relevance of this comment is.
…It’s an Intel NUC 11 pro kit TNHi7.
And all I have ever been able to find in a spec sheet is the following:
(Under the heading USB configuration) Front: 2x USB 3.2
Rear: 2x USB 4 (type C), 1x USB 3.2, 1x USB 2.0
Internal: 1x USB 3.2 on m.2 22x42 (pins), 2x USB 2.0 (headers)
and under the thunderbolt heading:
1x Thunderbolt™ 4, 1x Thunderbolt™ 3
Not one word about the controllers.
I’ve changed the params in qubes.InputTablet and qubes.InputMouse to allow, in every possible configuration.
Are you looking in policy files by those names, or are you looking for those items in one of the numbered files like 90-*? (I ask because you said “in” those names which strikes me as possibly you found files with those names.)
The separate files are apparently the way older versions of qubes did things (and I wish they weren’t still part of the current distro, as they can just confuse people). As far as I know, altering those old files will have no effect. On the other hand, if you’re on an older version…just ignore this!
In these situations, please mention the first message and the future title of the split. Otherwise it’s quite hard for someone coming into the conversation to extract the context.
