树莓派与HTC Vive Tracker的HID通信异常：SteamVR追踪失效咨询

Hey Sophie, let's break down your problem step by step and work through solutions to get your Vive Tracker working with both your Raspberry Pi and SteamVR simultaneously.

First: Confirm if the Raspberry Pi is indeed hogging the Tracker #

Your observation about /dev/hidraw0 is spot-on. If the device outputs data non-stop on boot but goes quiet after a reboot, that means a process on the Pi is actively opening and reading from the Tracker's HID interface. This exclusive access blocks SteamVR from communicating with the Tracker, which explains why it stops being tracked in SteamVR when the Pi is running.

How to find exactly which process is occupying the device #

Here are a few reliable ways to track down the culprit:

• Use lsof to list open files/devices: As soon as you boot the Pi and see /dev/hidraw0 outputting data, run this command in the terminal:

  lsof /dev/hidraw0
  

  It will show you the process ID (PID), process name, and user running the process that has the device open.
• Try fuser with verbose output: If lsof doesn't catch it, run:

  fuser -v /dev/hidraw0
  

  This will also display processes accessing the device, along with their ownership details.
• Check your udev rules for auto-run processes: Double-check the udev rule you created for the Tracker. If you added a RUN directive that launches a script or service on device connect, that might be the process holding onto the interface. Look in /etc/udev/rules.d/ for your rule file and verify no unintended commands are triggering on boot.
• Inspect startup services: Use this command to list all services that start automatically with the Pi:

  systemctl list-units --type=service
  

  Look for any HID-related services, or any custom scripts you've set to run on boot that might be accessing the Tracker without releasing it.

How to let the Pi share the Tracker with SteamVR #

Once you've identified the problem process, here's how to fix the conflict:

1. Adjust your udev rules to restrict access:
   Make sure your rule only grants access to your user/script, not system-wide processes. For example:

   SUBSYSTEM=="hidraw", ATTRS{idVendor}=="YOUR_TRACKER_VENDOR_ID", ATTRS{idProduct}=="YOUR_TRACKER_PRODUCT_ID", MODE="0660", GROUP="plugdev", OWNER="pi"
   

   Replace the vendor/product IDs with your Tracker's actual values (find them with lsusb). This ensures only your user and the plugdev group can access the device, reducing the chance of system services grabbing it.

2. Modify your script to use non-exclusive access:
   When your script opens the HID device, make sure it uses non-exclusive mode. If you're using a library like hidapi in Python, set the device to non-blocking mode after opening it:

   import hid
   device = hid.device()
   device.open(vendor_id, product_id)
   device.set_nonblocking(True)  # This prevents exclusive access
   

   For low-level file operations, use the O_RDWR | O_NONBLOCK flags when opening /dev/hidraw0 instead of just O_RDWR.

3. Disable auto-loaded HID drivers (if needed):
   Some Linux systems automatically load specific HID drivers for VR devices. Use lsmod to check for modules like usbhid or Vive-specific drivers, then blacklist them if they're interfering:

   echo "blacklist unwanted_module_name" >> /etc/modprobe.d/blacklist.conf
   

   Be careful here—only blacklist modules you're sure aren't needed for other devices.

4. Tweak Bluetooth profile connections:
   Vive Trackers use multiple Bluetooth profiles. Use bluetoothctl to check which profiles are active when the Tracker connects to the Pi:

   bluetoothctl
   connect YOUR_TRACKER_MAC_ADDRESS
   info YOUR_TRACKER_MAC_ADDRESS
   

   Look for profiles you don't need (like HID Input) and disconnect them, leaving only the profile your script uses for feature reports. This prevents the Pi from locking down the entire device.

Pro tip for log troubleshooting #

If you're still stuck digging through logs, narrow your search to relevant events:

• Check system boot logs for hidraw activity:

  journalctl -b | grep hidraw0
  

• Inspect Bluetooth service logs to see connection events:

  journalctl -u bluetooth.service
  

  Look for lines that mention your Tracker's MAC address or HID interface—they might reveal when and why the Pi is grabbing the device.

内容的提问来源于stack exchange，提问作者SophieOH