3/3. Meta could bring hand tracking support to > 50% of PCVR headsets overnight by removing an arbitrary restriction - this would substantially change the cost/benefit of hand tracking for game developers.

2/3. More than half of the headsets on the Steam Hardware Survey are Quest-series headsets that have support for hand tracking, but it requires developer mode or third-party software.

*passing the CTS* on every release would be hugely valuable to everyone though , including runtime devs.

I need to write up my thoughts on this, but while the CTS is hugely valuable, I don’t see official conformance as useful to devs or users. IMO the primary benefit is the IP framework for official adopters

The CTS is free; official conformance requires adopter status and a passing submission (though there is a waive process). It does not require resubmitting or re-testing on new releases or new headsets

It's frustrating as a developer when I investigate crashes and see they're caused by a runtime bug that could easily have been detected before release.

It's frustrating for users when I have to tell them to hope for a fix from their manufacturer.

[5/5] This is clearly bad for developers and users - and it hurts the ecosystem as a whole; your readers/viewers deserve to know what they’re buying; don’t mislead them by saying headsets support OpenXR when they don’t.

[4/5]
- some vendors seem to stick with an old version of the test suite
- some vendors only seem to test their initial release, or only major milestone releases
- some seem unlikely to have passed any version, and only been spot-tested on a few games

[3/5] Some manufacturers routinely test their releases, and they should be celebrated for this: conformant runtimes make the whole ecosystem stronger and reduce locking.

I’ve unfortunately also seen a mix of:

[2/5] You can ask manufacturers what version of the CTS you should use - this should either be the latest version, or any other version published by Khronos that’s at most 180 days old.

Or the opposite, “We reward teams with fewer severe incidents” -> “hmm is this really worth opening an incident over?” “Is this really a *severe* incident?”, reducing communication and increasing time to fix and severity of incidents , even if there’s fewer labeled as “incidents”

Metrics often stop being useful once they become goals; rewarding productivity measured by number of commits can encourage spamming ridiculously small commits - eg one per file when one per concept might make more sense

Whatever restriction were hypothetically added, I could bypass them for $360/active development year, by moving to more invasive techniques and www.ssl.com/certificates...

or they could set HKLM\System\CurrentControlSet\Control\Class\{ADAPTER}\000X\VulkanDriverName to point at their wrapper; no kernel driver needed then.

Also, a lot of the worst ones come from hardware vendors, but aren't GPU drivers. They are already able to publish properly signed Windows drivers, and they do for other components.

If Windows did lock this down, they'd just publish a fake GPU driver wrapping the NVidia/Intel/AMD/... one.

I also disagree with 'how it should be':

If as a user, I install "Bob's Vulkan Tool", it *should* work with all games, not just games that decided they want to support "Bob's Vulkan Tool" - that's not the best for game developers, but it is the correct expectation for users and the overall system.