I absolutely have to get a Veikk device working on this machine.
Somewhere sys-usb is preventing some of the inputs from working. Without sys-usb the inputs work.
Other than:
/etc/qubes-rpc/policy/qubes.InputKeyboard
/etc/qubes-rpc/policy/qubes.InputMouse
/etc/qubes-rpc/policy/qubes.USB
What are the points in the chain where sys-usb might be blocking the Veikk inputs?
What is happening under the hood differently when sys-usb is deleted (and the device works) vs when sys-usb is installed?
/etc/qubes-rpc/policy/qubes.InputTablet
Without sys-usb the device is directly attached to dom0
I’ve changed the params in qubes.InputTablet and qubes.InputMouse to allow, in every possible configuration.
Even still the tablet does not behave the same way as when its connected to dom0. It is still stopping the mouse inputs.
There must be some other point in the chain that is different between a direct dom0 connection and connecting thru sys-usb?
Or the outputs from the device might be recognized as something other than a tablet or a mouse. Is there any other params that might affect USB devices?
Crazy idea…I’m stretching for anything that might work. Would it be possible to direct connect the Veikk device to dom0, and still port the other devices thru sys-usb?
You can do it with another USB Controller connected to dom0.
We all dream about the day it’ll be possible to create sys-usb’s per device and not per controller. But as far as I know it’s about the Xen and not Qubes?
I never was able to figure out how many controllers I have, let alone which actual physical port goes to which one. There are listings that LOOK like they might be multiple controllers, but trying to nail that down is like trying to nail jello to the wall. I haven’t looked at it in months, though, so my recollections on exactly what was confusing me are vague.
Oh–well duh. The HCL simply says usb: | 4.
In sys-usb itself it lists four things 00:0d.0, 00:0d.2, 00:0d.3, and 00:14.0.
That sure seems like a LOT for this dinky little box.
And I still have no idea how to tell which hole in the box is on which controller.
doing a qvm-pci tells me that 00:0d.0 is a thunderbolt 4 USB controller; d.2 and d.3 are Thunderbolt NHI #0 and #1, and 14.0 is “USB 3.2 Gen 2x1 xHCI host controller.”
I seem to recall vaguely that if you have multiple controllers, you can simply put your mouse and keyboard on one of them, and have that pass through to dom0 without sys-usb thereby avoiding the possibility of locking onesself out.
The box has two USB-A style 3.0 (blue) ports on the front, and on the back two USB-C ports and two USB-2.0 ports (which of course I use for the mouse and keyboard).
To me it’s pretty clear that you have two controllers: “d” and “14”.
Which port is which is easiest to confirm by attaching USB stick to each port and follow device widget.
So what, then, does it mean that there are three things with d (0, 2, and 3) and they are listed as different items in the device list in settings?
What do you mean by “follow device widget”?
If I open an Xterm on sys-usb and do an lsusb there are six buses and 11 devices; which buses go with d and which go with 14? No hint. How do you map lsusb to qvm-pci?
Plugging in a thumbdrive, I do see it get assigned a USB port…but I can’t tell which controller of the two (or four) it’s on.
The listing on qui-devices (the widget) shows me 3:2 which matches the bus 003 Device 002: from lsusb, but again…I can’t tell what controller that is.
You should create separate sys-usb for each controller, and name 'em for example sys-usb-d and sys-usb-14(or xHCI). Then it’ll be easy to follow visually via device widget.
Simpler still.
With the two sys-usb set up, start one.
Insert USB device in to ports - note which ones are working.pop up
notification will appear.
Shut down that usb qube, start the other.
Insert USB device in to ports - note which ones are working.
You may find that some controllers don’t apparently match any port, or
some ports are linked to two controllers.
former - controller is linked to internal devices.
latter - probably one controller is usb2, one usb3 in dual speed port.
@enmus @unman I can’t just casually start and stop sys-usbs because my keyboard is a USB keyboard.
What I’m getting out of this is there’s NO WAY to tell which device is on which controller without potentially freezing up my system. There’s no command to show the mapping, it just happens somewhere.
I didn’t say that.
SUre, you didn’t…but what happens to my keyboard when I am transitioning from one sys-usb to two?
In fact, just doing that will involve starting and stopping a controller, since I can’t remove the controll from one sys-usb, and assign it to the other without stopping the sys-usb.
Well, I tried.
I cloned sys-usb to two new qubes. Since they were turned off I could assign devices to them.
I then wrote a script to shut sys-usb down and start the two new guys up. (Before running the script I disabled the cron job I have that runs once a minute, it restarts sys-usb if it’s not running. I did that after one too many fat fingers in the qui-domains widget as it was shuffling the qubes it shows, and shutting off sys-usb and having to reboot.)
I found myself locked out of my system. After looking up the “qubes.skip_autostart” trick via my phone I was able to get back in, and tried some more experiments. d won’t start at all by itself; 1e locks me out.
OK, so do you have a more specific suggestion to make?
I don’t think you have multiple controllers. To me, it looks like you have one USB controller and one thunderbolt controller.
I have a laptop with a similar setup, the thunderbolt controller only controls the thunderbolt port, and the USB controller controls all the USB ports.
If your laptops work the same way, and you want to use it as two separate controllers, you are going to need a dock you can connect to the thunderbolt port.
What about your mouse? You can’t use it too?
What about your computer? Is it a laptop which both keyboard and trackpad are on the usb controller? Or, is it a desktop without PS/2 ports?
Edit: I didn’t see renehoj’s post prior to posting mine.