OpenTPCast rumble only on one controller

Submitted by rdpeake on #1

I'm using an OpenTPCast to connect an oculus rift to a windows 10 PC. I'm asking this here rather than the tpcast discord as i think this is a virtual here issue?

The base TPCast runs with linux kernel version 4.9, but i have updated that to use 4.14 hoping that may result in better experience. I eventually found that upping the servers CompressionLimit to 800, up from the base 384 resulted in better tracking and somewhat better rumble response.

My issue is though, i am only ever able to get rumble from 1 touch controller at a time (at least in the game beat saber) when wired i can get both to function as expected. with a mod (which seems to be the solution many have found in the opentpcast forum) i can get a somewhat better experience, but that is simply because the the mod sends more vibrations allowing the 2 touch controllers to vibrate more interleaved.

Is this likely to be an issue with virtual here, or a limitation of the tpcast hardware (which is basically a raspberry pi 3, with usb 5ghz wifi) and is there anything i can do to help work out where the issue may lie?

Submitted by Michael on Sat, 2019/02/09 - 11:07

#2

Do you have more information about the "mod"? e.g a url or something

Submitted by Michael on Sun, 2019/02/10 - 08:43

#4

Are you using the tpcast router or your own router? I think its probably a latency issue. Although i havent heard of this issue before so it might be specific to your setup. If possible you could use your own router if you havent already. It might be better than the tpcast one as you have better control over the channel.

Submitted by rdpeake on Sun, 2019/02/10 - 11:11

#5

I am using the tpcast router - however i have seen multiple comments about this on the discord - it is the reason i even know about the mod option to reduce the issue. I also have the ability to control the 5ghz wifi band on the tpcast router? is there any test i should run to confirm the latency issues?

Submitted by Michael on Sun, 2019/02/10 - 11:47

#6

In the virtualhere client, right click on the TPCast Hub and select Properties and click "Latency" and it will draw a graph. You want 5-10ms and as flat as possible

Submitted by Michael on Sun, 2019/02/10 - 12:07

#8

Ok thats good, can you take another screenshot when you are using the rumble on the controllers

Submitted by rdpeake on Sun, 2019/02/10 - 12:25

#10

No idea if you have either an Oculus, or a TPCast/linux box to test with - but the simplest way to reproduce the issue is to open a song with obstacles and put both sabers into an obstacle. When running wired, both sabers will vibrate for as long as the sabers are in an obstacle. On tpcast - they vibrate very briefly then stop (how brief is extended by the mod i attached). However the moment you remove 1 saber from an obstacle the other one will restart vibrating like it would on the wired connection - and it doesn't matter which one you leave in, or take out. as long as there is only 1 in an obstacle it will vibrate as expected.

Submitted by Michael on Sun, 2019/02/10 - 12:30

#11

In windows, open Task Manager then Details and find vhui64.exe and right click and select Set Priority -> High

see if that makes a difference

Submitted by rdpeake on Sun, 2019/02/10 - 12:42

#12

Settings of high, or realtime didn't seem to make a difference (or if there was one it was only minor in terms of how long it was before the vibration ceased) however 1 saber still works, but 2 was not able to work.

Submitted by rdpeake on Sun, 2019/02/10 - 12:48

#13

For further test - i remove the rumble enhance mod - this indicates that there is no improvement as touching the 2 sabers together produces next to no vibration with high priority

Submitted by Michael on Sun, 2019/02/10 - 19:39

#14

OK im not sure what else to try. The latency seems ok as its consistent and 1-2ms should be ok. VirtualHere will pass all the signals it gets from the controllers so its definitely not dropping anything. You could turn off server compression or make it much higher threshold like 16384 instead of 800. Also you could use renice e.g -19 and see if that helps for the vhusbdtpcast process.

Submitted by rdpeake on Sun, 2019/02/10 - 19:57

#15

I have gone up as high as 2000 without seemingly any improvement (but i did need to increase it from the default to get better tracking) - i shall give a significantly higher value a try later (wasn't game enough to try that before as i wasn't entirely sure of the consequences). I shall also give renice ago and see what impact that has. I have spotted someone having issues with this on wired when they had connected the rift headset to a usb 3.1 (or 3.2) port on their mother board and connecting it via a 3.0 or 2.0 solved their issue.

I have also downloaded the oculus SDK and modified one of the examples given to cause both controllers to vibrate - and when doing that both were able to vibrate with no issue. This means the issue could lie in the OpenVR standard, or the Unity implementation which beat saber uses - but the problem doesn't seem to occur on wired so i still assume there is something involved in the virtual here which causes the dropout when 2 vibration calls are issued in game.

thanks for you help - i will get back to you on my results.

Submitted by rdpeake on Mon, 2019/02/11 - 19:03

#16

Running with renice -19, and 16384 compression did not change any thing - possibly some minor loss but the latency was still 1-2ms. As the tpcast is usb 2.0 and the virtual here virtual port registers as a usb3 device i connected the oculus wired via an active usb2.0 cable into a usb 3.0 header this however worked unlike the virtual here solution.

If i can help by collecting any logs for usb/network data i'm happy to help in that regard - i don't however know how to read them.

Submitted by Michael on Mon, 2019/02/11 - 19:34

#17

I had an idea, maybe its a power issue. Perhaps with two vibrating things its pulling too much power from the usb port. Maybe thats why it worked when there was a hub between...

Submitted by rdpeake on Mon, 2019/02/11 - 20:09

#18

Given that the tpcast is rated to supply 1.5A per connection (headset and video recieve) and the touch controllers are wirelessly connected to the headset and therefore run on their own battery - i'm not sure that would be the case. Not only that the oculus is barely rated to need the usb2.0 spec of 500ma power draw. whilst i can't say your wrong - i don't think power is the issue. Also when using the raw SDK i was able to have both vibrate at the same time - i am downloading the unity SDK to see if it is related to the unity sdk - or if it is game specific.

Submitted by rdpeake on Mon, 2019/02/11 - 21:21

#19

Running a very basic script in unity (which beat saber uses to my knowledge) has successfully caused vibration - so it does seem to be unique to beat saber - but it is also unique to virtual here and the tpcast.

Submitted by rdpeake on Mon, 2019/03/04 - 08:34

#20

Just want to add, in the last week or so - there have been more reports of haptic feedback issues whilst on tpcast (both virtual here and non virtual here) as well as beat Saber specific complaints - not sure it helps get to a fix, but at least we know it isn't specific to me, it may also not be specific to virtual here - but I don't know what software was being used for the complaints.

Submitted by rdpeake on Mon, 2019/03/04 - 17:36

#21

Hey Michael,

Do you know what would happen if the usb hardware on the embedded computer is being overloaded - as it is talking to a 5ghz wifi pumping a lot of data, as well as a device capable of usb 3.0 refresh rates of data - would the hardware controller loose the packets - and would that show up anywhere in longs (virtual here or otherwise)?

Going to look this up as well - but its about all i can see if the issues are consistent between stock and virtual here

Submitted by Michael on Mon, 2019/03/04 - 18:18

#22

Hi, yes basically when the usb bus is saturated, then some isochronous data maybe dropped by the USB bus. Isochronous packets are used by webcam and audio devices. Furthermore it will take longer for interrupt transfers to complete as the USB bus may make the device wait to complete the Interrupt/Bulk transfer if the USB bus is full. Interrupt transfers are used for HID type devices (probably like your haptic device) and Bulk is for pretty much everything else. There are also control type transfers but those i think have priority so arent affected as much as the other three types.

But usb devices never drop packets. Even the isochronous packets arent dropped but the data inside them may be or the usb device may return an error response to the isochronous request like "out of bus bandwidth" etc.

If you haptic fails over 5Ghz it could also be variable latency in the network. e.g it might send a message , "shake for 1 ms" but the message takes more than that time to get there before the next message etc.

Submitted by rdpeake on Mon, 2019/03/04 - 18:44

#23

I would think if it was variable latency issues it would be less consistent - where as i can reliably produce the errors whilst playing beat saber - which uses audio, and fast paced tracking. i would assume the requests are HID types - could they have a built in 'duration' based on the timestamp of the request - which if it takes too long gets ignored - and given the issue resolves itself ones a second device is no longer getting told to vibrate?

Submitted by Michael on Mon, 2019/03/04 - 23:49

#24

Take a look at the latency by opening the virtualhere client and right clicking on the TPCast Hub->Properties->Latency. Is it consistently low or does it spike ?e .g when there is a lot of audio or action in the game?

Submitted by rdpeake on Tue, 2019/03/05 - 01:25

#25

as i posted before it is consistent and very low

Submitted by rdpeake on Thu, 2019/03/14 - 00:54

#26

Looking further into this i'm thinking the issue may be to do with the linux usb stack somehow.

In dmesg i get a sequence of errors to do with resetting the device (err -71) - and attempting to look this up shows a host of people getting read error (-71) using 1.1 devices connected via usb 3.0 hubs.

Looking at lsusb with the oculus connected shows that the audio in/out and headset/controller tracking is all connected via 12M connections (usb 1.1 speed devices) but the oculus uses a usb 3.0 cable (and presumably hub). the majority of errors i saw involved a particular chipset which meant devices didn't work at all.

I have been attempting to get a device which has a working usb 3.0 socket so i can test to see if this is indeed the cause - but the chip i chose doesn't have enough kernel support (didn't realise an embedded board would be sold before it had kernel support at the time) to get reliable usb 3.0 connections working to test this step.

As i'm an inexperienced linux user - does any of this make sense to you?

Submitted by Michael on Thu, 2019/03/14 - 08:39

#27

If possible can you paste the exact section of error lines around the -71 error from dmesg. If its to do with a reset then virtualhere can skip a reset, if its to do with set address then there is no workaround. I wanted to see what exactly it is trying to do that gives that message

Submitted by rdpeake on Thu, 2019/03/14 - 12:39

#28

I can give you the exact messages once i get home - but from what i recall:

reset full-speed USB device number using dwc_otg -- last status line shown
followed by a series of the following:

hub_ext_port_status failed (err = -71)

cannot reset (err = -71)
Cannot enable. Maybe the USB cable is bad?

after which it eventually discovers a new device with a higher device id that those mentioned prior.

there were no read address errors that i saw - but i did see that following the errors it does completely re-discover the device.

I also plan to try using a ubuntu vm and connect the oculus to it via usb 2.0 and usb 3.0 to see if i can reproduce the same errors on there.

Submitted by rdpeake on Thu, 2019/03/14 - 19:00

#29

This may be a bit of a long post - so appologies for that.

First up - here is a copy of all the dmesg log associated with the error i was reporting before (minus some serial numbers): https://pastebin.com/fG1rYUaA

After doing this i attempted to connect the oculus to the following devices: Orange pi lite 2 (usb2.0), ubuntu 18.04 VM (usb2.0, usb3.0).

Initially - all 3 devices behaved the same - they all enumerated 2 HID devices connected to 1 device, no errors, but also not audio device was showing up.
I then stopped the virtual here service on the tpcast before connecting the oculus. checking dmesg here - i got the same output as the other setups i was testing. https://pastebin.com/ECwdN7U1

the moment i start virtual here again - the rift shows up in the client - connects, resets (and crashes) before showing up again, and a few moments later the audio device shows up. with the same error output as linked at the start of the post (just with a longer delay after the first detection, before the reset to the usb device which is what causes the headset to reset.

Noticing this, i played around with the ubuntu VM and on usb2.0 i was able to produce error 71 read address issues associated with low power (which was my experience trying to use the headset on usb 2.0 un powered up without the vm)

Connecting via usb3.0 and running virtualhere on the vm (which is x86_64, using uhci_hcd instead of the dwc_otg the raspberry pi is using) i still only got the rift device - no audio device - until i said to use the device in the client - this caused the device to reset... and then do nothing... Once i set it to auto use the oculus it reset - i reconnected it to the VM - and then it enumerated with the audio device as well.

I attempted to use this setup to play beat saber - and - other than there being delays on rumble, the rumble did work in more places - i think it worked as it should, but delays on the rumbles make that hard to determine. however - see this dmesg log for this interaction: https://pastebin.com/6cBJJcE7

hopefully this information is useful - and if you want me to do any other tests/configurations please let me know. a bit of a noob when it comes to linux under the hood - but programmer by trade so i can usually follow directions, or look resources up as needed.

Submitted by Michael on Fri, 2019/03/15 - 09:43

#30

In the virtualhere client, click on the oculus and then select Custom Event Handler... then paste in

onReset.$VENDOR_ID$.$PRODUCT_ID$=

then press OK. Now repeat that for each device listed.

Then unplug/replug the occulus and then try to use them via virtualhere. Does that show improvment? All resets are skipped by virtualhere and not sent to the device.

Submitted by rdpeake on Fri, 2019/03/15 - 12:41

#31

Hey Michael,

i put that in - and here is the pastebin of the dmesg (which looks fine, though i was surprised the audio came up given it seemed to require the device to be used before the audio shows up): https://pastebin.com/g8y7bwhW

Though looking higher on that interaction though: https://pastebin.com/UvvCbpCL i don't see the errors i listed before happening even with the reset message coming.

Having used the oculus with this setup results in no improvement to the vibration (and given the update recently, no mod helps yet) it still does not respond well to vibration.

I'm hoping the current dev work on the armbian image for the orange pi i have with usb 3.0 host support means the next nightly will allow usb 3.0 to work and i can test my theory about linux and usb 1.1 speed devices connected to usb 3.0 hubs

Submitted by Michael on Fri, 2019/03/15 - 13:00

#32

Ok yes i think it must be the kernel issue then...let me know if the orange pi with the new kernel works..

Submitted by rdpeake on Fri, 2019/03/15 - 21:20

#33

Ok so i was able to get the orange pi and usb 3 to be recognized - but no difference was experienced in game (though the overall exp was somewhat better on the newer hardware) - dmesg log and lsusb output: https://pastebin.com/ZA5q9KAF

The interesting thing about this though - the oculus only has a super speed usb hub connected to the usb 3.0 lanes - with the same vid/pid as the hub on the standard lanes (or so it appears from the dmesg output) but this seems to disconnect when virtual here is connected, and does not reconnect - nor get forwarded. on top of that - it does mean that aside from a random usb 3.0 hub - the usb 2.0 socket should result in the same use case as a regular oculus connection - but we have a difference in the output of the vibration.

I decided to take images of the windows device tree as well for the oculus both direct connection and virtual here (via orange pi - 2 devices individually, and tpcast 2 devices combined).
orange pi audio: https://www.dropbox.com/s/4d6vdu7tt3vehjr/rift%20sound%20devices.PNG?dl…
orange pi input: https://www.dropbox.com/s/on1xmau9vwpxtb9/Rift%20inputs.png?dl=0
tpcast combined: https://www.dropbox.com/s/zk81vtttbwjcyco/rift%20inputs%20tpcast.PNG?dl…
rift direct con: https://www.dropbox.com/s/zo95u6khx6fsh7f/rift%20inputs%20direct.PNG?dl…

I also get the same exp connecting the oculus via the orange pi 2.0 socket.

So i decided to connect the oculus to the VM instance of linux i have running and use the command line virtual here. after connecting the device - the associated dmesg and lsusb are here: https://pastebin.com/mqdqQty2

What i notice with this, the usb connection state is slightly different - the usb root hub - which is part of the oculus - is not present - given that it isn't generic, but has rift specific keys, i wonder if this is significant, or just me chasing any explanation i can find...

Submitted by Michael on Sat, 2019/03/16 - 11:49

#34

I dont pass through usb hubs, so it will be missing when passed through via virtualhere.

Submitted by rdpeake on Sat, 2019/03/16 - 22:07

#35

Given the devices here: https://usb-ids.gowdy.us/read/UD/2833
And that the oculus is able to detect if you are connected via usb 3.0 (presumably by detecting if a usb device with the 3031 product id is present on the system) would there be anything associated with this which could cause the HID vibration to function differently?

Given that i am fairly certain power is not an issue (directly connects to the same source powering the pi, which is 2.4A portable battery pack socket), and we know latency of the virtual here connection should not be an issue (as it is always under 2ms and fairly consistent) is there anything else i can do to collect data that could help indicate why it would seem vibration ceases (and is repeatable on different devices and by multiple users) when Beat saber tries to control both vibration motors at once - but the situation works when connected via cable?

When using stock firmware - which runs usb network gate - this issues is also present... so either there is something at the kernel level (any idea how to test for that) or both software miss something that oculus cares about. possibly custom firmware in the usb hub idk... and if it is the hubs - how hard would it be to have virtual here forward both the hub (if it has a vid of 2833) as well as it's connected children - even if its just a test build?

Submitted by Michael on Sat, 2019/03/16 - 22:29

#36

There is not much public information about the exact messages a usb devices sends. Most would work closely to a USB spec like HID or Audio etc but they almost always have extra commands to do their special things e.g set/read registers poll some status , and those are never documented. So its impossible to know exactly what messages need to be sent when. You can use a hardware usb analyzer which would tell you all the messages but you would have difficultly decoding all of them exactly. Most would fit into the usb class spec like i mentioned but others e.g control messages are not documented.

Submitted by rdpeake on Sat, 2019/03/16 - 23:16

#37

I assume that virtual here just forwards any message on - based on the vid/pid pairs - which would basically mean any messages sent to pairs not on the stack wouldn't be forwarded - which is why my question about forwarding a hub - which has a vid of the same company is possible without excessive effort on your part to see if it is trying to do something with a 'hub' as a special tool or if it is something else. I obviously don't want you to spend time on a test for no gain - especially if there are other ways to verify. i can do wireshark of the usb devices when connected via cable, and vibrating both motors - if i can work out how to determine if the hub is getting any messages (unless every message will include the hub because it is the parent of the devices recieving messages) i obviously don't care what the messages contain, as long as i can work out what is getting the message, or why something isn't getting a message.

Submitted by Michael on Sun, 2019/03/17 - 08:49

#38

The hub is not important in the device tree because its pretty much transparent to attached devices.

What you could do is capture a wireshark trace of the devices vibrating when directly connected to the pc and then via virtualhere. And see if you can see the difference. There will probably be many messages so it might be tough to filter but if you can get down to just that HID device at that time and the messages sent/received it might be a clue. I dont have an oculus to test with otherwise i would have a quick look myself.

Submitted by rdpeake on Sun, 2019/03/17 - 16:10

#39

Ok, i'm a little over my head with the outputs of the wireshark - however, when you say the hub is transparent to attached devices - that may be true, but the hub is not invisible to the host, and it could send commands to the hub if it is running custom firmware (and the fact that it has oculus vender id's makes me wonder if they've done more than alter the vid/pid on the hub chip). the direct connection seems to talk to the usb3.0 hub all the time, until vibrate requests start for example.

Looking at the outputs though - when vibration requests start - i go from communicating with 1 device to communicating with entirely different devices (usually with a .0 extension which i took to mean was the root hub?)
directly connected: https://www.dropbox.com/s/cl16xbtpyxsd2ap/direct%20vibrate.PNG?dl=0
tp cast connected: https://www.dropbox.com/s/4hpwhsaf76qq0fq/tpcast%20vibrate.PNG?dl=0

here is a link to the wireshark trace if you can make better understandings of it. unfortunately the direct connection also had a bluetooth radio and UPS connected at the time so those instructions do show up in the trace.
tpcast: https://www.dropbox.com/s/qqhy5dszroldjv2/tpcast-just%20vibrate.pcapng?…
direct: https://www.dropbox.com/s/m4xakasapx3w7ij/direct-just%20vibrate.pcapng?…

However, the fact that i spend a lot of time communicating with 6.0.1 in tp cast case - with the hid on 6.0.1 and 6.0.2 (i assume this is audio) but then talk to 6.0.0 when combined vibrations start, and 5.8.1 (presumably the usb 3.0 device) and the hid devices are on 5.7.1 and 5.7.2 (again, assume audio) but then send to 5.7.0 when vibration requests start...

Either i'm missing something (which is highly possible, i'm learning as i go here trying to work out why vibration is significantly different when wired compared to tpcast) or the hub may have significance to the oculus software even though the end devices don't care about how they are connected.

If you think this is lower level than virtual here - then please let me know who to communicate with to attempt to resolve this at their level, or what more i can do to get you debug data so you can determine what may be the cause.

Submitted by Michael on Mon, 2019/03/18 - 09:36

#40

OK yeah i dont know sorry, i dont know what those usb packets are meant to be. I was hoping it might show an error message instead of just packets of data.

Submitted by rdpeake on Mon, 2019/03/18 - 11:42

#41

How hard would it be - to entertain my crazy idea that oculus is doing custom stuff with their hub firmware - to forward the usb hubs in virtual here as a test build?

Submitted by Michael on Mon, 2019/03/18 - 11:46

#42

No i cant easily do that because now all windows drivers must be signed by microsoft so i have to put my driver through a test run with microsoft (HLK) which is very time consuming and not easy.

Submitted by rdpeake on Mon, 2019/03/18 - 11:59

#43

Even if i were to enable installing unsigned drivers?

Submitted by Michael on Mon, 2019/03/18 - 12:20

#45

No im not spending hours doing this for a 25 dollar product. its not viable

Submitted by rdpeake on Mon, 2019/03/18 - 12:23

#46

understandable - but thanks for at least trying to work out a cause. even if we didn't find one.

Does the virtual usb hub on windows show logs of commands it is sent that are not forwarded to a virtual device (or that target the hub itself?)

Submitted by Michael on Mon, 2019/03/18 - 12:42

#47

The issue is basically that even if you trace all the messages and i spend hours getting the hub to passthrough its not going to help much because you dont know the protocol of the device. This is the core problem, usb device protocols are basically hidden this is why so many users use virtualhere (including large companies who are customers of mine) because the protocols are not known so they cant just communicate with the device at a higher level directly.

E.g this is why wireless xbox controller passthrough and wheel passthrough etc use virtualhere and the tpcast devices. Companies like Valve and HTC themselves dont know the protocol of the all the usb devices exactly, manufacturers dont tell them and dont tell me because its proprietary and they are busy working on the next product.

This is why adding the hub through is futile, you might end up with some extra messages but then what? How are you doing to translate them? I have worked on this stuff for large companies and its a very slow process that can take weeks/months.

To make things more complicated the windows kernel can issue usb messages out of order due to requests taking place on kernel threads. So a usb device communication takes place slightly or a lot differently for each run usually. They may not be able to be directly compared.

There is a hidden state machine inside the driver and a hidden one inside the device. So for example the HID device like the trigger you are talking about might have a state machine say vibrate to 1ms then stop when you get the next msg . but that msg is delayed more than 1ms and the device doesnt know what to do and might do nothing or stay on vibrating. I have seen this occur on some devices like wheels where there is insufficient spare cpu cycles or the wifi network is heavily congested.

To add an additional level of complexity some devices dont even do anything until firmware is uploaded on boot then they change characteristics and become another device. So when you trace messages you need to skip those particular messages and prevent reset from occuring

Submitted by Michael on Mon, 2019/03/18 - 12:48

#48

Heres an example of what im talking about inside the linux kernel. There is a special driver for logitech devices that is added to as logitech devices are developed and decoded by hackers People add workarounds etc as they are discovered. Note at the top there is no help from logitech. Its all just normal people writing this stuff. Its a very similar thing to your issue

https://github.com/torvalds/linux/blob/master/drivers/hid/hid-lg.c

Submitted by rdpeake on Mon, 2019/03/18 - 13:01

#49

But my intention is not to hack the protocol in any way - it is simply to work out why - when using the tpcast and virtual here the devices connected function differently than when they are wired directly - looking at the output of the wireshark log - it looks like the oculus software is directly communicating with the hubs (in some way) as part of it's functionality. for example, the oculus only shows up as a usb 3.0 device within oculus when the usb 3.0 hub is connected - but it has no children. i cannot forward this device via virtual here either as it does not support usb hub forwarding - but obviously the oculus software is registering the hub is connected - and from what i can tell in the packet sniffing - is communicating with the usb 3.0 hub even though it gets responses on the usb 2.0 devices.

Or are you saying that - in order to forward the hubs - we would need to understand what protocol they use internally - even though we are just treating them the same as we are other remotely connected devices - and passing the raw commands directly through without understanding the protocol?

Submitted by Michael on Mon, 2019/03/18 - 13:17

#50

Sorry when i mean "hacker" i mean people who spend lots of time reverse engineering a protocol in order to figure out how to communicate with a device where the protocol is unknown. The way a usb hubs works is that an request is sent from the operating system into the hub to complete when a port changes state. That is probably the messages you are seeing. They come from windows operating system requests very likely. Although possibly the oculus drivers might also call the hub for some reason. I suspect not because a hub usually is just a hub but maybe it does something extra like power functionality. Sometimes hubs provide extra functionality to group devices into a common container. They would return certain descriptors to provide a container ID and the driver could query on that e.g to find attached devices it is expecting to see. (The hololens does this).

To basically summarize, the usb protocol can be extremely complicated due to the dearth of information about devices and the timings involved. So its basically pointless trying to figure out the difference without knowing the firmware inside the usb device exactly. If you had the full source to the firmware inside the HID trigger or the oculus drivers then its maybe quite fixable. But there is no chance you could get that info first as its proprietary.

Submitted by rdpeake on Mon, 2019/03/18 - 13:36

#51

Why would it be communicating with the hub at the same frequency it is receiving hid responses from the connected devices though - especially when the hub has no children (and also when using virtual here - this device id is replaced with the usb 2.0 equivalent). also i don't see any direct communications to the other devices in the usb 3.0 case that would explain how it is sending audio and vibration requests that are not the 'both sabers at once' which causes beat saber to not vibrate properly.

Also - the big change that happens based on the wireshark sniffing - which is consistent on both setups - it goes from sending to x.x.1 (usb 3.0 or 2.0 depending on which is connected) to x.x.0 (always the usb 2.0 device even when connected via usb 3.0)

to be fair - this is what i suspect is causing issues - but i don't understand how different device endpoints affect virtual here - and i was assuming .1 was the first child and .0 was the hub directly - having read up on how usbpcap reports device addresses i may be wrong, but at that point i don't understand what endpoint id's mean - and if that is something virtual here is missing (or is outside of specified protocols). which is why i was thinking 'if we just forward the hub as part of the pass through of virtual here' any comms to the hub (which i thought 'x.x.0' was referring to) would make it un-altered. according to usbpcap - the 'x.x.0' device would be the same one that reports the VID/PID combination. Again, you're showing you probably understand what that means far better than i do.