Skip to content

Add Qwerty driver for mouse and keyboard controlled devices

Mateo de Mayo requested to merge mateosss/monado:mateosss/qwerty into master

About the driver

This MR introduces a new driver named Qwerty, which utilizes the SDL keyboard and mouse events that can be obtained from the debug UI (OXR_DEBUG_GUI=1) to optionally emulate an HMD, a left, and a right controller. It is disabled by default and it is needed to set QWERTY_ENABLE=1 for enabling it. When enabled, it should fill any remaining devices (from the three mentioned above) that the user may not have. For example, if the user only has a physical left controller, Qwerty should allow the user to move a qwerty_hmd and a right qwerty_controller through keyboard and mouse.

A widget for the qwerty_system is presented in the debug UI and shows information regarding the qwerty devices present at runtime. It also shows a help section for the user on how to use the driver.

Regarding usability, I took inspiration from Unreal and Blender walk modes. When using the devices, you can change your focus between the HMD, the left, and the right controllers with the CTRL and ALT keys. The device focused by default will change based on your particular setup (for example the right controller will be focused by default if the user is only using a qwerty right controller). There is a complete list of the keybindings in the Help tab of the Qwerty widget.

How it could be improved

Two features that are not implemented in this MR:

  1. qwerty_controllers aim inputs
  2. It is only possible to attach/detach the controllers to/from a qwerty_hmd. It would be nice for it to work with non-qwerty HMDs as well.

Some concerns

  1. I didn't have physical devices for testing the driver and only used devices based on the dummy driver for that. While I tested all possible combinations, it would be good to try it out with some combinations utilizing physical devices as well.

  2. I added a new xrt_tracking_type in ced329bc the second commit, the reasons are in the commit changes. Unsure if that was the best approach.

  3. The UI runs on a separate thread and so there are two threads accessing the driver. I didn't use locks because the most I think can happen is a misread value during a frame. However, if you see any more serious race conditions let me know.

  4. I didn't add the SPDX license headers as I am not sure how that works.

  5. Similarly with the proclamation fragments.

Please point out anything that might be out of place, even more so as this is one of my first MRs and some tools were new for me.

Edited by Mateo de Mayo

Merge request reports