Feature request: expose Pimax headset physical buttons as configurable SteamVR inputs

[Marantzi123]

Hello SBoys3,

Before explaining my request, I would like to sincerely thank you for the work you are doing with CustomHeadsetOpenVR.

I am currently using v1.3.0-beta.1 of your driver with two Pimax headsets:

• Pimax Dream Air Lighthouse
• Pimax Crystal Super with the Micro-OLED module and Lighthouse Faceplate

My system is primarily designed for VR simulation, especially iRacing, and uses:

• SteamVR as the active OpenXR runtime
• Lighthouse tracking
• A 6DOF motion platform
• A Vive Tracker 3.0 for motion compensation
• Eye tracking
• OpenXR applications such as iRacing

Your driver has produced excellent results on my system.

Thanks to CustomHeadsetOpenVR:

• SteamVR recognizes the Pimax headsets as native SteamVR devices.
• The pipeline feels lightweight and clean.
• Lighthouse tracking works correctly.
• I can retain motion compensation for my 6DOF platform using a Vive Tracker 3.0.
• Eye tracking works in iRacing when the simulator is launched in OpenXR and SteamVR is configured as the active OpenXR runtime.
• I have been able to integrate both the Crystal Super Micro-OLED and the Dream Air Lighthouse into the same SteamVR ecosystem.

For me, getting eye-tracking data into iRacing is especially important because it is essential for my configuration and potentially for current or future foveated-rendering implementations.

Your driver also directly influenced my decision to purchase the Pimax Dream Air Lighthouse. I used your affiliate code or link for the purchase as a way of thanking you for your work and so that you could also benefit from the sale.

The main issue that remains for me is the loss of the physical headset buttons while CustomHeadsetOpenVR is controlling the device.

With the standard Pimax runtime, the physical headset buttons, especially the + and - buttons, allow basic actions to be performed without using motion controllers, such as:

• Opening or closing the dashboard
• Accessing the desktop
• Navigating some menus
• Performing quick actions while wearing the headset

However, when I use Pimax Play EVO, OpenPort and CustomHeadsetOpenVR as a native SteamVR driver, these buttons are no longer available.

This creates a major ergonomic problem inside a simracing cockpit.

I am seated inside a motion platform with:

• A steering wheel
• Pedals
• An active harness
• A cockpit structure surrounding the user
• Physical movement from the platform

To open the desktop or access SteamVR, I currently have to:

1. Keep a Valve Index Controller inside the cockpit.
2. Find it without being able to see it while wearing the headset.
3. Turn it on.
4. Wait for SteamVR to detect and track it.
5. Hold it while the motion platform may be moving.
6. Point at the menu and use the trigger.

Apart from being inconvenient, there is also a risk that the controller may fall inside the motion platform or interfere with the wheel, harness or cockpit structure.

For this reason, my main feature request is:

Would it be possible to expose the physical + and - buttons of the Pimax Crystal Super and Dream Air as configurable SteamVR inputs?

The ideal implementation would be:

• Detect the physical HMD buttons.
• Expose them as SteamVR Input actions.
• Allow the user to configure their functions.
• Assign actions such as:
  • Open or close the SteamVR Dashboard
  • Show the desktop
  • Confirm
  • Go back
  • Increase or decrease volume
  • Execute a configurable shortcut

Even a simple initial implementation would be extremely useful, for example:

• Pressing the + button to open or close the SteamVR Dashboard
• Pressing the - button to go back or show the desktop
• Configurable long-press actions

It would also be very helpful to know whether the current limitation is caused by:

1. CustomHeadsetOpenVR
2. The OpenPort API
3. The headset firmware
4. Pimax not currently passing the physical button events through OpenPort

If OpenPort does not currently expose these buttons, I would appreciate confirmation. I could then provide Pimax with a precise technical request asking them to add this capability to OpenPort.

I am already discussing this issue with official Pimax Support as well.

For reference, I have personally confirmed the following:

• CustomHeadsetOpenVR v1.3.0-beta.1 works with my Dream Air Lighthouse.
• It works with my Crystal Super Micro-OLED and Lighthouse Faceplate.
• SteamVR recognizes both headsets correctly.
• Lighthouse tracking is stable.
• Motion compensation works using a Vive Tracker 3.0.
• Eye tracking works in iRacing OpenXR.
• The physical headset buttons are unavailable while the driver is active.

I still need to validate eye tracking in other applications, particularly Assetto Corsa EVO.

I would be happy to provide:

• Logs
• Screenshots
• Videos
• Testing with both headsets
• A/B testing between Pimax Play and CustomHeadsetOpenVR
• Button event or input-code testing
• Exact SteamVR, Pimax EVO, firmware and OpenPort versions

Thank you again for your work.

Your driver has turned these Pimax headsets into lightweight, flexible native SteamVR devices and has made possible a combination that is essential for me: Lighthouse tracking, eye tracking and motion compensation within the same pipeline.

Restoring access to the physical headset buttons would remove the main remaining ergonomic limitation of this configuration.

Technical environment:

• Driver: CustomHeadsetOpenVR v1.3.0-beta.1
• Headsets:
  • Pimax Dream Air Lighthouse
  • Pimax Crystal Super Micro-OLED with Lighthouse Faceplate
• Tracking system: SteamVR Lighthouse
• OpenXR runtime: SteamVR
• Motion compensation device: Vive Tracker 3.0
• Motion platform: 6DOF
• Confirmed eye-tracking application: iRacing in OpenXR mode
• Pimax software: Pimax Play EVO with OpenPort enabled
• Main missing functionality: physical HMD + and - button input while the driver is active

Best regards.

[mbucchia]

This was already done in #54 (and #56 for the LH version). The combined Vol+/Vol- is bound to /input/system while the headset side "double tap" is bound to /input/tap. Default bindings for those are set to open dashboard/lasermouse click and toggle passthrough respectively. I suspect this will be published in the next official release.

[Marantzi123]

Hello Matthieu,

Thank you very much for replying so quickly and for clarifying that this functionality has already been implemented. I would also like to personally thank you for all your work. OpenXR Toolkit has been extremely useful to me for years, especially in VR simulation, so it is a real pleasure to receive a response directly from you.

As I understand it, /input/system is generated when Volume+ and Volume− are detected simultaneously. On the Dream Air Lighthouse, the volume control appears to be a single rocker button. When pressing exactly in the center, I can feel a click, so I am hoping that this central press may activate both contacts at the same time.

Is this the expected behavior on the Dream Air Lighthouse, or would this model still need to be tested to confirm how the Pimax API reports its buttons?

I would be very happy to test it as soon as a build containing the Lighthouse implementation becomes available. If a test build exists before the next official release, I would also be happy to test it and provide any useful results or logs.

I would also like to suggest a possible future improvement: exposing all physical headset controls as generic and configurable SteamVR inputs.

In addition to Volume+, Volume−, the combined or central press, and the possible headset-side double-tap event, it might also be useful to expose the upper button currently used to turn the displays off and back on.

Its original function would not necessarily need to be removed. A short press could continue to control the displays, while a double press or long press could trigger an additional configurable action, provided that the API and firmware allow these gestures to be distinguished.

Ideally, the driver could expose:

Volume+
Volume−
the combined or central press
the headset-side double-tap event, when supported
the upper display or power button

And, where technically possible, distinguish between:

short press
double press
long press
perhaps triple press as an advanced option

These inputs could remain completely generic. CustomHeadsetOpenVR would not need to integrate any specific application directly. Users could assign actions through SteamVR bindings, keyboard shortcuts, or external tools.

Possible uses could include:

going directly to the desktop
opening or closing the SteamVR Dashboard
showing or hiding an overlay
triggering a motion-compensation action
starting a countdown before enabling motion
displaying SimHub or a motion-control panel
opening a hardware configuration panel
enabling a clean mode by hiding all overlays
executing any other user-defined command

My own use case is a simracing cockpit with a motion platform. In this environment, depending on a hand controller only to access the desktop or system functions is especially inconvenient and can even be unsafe.

However, I believe this could be useful far beyond simracing. It could also benefit flight-simulation users, people playing seated with a standard gamepad, users with accessibility needs, or anyone who wants to control SteamVR functions without constantly depending on motion controllers.

The broader goal would be to turn the headset’s physical controls into a small universal quick-access interface for SteamVR while preserving their original functions.

A small diagnostic section in the GUI showing in real time whether the headset is reporting:

Volume+
Volume−
both simultaneously
DoubleTap
the upper button

would also be extremely useful. This could make it much easier to validate differences between Pimax models and confirm whether pressing the center of the Dream Air rocker actually registers both contacts.

Thank you again for your time, for the quick response, and for all your work. I would be very happy to test this implementation specifically on a Dream Air Lighthouse and share the results.

Best regards,
Adán

[mbucchia]

Vol+ and - as individual buttons also change the volume, so I don't think it's desirable to overload them. On Pimax Crystal, pressing them simultaneously also "locks" as a single button, therefore not changing the volume. I suspect that's the same thing you described on the Dream Air.

The input mentioned in my comment are configurable in SteamVR. The driver ships a default configuration that does what I described, but this can be altered via SteamVR Settings to do other things.

[Marantzi123]

Thank you very much for the clarification. It makes sense to preserve the individual Vol+ and Vol− functions without overloading them with additional actions.

The solution you propose sounds appropriate: exposing the simultaneous or central press as a single configurable SteamVR button, with opening the desktop as its default action, while still allowing users to change it through SteamVR bindings.

The most important next step would be to confirm whether the Dream Air Lighthouse reports this central press in the same way as the Crystal. I will be happy to test it and report exactly which event is detected as soon as a test version becomes available.

If possible, adding a small diagnostic indication or log showing when Vol+, Vol− and the simultaneous press are detected would also make validation across different Pimax headset models much easier.

Once this basic input works reliably, other physical buttons or press types could be considered in the future, provided that the API and firmware expose them.

Thank you again for the explanation and for working on this implementation.

[mbucchia]

There's an input tester in SteamVR. Under Settings, Controller, Test controller. This also works for headset inputs.

I'm pretty sure sboys3 has already tested the change on DreamAir.

[kamil-malinski]

@Marantzi123 as a workaround and until the hardware buttons work I'm using this: https://github.com/mbucchia/SteamVR-Dashboard-KeyboardNav

for some reason it doesn't always work, sometimes you have to press the windows-key several times until the click gets registered, but eventually it will work