Thanks for filling the issue...

As per comment #0 issue seems to be VR related, not available at our end. Hence adding "TE-Hardware-Dependency" label to it and requesting respective team to have a look in to it for further inputs on it. 

Thanks..!  

klausw@, offenwanger@ - could one of you verify/investigate?

Variant on the issue.  In older Chrome, gamepads also continue to work when not in VR mode at all.  This is probably not too important in most production use, but is often helpful when debugging.

It would also be useful if the gamepads worked even without entering VR mode in the first place.  Logically, and in the API, gamepads and VR display are independent.  I can see that this may be difficult in the implementation when they are driven by the same hardware.

Raising priority since there are multiple related controller-related issues here.

Controllers only working for one session is apparently caused by mojo communication breaking when the render loop thread is stopped and resumed. When the second session is started, the isolated gamepad fetcher's have_outstanding_request_ is true, but the callback doesn't get executed.

For comparison, on the first session, have_outstanding_request_ becomes true when the non-immersive session starts, and the stored callback is executed by the mojo service's AcceptWithResponder after RequestGamepadProvider runs on the start of the immersive session.

The stored-callback approach for the isolated gamepad provider also seems to suffer from excessive latency, it appears that poses are reused for 2-3 frames. This is visible when holding a controller in front of your face while turning your torso, the controller image appears doubled or tripled and is noticeably laggy.

FYI, I filed issue 878181 to track the excessive latency separately.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d605bd014db7b9628b512a3eabbf375524133e2

commit 4d605bd014db7b9628b512a3eabbf375524133e2
Author: Klaus Weidner <klausw@chromium.org>
Date: Wed Aug 29 15:50:13 2018

Don't shut down OpenVR render loop on connection errors

A normal immersive session shutdown triggers this error handler,
and stopping the render loop lost a pending gamepad_callback_,
so future immersive sessions weren't seeing the controllers
anymore. Instead, keep the render loop running, it'll be cleaned
up when exiting the page entirely.

BUG= 875187 

Cq-Include-Trybots: luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I89a333a9cd104069d6e228248608957bec665a91
Reviewed-on: https://chromium-review.googlesource.com/1194252
Reviewed-by: Bill Orr <billorr@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587130}
[modify] https://crrev.com/4d605bd014db7b9628b512a3eabbf375524133e2/device/vr/openvr/openvr_device.cc

This should be fixed by r587130 in Chrome Canary >=  70.0.3536.0.

Thank you, I can confirm gamepads now working in 71.0.3552.2 when we leave and reenter VR mode.

As I mentioned earlier (comment 7), it would be good for development if gamepads could also work outside VR mode, as they used to (e.g. 67.0.3393.0)  Not a serious issue, though.