07-20-2018 02:57 AM
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.
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?
07-20-2018 11:54 AM
@pat_trickThanks for the tip! I thought about reporting this somewhere else than this user support forum but somehow all I could think of was the forums on Steam. Duh, opening a issue on GitHub is a no-brainer. I did so here: https://github.com/ValveSoftware/openvr/issues/833
07-24-2018 01:58 PM - edited 07-24-2018 02:13 PM
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.
07-24-2018 02:51 PM
07-24-2018 08:25 PM
Thanks for the clarification!
I updated my test tool to print out button presses/unpresses and for me button events can get skipped, too. I added this info to the reported issue on the openvr github project and changed the title from "VIVE controller touch pad untouch sometimes not registering until next input event" to "VIVE controller input events sometimes not registering until next input event".
This issue might be deeper rooted than I first thought but maybe a firmware update can fix this? It seems weird to me that this issue is not wider reported on. A game controller that can skip button events? Sounds like something that would delay the release of a piece of hardware not something that only gets looked into 2 years after release.
07-24-2018 09:21 PM
08-11-2018 01:21 PM
I can add i have the same problem, got the vive only a few months ago. first noticed it in google maps with the grip to turn would stick with me turning untill i pressed another button, thought it was just a bug in the game. then started to notcie it with the track pad more the more making free movement locomotion feel really strange and hard to controll. thought at first it was just me not getting used to the controlls but see that other people are having same issue.
09-06-2018 06:50 PM - edited 09-06-2018 06:50 PM
10-04-2018 07:35 AM
Just saw this in the release notes of the latest update. Time to get testing, people!
Vive Controller Firmware:
Well, unfortunately the problem has not gone away at the time of this writing. Nor did errors in bluetooth communication sound like a convincing reason, because I have yet to see an environment where it does not happen, or even happens less frequently. And I have tried in several locations, greatly separated. (As in, different cities).
What DOES affect its frequency is frame rate. For example in something very lightweight like Viveport, it happens infrequently. Perhaps after 30 attempts at sliding your finger on the trackpad and raising it. However, if there happens to be any stutter at the same time, such as a short error in motion tracking (for example, your vision moves for a few frames and then returns where it was) then it is likely to happen exactly then. Also, in heavyweight applications like the game The Forest, it happens much more frequently. Perhaps every five to seven times you slide your finger on the trackpad and then raise it. The difference in frequency of problems is extremely noticeable.
So, here's my theory: When the raise event happens on a frame that got skipped due to inability to render it in time, the raise event is lost with some significant probability.