Third Update

Qwerty Submission

It seems that I’ve been a victim of the 90-90 rule with the last “tiny little details” of the Qwerty driver for Monado for emulating VR devices with keyboard and mouse. In my previous update I naively thought it was almost ready for submitting for review and that I would have extra time for other VR-related topics.

Even though I was naive, the MR is now published and awaiting review. In this post, I will talk about what things I originally overlooked that needed to be dealt with to make Qwerty worth publishing.

External Tools

For starters, I didn’t even have CMake files setup for compiling Qwerty. I was only using Meson. Both CMake and Meson were new for me as I’ve not used them for more than compiling other projects. So I took the time to learn a bit of the former (I already had learned a bit of Meson by that time) and adapt the project build files for my needs. Eventually, both Meson and CMake needed to be modified to conditionally compile Qwerty based on the presence of SDL in the system as this is now a dependency for the driver.

Regarding documentation, Doxygen has a considerable number of commands and functionalities to use, so I took the time to read through them and see which ones are the most used in Monado. In the process, I caught some missing documentation entities and opened a MR for that. When reading Doxygen documentation of other projects I always felt I didn’t quite understand how the contents were grouped and why they seemed to have so much redundancy. I now see how that works, the different concepts the tool uses (entities, groups, modules, member groups, sections, and so on) may not be very intuitive if you are not familiar with the definitions Doxygen assigns to them. Knowing how battle-tested the tool is I was surprised by my luck to run into a Doxygen bug that affected my use case.

Overlooked Features

These were all features I had not given enough attention but that when considering the submission of the driver I realized how essential they were.

Previously the driver had my keyboard ID hardcoded for probing Qwerty devices. Previously I had submitted a MR to make it possible to “auto probe” many devices at once because that would let me get rid of my hardcoded keyboard ID when creating the devices. I got to use this feature.

The controllers can now be optionally “attached” to the HMD (or “parented” to or “follow” it), if not you would need to drag each device to the location you want to go in the OpenXR app; first the HMD, then one controller and then the other. The usability of this feature together with the “reset position” one was greatly improved, and now it is possible to select exactly what controller you want to attach/detach or reset position. Unfortunately, this attachment feature does not work for non-qwerty HMDs (but hopefully it will in the future), which brings me to the next paragraph.

Qwerty did not work with other devices and with a second thought, you quickly realize that it would be a crime to not make it work and be a complement to other devices the user may have. It could fill any lack of devices for the user. They might only have the right controller, and Qwerty could provide them a virtual HMD and left controller. Or maybe they only have an HMD and qwerty provides them both controllers to try out interactions in their app. First I made it possible for the driver to work with external HMDs and then I reworked the input logic to flawlessly (at least in principle) work with any other devices. The catch in this is that I didn’t have any physical devices to try this out. The Monado Discord server helped me out with this, and I tested that everything worked with non-qwerty devices based on the Dummy driver. I hope this is working well with physical devices.

Other features that were already present in Monado that were of great help were the logging system, the ability to introduce an environment variable QWERTY_ENABLE to easily toggle the driver usage and, the coolest one I think, was the variable tracking UI. It let me with very little time implement a decent UI for the driver that makes it a lot easier to use for Monado users (though it is intended only for debugging and might be a bit unsafe).

Refactor

While implementing many features and changes to the driver I needed to better organize my files, classes, and methods to have a good separation of concerns. I created the qwerty_system to manage the driver-global properties and to organize the qwerty_hmd and qwerty_controllers which now derive from my original qwerty_device class. All of these now reside in the qwerty_device.{c,h} files as they are all friends of the qwerty_device.

I reduced the coupling of my driver with the rest of Monado as much as possible by, for example, moving all the SDL input logic into the driver to qwerty_sdl.c. The contra of this is that now the driver directly depends on SDL, though the SDL logic inside the driver is isolated and it should be easy to add new input logic using other libraries like XCB.

By this time my original branch had close to a hundred little and erratic commits because I was also using it to study and annotate over parts of Monado. So I redid the commit history before the MR to try and tell a story as concise as possible of the changes. While the MR ended up being a lot bigger than I would’ve preferred to not overwhelm the reviewers I hope the new change list is clear enough to help with the review process.

What’s Next

My classes start tomorrow and my time for VR will be reduced quite a bit so I need to narrow down my focus. I will be following up and making any adjustments the driver requires to get merged but whatever my next objective is I need it to be concise and relatively well defined. The topics I mentioned in the last post are still valid, though I need to first define my objective in the next few days.

I am very happy with the work I did with the Monado codebase and I think it will prove to be very useful for the next steps I take, whatever those might be.