This appears to be caused by a call to USBDeviceOpen failing with kIOReturnExclusiveAccess, indicating that the device is already opened for exclusive access by another process.

According to Apple's docs this is expected:

> Many types of devices are designed to allow only one process at a time to access the device. A scanner, for example, supports access by only one application at a time. Accordingly, I/O Kit families enforce the access policy for their devices, whether exclusive or shared. In addition, Classic (the Mac OS 9 environment that you can run in OS X) may expect its drivers to have exclusive access to some devices, such as USB devices. In the course of developing an application that accesses hardware, you may receive an exclusive-access error, even when you believe yours is the only process trying to open the device. When this happens, if there is no higher-level arbitration you can employ, you may need to present a dialog to the user and either try accessing another device of the same class or try to access the same device later or under different circumstances.

https://developer.apple.com/library/content/documentation/DeviceDrivers/Conceptual/AccessingHardware/AH_Handling_Errors/AH_Handling_Errors.html

I've noticed USBDeviceOpen failing with exclusive access errors in two general cases:

* When the device is first connected, trying to open it may fail. Usually, retrying after a short delay will succeed.

* If another instance of Chrome is running, the device may not be opened until the other instance is closed. If both instances are running when the device is connected, only one will be able to open the device. Re-plugging the device can change which instance opens the device.

I'm not sure which process is opening the device in the first case, but we can register for interest notifications to be notified when the device is available.

The second case is caused by exclusive access to the USB device. If one Chrome process opens the device the other must wait until the handle is closed. Unfortunately this is a limitation of IOUSBLib and is probably not fixable within Chrome. As a workaround, users can install a third-party driver (e.g., 360Controller) that allows XInput devices to function as standard HID gamepads.

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

commit 3e906dc4e4dcc331e10451069d785d7f13642425
Author: Matt Reynolds <mattreynolds@google.com>
Date: Tue Mar 13 19:47:47 2018

[Mac] Retry USBDeviceOpen on exclusive access error

On OSX, opening a device with USBDeviceOpen may fail with
kIOReturnExclusiveAccess if the device has already been opened by
another process. This CL checks for the exclusive access error and
waits for a signal from the OS that the device is available.

BUG=811480

Change-Id: I8ed3cd25e52e80ca1d6086e151a63b9df0e99e0c
Reviewed-on: https://chromium-review.googlesource.com/915018
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542886}
[modify] https://crrev.com/3e906dc4e4dcc331e10451069d785d7f13642425/device/gamepad/xbox_controller_mac.h
[modify] https://crrev.com/3e906dc4e4dcc331e10451069d785d7f13642425/device/gamepad/xbox_controller_mac.mm
[modify] https://crrev.com/3e906dc4e4dcc331e10451069d785d7f13642425/device/gamepad/xbox_data_fetcher_mac.cc
[modify] https://crrev.com/3e906dc4e4dcc331e10451069d785d7f13642425/device/gamepad/xbox_data_fetcher_mac.h