Jump to content

Problem with Controller Trackpad. Need some help


MWilliamGoody2303

Recommended Posts

The trackpad problem is there, tried on a much older Vive. I am pretty sure you will see the problem if you attempt to re-create it yourself. Could be the hardware to the controller but I believe it probably is connected to the code. You will experience the problem as long as the library that uses the trackpad is connected to this:

 

[unmanagedFunctionPointer(CallingConvention.StdCall)]
internal delegate bool _GetControllerState(uint unControllerDeviceIndex, ref VRControllerState_t pControllerState, uint unControllerStateSize);
[MarshalAs(UnmanagedType.FunctionPtr)]
internal _GetControllerState GetControllerState;

 

To find out if it isn't a code problem, someone would have to follow _GetControllerState, which I cannot. I don't know where the code is nor if I am able to look into it. When I highlight over it, I get:

 

Valve.VR.IVRSystem._GetControllerState(uint unControllerDeviceIndex, ref VRControllerState_t pControllerState, uint unControllerStateSize)

 

Of course I can't find that. But the return of VRControllerState_t is incorrect or the hardware is telling the code it's incorrect. The reason I suppose it is the code is from my belief in experience. After more testing I noticed it is possible to even get vector2 values such like 0.2f to 0.9f while the GetTouch() function return is still positive and nothing is touching it. My belief is the event of a getuntouch is missed and the functions return the belief of being touched when not. Workarounds? I am going to try GetPress() instead. If that becomes the same problem, well then that means the code is wrapped around the same similar design. There is not much I can do from this point because none of it I created or have access to address it. If it is a code problem, it can be fixed much more easily. Hardware... well that's a different story of course. I still believe it is the code though. I trust my gut on it being the code. I been programming for over 10 years and I can imagine how some of that code might be written causing this problem.

Link to comment
Share on other sites

  • Replies 60
  • Created
  • Last Reply
  • 2 months later...

I found this discussion by googling for the exact same problem. Same symptoms; both controllers do it, both SteamVR beta and non-beta does it, occurs in all games and Home. I've programmed firmware myself, so I have pretty good instincs for isolating a problem, and nothing isolates it. I agree with the previous commenter that this is almost certainly a bug either in the controller firmware, or the SteamVR API. This is precisely the sort of bug that I myself would have in my own code. I also am amazed at how little it's being talked about. It's annoying enough that I have changed my recommendation for people wanting to buy VR from Vive to Oculus.

Link to comment
Share on other sites

The behavior in Home, while looking at the virtual trackpad, is interesting when it happens. I lift my thumb, and the dot stays in place. Now I press my thumb at some other location that has some distance to the previous place where the dot is. I'd expect the dot to just kind of teleport to the other place. But it actually moves from point A to point B in a slow (in terms of what you expect from controller, not like snail-slow) and deliberate movement. It's as if the software or firmware has realized that there is something strange happening and is trying its best to recover from the situation.

Link to comment
Share on other sites

  • 3 weeks later...

Yeah, this is a common problem. I've had it for a long, long time. Resetting the controllers doesn't fix it. Maybe temporarily, but it's back pretty soon. I got a Rift as a supplement, but that has its own problems (USB and tracking issues).

Link to comment
Share on other sites

  • 1 month later...

,

I'm a developer of a VR application and I have confirmed this issue on 4 different sets of VIVE hardware and PCs. Due to what I can only assume to be a bug present in OpenVR/SteamVR the VIVE controller touch pad release event might not be registered until another input action is performed. This causes the touch pad to be in a touched state for longer than it actually was touched.

 

I confirmed this on both the latest stable and beta version of SteamVR. I don't think it is affected by distance between controller and HMD.

 

I wrote a tiny console application to easily confirm the existence of this bug which can be downloaded for Windows from GitHub (source code is available here).


Normal touch process

A regular touch event has a ButtonTouch event on begin and ButtonUntouch event at the end

--- TOUCH START ---[23.28] Event VREvent_ButtonTouch (202) - Age: 0.000013 - Button: 32[23.28] Device: 1 - PacketNum: 11506 - Touch: 1 - Press: 0 - X: -0.50331 - Y: -0.74837 - Trigger: 0.00[23.29] Device: 1 - PacketNum: 11508 - Touch: 1 - Press: 0 - X: -0.31482 - Y: -0.77153 - Trigger: 0.00[23.31] Device: 1 - PacketNum: 11510 - Touch: 1 - Press: 0 - X: -0.04536 - Y: -0.77014 - Trigger: 0.00[23.32] Event VREvent_ButtonUntouch (203) - Age: -0.000006 - Button: 32[23.32] Device: 1 - PacketNum: 11513 - Touch: 0 - Press: 0 - X: 0.00000 - Y: 0.00000 - Trigger: 0.00--- TOUCH END ---

Bugged touch process

A touch event that is affected by the bug will only have a ButtonTouch event at first.

Usually swiping across the touch pad with a slight touch for 10 to 50 times results in at least one bugged process.

--- TOUCH START ---[36.32] Device: 1 - PacketNum: 19213 - Touch: 1 - Press: 0 - X: 0.000000 - Y: 0.000000 - Trigger: 0.00[36.32] Event VREvent_ButtonTouch (202) - Age: 0.000810 - Button: 32[36.32] Device: 1 - PacketNum: 19215 - Touch: 1 - Press: 0 - X: -0.33845 - Y: -0.80251 - Trigger: 0.00[36.33] Device: 1 - PacketNum: 19216 - Touch: 1 - Press: 0 - X: -0.25579 - Y: -0.80251 - Trigger: 0.00[36.33] Device: 1 - PacketNum: 19217 - Touch: 1 - Press: 0 - X: -0.25579 - Y: -0.80740 - Trigger: 0.00[36.36] Device: 1 - PacketNum: 19219 - Touch: 1 - Press: 0 - X: -0.15010 - Y: -0.79756 - Trigger: 0.00[36.38] Device: 1 - PacketNum: 19220 - Touch: 1 - Press: 0 - X: 0.02383 - Y: -0.79756 - Trigger: 0.00[36.38] Device: 1 - PacketNum: 19221 - Touch: 1 - Press: 0 - X: 0.02383 - Y: -0.77761 - Trigger: 0.00[36.39] Device: 1 - PacketNum: 19223 - Touch: 1 - Press: 0 - X: 0.22799 - Y: -0.74648 - Trigger: 0.00

After the 36.39 timestamp the finger was physically released from the touch pad but OpenVR did not process the untouch event.

10 seconds later the trigger on the VIVE controller was slightly pressed and thus another input action was performed which in turn finally sends the ButtonUntouch event but way too late.

[45.93] Event VREvent_ButtonUntouch (203) - Age: -0.000009 - Button: 32[45.93] Device: 1 - PacketNum: 19226 - Touch: 0 - Press: 0 - X: 0.00000 - Y: 0.00000 - Trigger: 0.00--- TOUCH END ---[45.94] Device: 1 - PacketNum: 19229 - Touch: 0 - Press: 0 - X: 0.00000 - Y: 0.00000 - Trigger: 0.02[45.96] Device: 1 - PacketNum: 19232 - Touch: 0 - Press: 0 - X: 0.00000 - Y: 0.00000 - Trigger: 0.00

If you're a developer of a VR application I posted some hints how to implement a workaround for this problem in the README.md.

 

But hopefully this can be completely fixed with an update in SteamVR itself?

Link to comment
Share on other sites

I have tested my game with my CV1 Oculus and can't find a bug with any of the movement and their joysticks, using exact same code to SteamVR. This is only connected with Vive and the trackpad touch that I know of. While your work around is to monitor the touch press, we are doing an extra step we shouldn't have to. I wish someone would just fix it properly.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...