HackPerception

@jasper1234 - A couple of comments here: That SteamVR UI is generally a bit buggy when it comes to connection status and it isn't always accurate. I'd always differ to the main status UI or the tracker's LED indicator We used to have a tool called the "Vive Role Changer". It would modify the way the tracker's firmware reported to SteamVR and it would allow you to change between reporting a tracker or a controller. We maintained the tool for a while including updating it to support Tracker v2018 but changes to SteamVR's back-end ultimately led to the tool becoming too dangerous to use with Tracker 2018 - the procedure started bricking devices and we were forced to take the tool offline. We generally advise developers to correctly program their projects to work with the tracker in tracker configuration - it's not feasible or scalable to tell users to modify the firmware of their devices for a specific executable. If you have a first generation tracker, you can download v0.8 of the role change tool here. If you have a tracker 2018 (blue logo) - there unfortunately is no stable way to modify the device reporting status without a high risk of bricking it. These tools fall into the category of "use at your own risk" as it deals with firmware modification. Generally, SteamVR will not allow you to have more than 2 controllers connected without some custom back-end work.

@pavolmoro If you purchased the station through Vive via a Vive Pro Full Kit - you'd want to get the serial number off of the back of the unit and request a repair RMA via www.vive.com/support -> contact us -> contact us. That will put you in touch with an agent specific to your region who can book a repair RMA.

@sangyeop - SteamVR handles the location of the station's in a relative fashion. Borrowing from Steam's vr.chap documentation: Coordinates are specified in meters, where one of the base stations is usually used as the zero point of the coordinate system of a given universe (though ultimately all coordinates within a universe are relative to each other). Positive values on the Y axis are floorward, while negative values are ceiling/skyward. So there would only be a true origin for one unit (but it doesn't always center the universe around that point). I've asked our R&D team if they can provide a more specific location on how that coordinate system is being generated because I can't find anything from Valve on this matter. Hunting around, I've seen two answers from researchers: some say it's the center of the physical unit, whereas others say it's at the center of the window (facing the player - see here).

@KhantCaThing - I've generated a Viveport support ticket tied to the email address associated with your forum account. The code is on the large insert that's the first thing you see when you open the box; I've highlighted it's location in the image below.

@aa7696 - Is this this model? The spec page specifically says that USB-C port has DP support. I would generally recommend going into Nvida's Control Panel -> PhysX. It will show the port mapping on that laptop and allow you to confirm that the port is connected to the Nvida GPU and not just the integrated GPU. Some OEMs only wire their USB-C ports to the integrated graphics as a cost saving measure. Per the USB-C adapter you've linked - it meets the requirements on paper. I don't have any experience with that specific "brand" of USB-C -> DP adapter but it seems to be the same generic hardware that's sold under a few different brands. This is a similar generic brand which is sold/rebranded under the brand Nekteck on the US amazon store - it also meets the specs on paper.

@dNazarik - No, the SRAnipal (and the underlying Tobii backend) do not allow for images of the eyes to be collected or transmitted. I've copied the SRAnipal SDK developer agreement below: SDK Developer Privacy Guidelines: This SDK contains software which collects facial images and processes those images into user facial feature data for VIVE Pro Eye or other HTC VR products. Facial feature data includes eye tracking data (such as gaze position, pupil size and eye openness), but not actual images or representations of the face, eyes or lips. Facial feature data but not actual facial images or representations are available to the SDK developer. Information about how this SDK collects and processes facial feature data that the SDK developer can collect and use can be found in the Vive Eye Tracking section of the HTC Learn More page. We recognize the importance and privacy of user data, and to create a platform that supports these values we require developers who use this SDK to conduct the following self-review privacy checklist: - You must post a conspicuous privacy statement to users in your application disclosing the use of facial tracking technology and collection of facial feature data. Such privacy statement shall describe your collection and use of facial feature data, including what data is collected, how data is being collected and used, purpose of data usage, whether any data is shared with third parties, data retention etc. - You must keep your privacy statement up-to-date as you make changes to your data processing practices such as what type of facial feature data you collect, and how you use it or if you add new features and functionality to your application that may affect user privacy. - You must get explicit opt-in consent before you collect facial feature data where required by applicable laws. - You must only collect or provide access to facial feature data which is required to accomplish the task or functionality in your application and as disclosed in your privacy statement. - While this SDK might allow you to access certain facial feature data, you must not, and must not attempt to, collect, store, distribute or transfer eye image data. - You must not use any facial feature data, on its own, as an identifier to identify or recognize an individual. - You must not share facial feature data with third parties without user consent or otherwise complying with data protection law. - If you share or make available facial feature data to any third party, you must ensure that third parties comply with the same requirements in these guidelines. - If you collect or use facial feature data for profiling or behavioral analysis, you must provide a mechanism for users to reject profiling and behavioral analysis. - If you process facial feature data about individuals in the European Union, you must comply with all terms of European Union’s General Data Protection Regulation (“GDPR”) and any corresponding or equivalent national laws or regulations. - If you collect facial feature data of a minor (subject to the definition of children age under applicable laws), you must comply with applicable data protection laws meant to protect children (such as the U.S. Children’s Online Privacy Protection Act (“COPPA”)). - If you use, collect or process facial feature date for healthcare or health research use, you must comply with applicable data protection laws and relevant healthcare or medical regulations and determine for yourself if our product meets your compliance needs (we note that we are not and do not desire to be a business associate, under HIPAA, with respect to your application). - You must implement appropriate security measures to protect the confidentiality and integrity of facial feature data and prevent unauthorized access, use or disclosure, such as using industry standard encryption methods when appropriate. - Don't sell or license any facial feature data received through this SDK. - Don't use a service provider to process facial feature data you received through SDK unless you make them sign a contract to: (a) protect any facial feature data you received through us (that is at least as protective as our terms and policies), and (b) limit their use of that facial feature data solely to using it on your behalf to provide services to your application (and not for their own purposes or any other purposes). You must ensure they comply with our terms and policies (and you are responsible for their non-compliance). - Don't use facial feature data obtained through this SDK to discriminate (including based on race or gender) or make decisions about eligibility to participate in plans or activities, including to approve or reject an application or charge different interest rates for a loan. Published May 2019

We'd have to defer to Mozilla on this. They did make an offical blog post formally announcing Firefox Reality for SteamVR (desktop). It doesn't seam like it's been released yet based off their support page. Perhaps it's just slightly delayed? FFR is the default on Vive Focus - it does not appear to be available on desktop at all currently pending their previously announced desk release.

@Dicehunter - Mirroring the cellphone market, alot of this stuff is best left to third party accessory manufacturers who specifically specialize in aftermarket accessories. I'd generally recommend buying a "bust" like this that is hardware agnostic and can serve whatever HMD you're sporting on a given day. Beyond being agnostic, a bust will prevent sunlight from reaching the lenses and damaging the screens which other common stand designs fail to address.

Vive Community, We're seeing some reports from Windows 10 based systems that indicate that Windows 10's privacy settings can block communication between the Vive Cosmos' optical tracking cameras and the host PC. This has commonly been reported by the Vive Console under the following error code: "Cosmos camera is occupied by unknown application" In this scenario, we recommend updating Window 10's privacy settings to enable communication with the Cosmos' optical tracking system via the following steps: Within the Windows Start Menu or the Cortana Search Box, search for "Privacy Settings". Next, find and select the "Camera" tab and scroll down to "Allow desktop apps to access your camera". Please enable this option, power cycle the linkbox, and then restart the Vive Console.

@Bannschlag I've flagged your email address to a member of a care team within your region who can look into this and reach out to you. If you PM me the URL of the form you used, I can try try and verify that system from my side as well.

@Tarsuel, SteamVR is two components: the SDK/Runtime which is the software that drives communication between the game engine and the headset and SteamVR Tracking which is a hardware based tracking solution currently consisting of basestations and the sensors to detect their signals. The Cosmos is a SteamVR headset meaning it's natively compatible with SteamVR titles which are driven by the OpenVR/SteamVR SDK/Plugin. The Cosmos does not natively support SteamVR Tracking - neither the headset nor the controllers have the sensors required to detect signals from a base-station. We'll launch an external tracking mod in Q1 2020 to facilitate the headset being tracked by base-stations. The Cosmos is optically tracked - it's using the 6 cameras on the device to track the controllers as well as the HMD's position in 6DoF. You cannot hybridize a SteamVR Tracked device with the headset natively although there are ways to roughly accomplish this using existing SteamVR community-built tools but this falls outside of our current scope of support.

@Flashfire2205, the Cosmos (and it's default controllers) do not have native basestation (SteamVR tracking) support - it does not have the sensors required to detect signals from base-stations and it is natively an optically tracked device . We've announced an "external tracking mod" add-on faceplate for Q1 2020 that will enable the headset to be natively tracked via SteamVR tracking.

@yayumura To add some context, this is expressly not allowed as images of the iris are individually identifiable biometric data (meaning you can't change it like a text password). We're not allowed to provide access to these images per our technology licensing agreements with Tobii and per the T&C of the integrated solution in the Pro Eye headset. Here is the developer agreement for the Pro eye in full (May 2019):

@xPriime - Tom is correct, you need native Displayport 1.2+ support to drive the Vive Cosmos (or any current gen HMD such as the Index, Rift S, Pimax, Ect.... They all require Displayport 1.2+). And HMDI port cannot drive DP 1.2+; it's bandwidth is too low. @xPriime - What is your specific laptop's model number? I can take a look into seeing if there is a way to get a DP 1.2+ signal out of the available ports.

@VROne - Aside from the eye-tracking, they're both the same base-headset. We strongly recommend against consumers purchase the Pro Eye - it's an enterprise focused headset and almost all pieces content that you'd be launching as a consumer do not have the SDK's integrated required to drive foveated rendering or VRS. Previously, it could cost upto $6000 to modify a OG Vive with aftermarket eye tracking to drive foveation, the Pro eye reduces that cost dramatically while also providing an integrated solution. Eye-tracking is still not in the realm of consumer VR - there's still work to be done in the backend tech stack as well as in the front end legal and privacy framework and our implementation is currently geared towards enterprise use-cases and developers.

@Leo_BH @Vanityassassin @TomCgcmfc @DevDoc An official statement on wireless adapter and Cosmos has been posted here: https://blog.vive.com/us/2019/10/02/vive-cosmos-vive-wireless-adapter/

@ggvive000, I have a couple of notes on this: Focus/Focus plus are enterprise headsets - we strongly advise against consumers purchasing the Focus HMD - it's not a consumer product. It can only be purchased via enterprise.vive.com Focus is 3DoF - you'd need Focus plus and it's 6DoF controllers to being to approach parity for desktop usage We did announce a WiFi streaming solution to launch Viveport builds of SteamVR/OpenVR enabled content that is expected to enter early access in Q4 2019. That said, WiFi has limitations and our implementation is still not consumer oriented. In this case, rendering occurs on the GPU - the processor on the Focus is nowhere close to meeting the computational requirements to render PCVR content. Overall, if you're going to try and leverage the power of your PC GPU, you'd want to pick up a Vive wireless adapter to convert your desktop HMD into a wireless unit. The wireless adapter uses WiGig technology which enables multi-gigabit per second transmissions between the PC and the headset which is required to achieve quality parity to a tethered HMD.

@sixense - They're talking about a Vive Focus specific hardware issue and the WaveSDK forum is the default forum for Vive Focus hardware as it's the WaveSDK reference hardware. If we were to create a Focus specific forum, it would unfortunately lead to greater fragmentation of our community into harder to find subcommunities so for the time-being, Focus -> WaveSDK. Cheers,

@Terrence Campbell - This app sounds super achievable today using current headset and game engine technology. If you have the means, I'd recommend trying to start to prototype it out via Unity/UE4. There is a handful of companies trying to launch similar types of self-improvement VR apps but that crowd is small compared to gaming - one example is NewPathVR. Overall, there is definitely some level of consumer demand for this - it's hard to say how that market will play out this early on. I think the most important part about all of this type of stuff is to be very careful about what claims you make in your marketing and advertising - the FDA/FTC can come down pretty heavy on you for making health claims without the proper evidence & processes.

@Nemmy1234 - Please see my post here: https://forum.vive.com/forums/topic/5458-compatibility-vive-wireless-adapter/?tab=comments#comment-28313

@DevDoc @Leo_BH, Official statement on wireless adapter and Cosmos here: https://blog.vive.com/us/2019/10/02/vive-cosmos-vive-wireless-adapter/

@Zagagel - The limitation is hardwired into the adapter's WiGig components - there are 3 supported channels that the underlying Intel WiGig hardware is capable of outputting - regulations in China restrict those 3 channels down to 2 in that region. The two strategies for doubling channels in a closed environment are to strategically space the channels out apart as shared above so that they're far enough from one another that the signal propagation limitations (range) can be taken advantage of, or physically isolate play spaces from one another using a physical barrier such as a room partition.

@schwaBAM - The Cosmos is a SteamVR powered HMD and so it will be able to launch any application that has the SteamVR/OpenVR support - which by default will include all Vive/Vive Pro titles. The only potential support issue you may encounter is titles not having optimized Cosmos controller bindings. We're working with the developer community to ensure as many titles as possible have native binding files at launch and if you happen upon a title that doesn't have native controller support, SteamVR has remapping tools you can use to achieve a suitable mapping. You may notice in some apps that you'll see a Vive wand rendered rather than the controller - those types of assets are harder for developers to update and require more patching but they're aesthetic issues and shouldn't impact game play. If you're coming from an OG Vive, you may also notice on some older games that the texture resolution looks low on the higher resolution displays of current gen pMDs.

@Nemmy1234 - the cable is about 4.67m (~184 inches) from the linkbox to the cable guide at the back of the headband, and then another ~.25 meter or so from where the cable meets the headstrap to where it actually plugs into the HMD. Much like the Vive Pro and other current gen headsets - aftermarket extensions are not something that falls within our primary scope of support due to the specifications and constraints of the Displayport 1.X protocol. Displayport 1.x has length restrictions (which are mediated by bandwidth and latency). Extensions will fall into "mod" territory - advanced users will likely be able to find solutions for some use cases but overall it's not within the offical scope of support. Consumer HMD's push Displayport to the spec's limits. Our product teams are still finalizing some of the details on the Cosmos wireless attach kit - more info on that will come very soon.

@vasanthkalai - Lastly what's your SteamVR plugin version? That should be enough info to get the VIU team off on the right track?