I am also getting this on Fedora 31, SteamVR 1.10.12 - Mesa 20 git on Radeon 5700XT

Also started getting this problem recently. Came to see if it was an issue with the recent betas or just me.

I thought my HMD had died until I noticed the new dashboard appeared correctly for both eyes. Tried a couple of games and they worked fine.

SteamVR 1.10.12

https://gist.github.com/zurohki/94f95e80cd785a0d7358dcf1db847845

Got SteamVR 1.10.14 today and the colours are no longer inverted but the left eye is sort of washed out

This happened to me on 1.10.14 yesterday a few times when restarting, but sometimes a restart would fix it. However, it only happens in SteamVR Home. Games seems to work just fine.

Quick edit: I'm on Fedora 31 using XFCE, with an AMD RX 5700 and Ryzen 5 1600.

So, everyone having the issue uses a 5700 series card?

@Zamundaaa Can confirm, 5700 XT here.

@Zamundaaa I also have the issue on/off on a 2080ti, left eye has inverted colors.

I get the same thing here (GTX1060 + OG Vive). Seems to disappear if i relaunch SteamVR

Good to know it's not just a Navi or AMD problem.
I think I haven't seen the inverted colors in the latest beta though, only the tint.
It does sometimes work fine for me, too.

I get the same problem with a GTX 1080ti + OG Vive. Left eye has inverted colors.
I am using the latest SteamVR Beta.

I've found some SteamVR Home environments look right, and some are messed up. It seems like there's some lighting effects which aren't working properly, and environments that don't use those effects are fine.

1.10.15 that just came out seems to have fixed this issue

New dashboard fully works, as does binding room view to a double tap of the system button

I still experience this issue with 1.10.15. However, I have noticed (even prior to 1.10.15) is that the issue is not consistently reproducible. It usually occurs, but sometimes does not. Also, the visual impact of the issue varies as well. Sometimes the colors are downright inverted whereas other times it just looks like the colors are washed-out.

I still experience this issue with 1.10.15. However, I have noticed (even prior to 1.10.15) is that the issue is not consistently reproducible.

yeah I jumped the gun, just had it again

Also occurring for me.

• Distribution: Arch Linux
• SteamVR version: 1.10.7
• Steam client version: 1582328676
• Opted into Steam client beta?: Yes
• Graphics driver version: RX 5700 XT with Mesa 19.3.4 (LLVM 9.0.1)
• Gist for SteamVR System Information: https://gist.github.com/yaomtc/12fae1b56e7dc782b34d8197c655f3d0

Still there in 1.10.21.

And (as others have noted) it is not consistent. It sometimes renders normally.

I'm also experiencing this bug.

• Distribution: Kubuntu 18.04
• SteamVR version: 1.10.20
• Steam client version: Built Feb 11 2020, at 19:27:00
• Opted into Steam client beta?: No
• Graphics driver version: I have an RX 580, and I'm using the kisak/steamvr PPA. Running vulkaninfo | grep driverInfo outputs nothing. Here's the full output of vulkaninfo.
• Gist for SteamVR System Information: https://gist.github.com/Jayman2000/d1c13fa97aaccb276878e1a5fdbc7452

I'm also experiencing the same issue.

System Information:

• Distribution: Debian Testing (bullseye)
• SteamVR version: 1.10.23
• Steam client version: 03.03.2020
• Opted into Steam client beta?: Yes
• Graphics driver version: 440.59
• Gist for SteamVR System Information: https://gist.github.com/tdjb/87c19dd632c46e304eb6ec57bdd390f0

Same here. Only ever SteamVR Home, and then only sometimes; generally the left eye image is washed out, often without shadows, sometimes with noise.

System info:

• Devuan beowilf
• SteamVR 1.10.28
• Steam client dated 2020-03-09 (current beta)
• GPU: RX 570
• Driver: Mesa 20.0.0 (ACO enabled).
• HMD is Vive (original)

Same symptoms: left eye noisy / inverted sky color (and sometimes looks like only diffusion lighting is enabled).

System:

• Gentoo, Linux 5.46-gentoo
• SteamVR 1.10.28
• Steam client 2020-02-11
• GPU: Vega 56
• Driver: Mesa 19.3.2
• HMD: Index

I have (had) the same problem. I'd describe it as the left eye not having "advanced lighting": there are no shadows (e.g. from the controls/hands) on the left eye, In HL:A's Preview Location of City 17 "in the shadow of the under-construction Citadel" the sky is missing (black).

After upgrading my ubuntu kernel from general to lowlatency this went away.
This makes me think it is some kind of race condition with configuring. Definitely a software bug.

System:

• Ubuntu, 5.5.9-050509-general
• SteamVR beta 1.10.31 (or maybe 1.10.30, I changed kernels around that time).
• Steam client 2020-02-11
• GPU: RTX 2080 Super
• drivers: nvidia 440.64 + mesa/vulkan 19.2.8
• HMD: Index

The issue with the left eye being screwed up happens on plenty of environments. Skyboxes and lighting to not seem to work at all in the left eye. It's very unreliable, but happens most of the time. On rare occasion there are no issues on Pavilion, though the TF2 environment never once worked.

System:

• Arch Linux running kernel 5.5.10-zen1-1-zen
• GPU: GTX 980 running 440.64 + Mesa 19.3.4-2
• Steam: 3/19/2020 (Latest Beta)
• SteamVR: 1.10.31 Beta
• HMD: Original Vive

My conclusion from all of the above reports is that it is very likely a GPU initialization bug in openVR, or possibly steamVR. Does anyone have arguments against this conclusion?

This is a (probably GPU / Texture initialisation) bug in the Linux version / Vulkan VR path of Source 2, the engine SteamVR Home is built on.
OpenVR is the description of the runtime / the API applications use to communicate with SteamVR and neither the API nor SteamVR as the runtime have anything to do with this as it's not the full image that's affected but only certain parts to do with lighting.

Edit: actually, it looks like this bug is fixed in the latest beta!

It is not fixed (I still ran into it). And it is not going to be accidentally fixed either, aka not until this bug is assigned to someone and then fixed and closed. I am rather disappointed that nobody from Valve has comment here for so long. Since SteamVR is closed source there isn't much we can do to look into it, so they brought it up themselves that they are kinda obliged to fix it, imho.

@Zamundaaa Agree that it is likely that this is related to Linux and vulkan as combination, but I have no information on that this bug is restricted to linux and never happens in Windows. Can you tell me what the source of your information is?

I have to stress however that this has nothing to do with 'Home'. The lighting problem happens everywhere; it is just more prevalent in some environment than others. For example if it happens you will see it VERY clearly in HL:A since the sky turns black, but it is hardly visible in the Lab.

The best way to be 100% that the bug is not occurring is by looking if there is shadow of the hands on the ground: Keep you hands close to the ground and see if they cast a shadow on the right eye, if so: do they also cast a shadow on the left eye? Yes: no bug; No: yes bug.

Also, this bug has nothing to do with "initialization of a texture". It can't be since it is a lighting bug.. a texture is just ONE 2D image.

Absence of shadow is a reliable indicator. Presence of shadow is not a reliable indicator – I've seen the bug manifest with shadows being rendered normally.

Well on Windows SteamVR Home AFAIK (like HL:A) uses a DX11 renderer.

"Home" is the application where you have the environments, it's not the one environment. The "HL:A" you reference is just environments in SteamVR Home. It's interesting that you experience something like that in The Lab though, as it's made in Unity...
The error does not happen for me in the HL:A environments anymore and I did check 10 different environments where I consistently had the problem in the past and all was fine but today I randomly got it again on one start of SteamVR, it was too early to assume it was gone.

Also, this bug has nothing to do with "initialization of a texture". It can't be since it is a lighting bug.. a texture is just ONE 2D image.

Usually (meaning: if you don't ray trace it all) shadows are done with shadow maps that are rendered to a buffer (also called texture) on the GPU. If that texture is wrongly initialized or somehow made invalid effects like random contents (the noise) can appear or it's all read as 0 or unicorns or whatever... the behaviour is completely undefined.
This bug is not (necessarily) only that but if I had to guess there is a badly initialized texture and is with 100% certainty caused by a bug in the Source 2 code for Linux.

And it is not going to be accidentally fixed either, aka not until this bug is assigned to someone and then fixed and closed. I am rather disappointed that nobody from Valve has comment here for so long. Since SteamVR is closed source there isn't much we can do to look into it, so they brought it up themselves that they are kinda obliged to fix it, imho.

Welcome to the SteamVR for Linux bug tracker, stuff sadly does not work like that here. Some bugs get fixed without mention, very few are commented on (well, if they don't work on it then that wouldn't really make much sense either way tbh), some get fixed without being commented on and some just stay open and unsolved. It would indeed be nice to see some (more) commitment to SteamVR on Linux.

I've started testing 5.6 kernels (rc7 specifically) and I have not been able to trigger this left eye corruption all evening Not calling it fixed with a kernel update, but can anyone else install a 5.6 series kernel and see if they can trigger it?

(of note my whole VR experience seems smoother under 5.6 kernel anyway)

Just tried 5.6rc7 and the bug was still there.

same bug.

System Information: https://pastebin.com/g8WbvM3P

Works for me now.

The bug seems sorta fixed for me. The bug was still there on my first try, but, after restarting SteamVR a few times, it gone away.

I still have a general haze in both eyes with the TF2 environment, however. In the other environments I tested, everything works perfectly.

Still having this issue after two attempts, even with a full reboot in between.

System Info:
Distribution: Debian Testing (bullseye)
SteamVR version: 1.11.4
Steam client version: 26.03.2020
Opted into Steam client beta?: Yes
Graphics driver version: 440.66.03
System Information: https://gist.github.com/tdjb/0c96bf7abe684a0dcb65ad6af8a54a91

I was able to reproduce this issue with SteamVR beta 1.11.4.

System Information:

• Distribution: Kubuntu 18.04
• SteamVR version: 1.11.4
• Steam client version: Built: Mar 26 2020, at 22:46:20
• Opted into Steam client beta?: No
• Graphics driver version: I have an RX 580, and I'm using the kisak/steamvr PPA. Running vulkaninfo | grep driverInfo outputs nothing. Here's the full output of vulkaninfo.
• Gist for SteamVR System Information: https://gist.github.com/Jayman2000/79eec5849ce4a19316398c6c08f6f5ee

Seen on the latest SteamVR.

System Information:

• Distribution: Ubuntu 18.04.4
• SteamVR version: 1.11.5
• Steam client version: April 3 2020, at 22:37:31
• Opted into Steam client beta?: Yes
• Graphics driver version: Nvidia 440.64

I am able to reproduce the bug as well. Able to mitigate by triggering "restart headset".

STEAMVR: 1.11.5
HEADSET: Valve Index
OS: Manjaro Linux
KERNEL: 5.4.28-1-MANJARO
CPU: Intel Core i7-8700K @ 3.70GHz
GPU: NVIDIA GeForce RTX 2080
GPU DRIVER: NVIDIA 440.64
RAM: 32 GB

As mentioned previously, beta 1.11.4 has fixed the haze on the left eye and the skybox issues for me. Beta 1.11.6 appears to have completely fixed the haze issue in the TF2 environment as a whole.

• Steam client version (build number or date): Apr 8, 2020 at 20:52:25
• Distribution (e.g. Ubuntu): Arch Linux running the 5.6.3-zen1-1-zen kernel
• Graphics driver version (run nvidia-settings): 440.66.08
• Gist for SteamVR System Information: https://gist.github.com/llamasking/4e72006c6c1a0c97d836d77ba0785842
• Opted into Steam client beta?: [Yes/No] Yes
• Opted into SteamVR beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes

Yeah, this problem doesn't appear with 1.11.6 for me either (and did sometimes happen in 1.11.5 for me). The TF2 environment works properly now as well.

Can confirm that v1.11.7 fixed it for me as well.

Also not seeing this anymore.

seems to be fixed properly