Can confirm, the controllers have ghosting as if they're interpolated. Also the headset movement is delayed, which makes me sick after a few minutes. It's like the world moves around you, instead of you moving around the world.

Performance and latency aren't currently expected to be optimal when a VR application is running, but should be comparable to the Windows version in the default SteamVR environmnent. Is anyone seeing subpar performance when no application is running?

@Plagman The SteamVR environment works great - it's a night and day difference vs the tutorial.

@Plagman I first noticed the issue in the SteamVR environmnent, from the first time I started it. Isn't obvious as in Destinations or SteamVR Tutorial because is mostly an empty space but, if I turn my head looking at the chaperone or a lighthouse, I feel that something is wrong.

yes, at steamvr enviorement works correctly, it's when a application is running that delay appear, as more consuming more delay. At serious sam i have a huge delay at tracking, more than tutorial.

@Plagman I can confirm this is happening on my system, too. The tracking is noticeably slower (or it is my perception as slower). I've noticed this delay in the SteamVR environment from time to time, too... But it happens in every application, period.

I tried updating my kernel to last 4.9 and disabling desktop effects on kde, but still the same.

@Plagman I can confirm the tracking inertia. It appears in every application (including really simple Unity scenes) except the empty default environment of SteamVR. After loading a custom 3D obj-based SteamVR environment (for example the Rick and Morty garage) the latency get's noticeable there, too.
~Since the delay seems to be the same everywhere, I guess that it is not dependend on the application performance itself and maybe lies somewhere in the tracking data pipeline.~ The latency is not present in the display mirror (Chaperone grid and Unity scenes move synchronously and align perfectly) and only inside the HMD.
Also, the Chaperone bounds are never lagging. This feels similar to the the latency problem with UE 4.12.

The March 6th build of SteamVR makes this much worse for me. I'm running the .13 Nvidia driver, too. Now, the steamVR environment really shows this much worse.

The March 10th build seems to be moving in the right direction. The SteamVR environment still lags (noticeable when moving your head up and down, less so when right to left, but it is much better than before.

I'm noticing this with the March 16 build as well, especially if you stand still and wiggle your head a little -- the delay is considerable enough to generate nausea (in the StemVR environment). In the SteamVR tutorial, the delay is exaggerated even more so. Running Ubuntu 16.10 x64, Nvidia GTX 980ti w/ 375.27.13 Vulkan proprietary drivers, Unity 7.5.0 desktop environment, Linux kernel 4.8.0-39-generic.

I still experience this issue. Performance seems fine, but everything is noticeably delayed. Running Linux Mint 18.2 (based on Ubuntu 16.04) with Cinnamon, NVIDIA Driver 384.69 with a GTX 1080.

The delay happens everywhere including chaperone bounds, SteamVR Home and the standard SteamVR environment.

@Plagman Any news on this issue? it's been 7 months already :'(

@Plagman I've recently tried to get SteamVR working on my Linux machine and have been experiencing the same issues as described above: the SteamVR tutorial is nauseating (only the default VR environment is smooth). Some details about my machine: Ubuntu 17.04, Quadro P4000 graphics with NVIDIA 387.34, SteamVR [beta].
I also have a Windows machine running SteamVR which does not have this problem. There I noticed that the GPU frame timing is ~5ms while on my Linux machine it is ~13ms. Maybe this points to the issue.
Any help would be much appreciated! Thanks.

Same problem here. Nvidia 396.54 (GTX 980 Ti Strix). SteamVR Build Aug. 7, 2018 at 19:52 Version 1533664367 on Arch Linux (kernel 4.18.5-arch1-1-ARCH). Basically unusable without getting a headache within 5 minutes. No issues on the Windows version.

I can no longer reproduce this for quite some time now.

No, the issue is still present. Since my last comment, I have switched distribution, used many different nvidia driver and SteamVR versions, but not a single time I did not experience a delay in tracking. And since everything is proprietary and closed source I see no way to debug this myself. Here is a system report from SteamVR: SteamVR-2019-01-15-_09_49_59.txt
I could imagine many users wouldn't even notice the delay, but it is definitely there and makes SteamVR absolutely unusable.

SteamVR user for two years on Windows. Finally took the plunge and installed it on Ubuntu 18.04. I immediately noticed what felt like a full frame of latency vs. the Windows experience I'm very used to.

CPU: Ryzen 7 2700x
GPU: RTX 2080 ( 410.57 )

I'm not on the Beta branch, but the entire Ubuntu/Steam/SteamVR/Nvidia installation is entirely new from this weekend. My timing graph stays flat at 6-7ms, with plenty of headroom. It's just a persistent, tiny delay at the beginning and end of every head movement that isn't present in Windows and seems unrelated to actual performance.

Same issue here as well, after some time head movement will have a slight delay which is extremely uncomfortable.
CPU: Ryzen 7 1700
GPU: RX Vega 64
Kernel 5.0.2-steamvr-generic
Currently on Steam Beta Branch & SteamVR Beta Branch

Update to this, now that the tearing bug is fixed ( #196 ) I can once again reproduce this. It seems whatever was done to fix the tearing (vsync?) brought back the latency. This is with an Nvidia 2080 and the drivers that fixed the gsync tearing, 435.27.07

I have also noticed this regression, although in my case it appears to be from upgrading from NVIDIA drivers 440.36 to 440.44, which also fixed the gsync/steamvr combo tearing, albeit in a different driver branch, if I understand correctly.

From what I remember, when I was experiencing tearing in the headset with the previous driver, the portion of the screen above the tear seemed to occasionally have the same level of latency as I experience with the newest driver, but the portion below the tear always had latency on the same level of Windows (that is, noticeably lower latency). I'm not sure why this would be though, especially if frames are being rendered from the top of the screen downward...

I have also noticed that I can make the latency go away for a bit by opening the SteamVR dashboard or causing frame drops in the VR application. But every new frame drop has a chance to reintroduce the latency again.

I noticed the exact same symptom regarding the tear where the area below the tear was very responsive and fast. I'm also seeing something similar where sometimes the latency is better than others, seems to come and go between SteamVR boots or opening and closing applications, even with the same applications.

Any news on this one? It still happens in now with 1.10.21 and the 440.59 driver and it makes VR completely unusable.

Edit: it does still seem to be fixed by turning off gsync.

Ran into this issue using the following:
Pop!_OS 20.04 LTS,
SteamVR 1.13.10,
GTX 1080Ti (driver 440.100).

Switching to 120Hz has stopped there being a visual delay between movement and display,
(original being 90Hz).

@edwin-v Unfortunately, I don't seem to observe the same behaviour. I get the roughly the same amount of latency increases whether or not I have Allow G-SYNC/G-SYNC Compatible enabled in the Nvidia control panel.

Sorry to bump an old topic. Are there any updates at all for this problem? Proton works so well now that I'd be so glad to play VR on Linux but the latency is headache inducing. It appears like any fixes posted in this thread are nvidia specific.

I'm on up to date Arch with kernel 5.9.1-zen2-1-zen #1 ZEN SMP PREEMPT Sun, 18 Oct 2020 02:45:20 +0000 x86_64 GNU/Linux
mesa 20.2.1-1
5700XT gpu
3700X cpu

No updates as far as I'm aware. I'm still hoping for a fix at some point... Or at least a better idea of what's causing the issue. Even with a Nvidia card I haven't had any luck with fixes mentioned here on recent drivers, except for being able to temporarily fix the latency issue by inducing a frame drop (such as by opening the SteamVR menu in-game.)

With this temporary fix, games like Beat Saber become quite playable. I can play multiple levels before I see any latency issues, and when I do, I just open and close the SteamVR menu.

Games like Hot Dogs, Horseshoes, and Hand Grenades have more frequent frame drops on my GTX 1070, however, so I'm required to open and close the SteamVR menu fairly frequently to mitigate latency issues that occur.

Overall, the latency is less of a deal breaker for me, and more of a mild annoyance.

That's interesting it can be fixed by opening the menu. For me the latency is there from the beginning and is fairly consistent. It's there in the default SteamVR environment and doesn't seem to change regardless of what I run.

I tried out the beta version 1.15.6 today and the problem seems to be a lot worse for overlays. The dashboard or xrdesktop windows seem to lag by half a second behind head movements. It looks very weird with everything seeming to wobble around in your vision. Overlays also stutter a lot when moving your head.

Games however aren't too affected. They still lag only a little like before.

That sounds like #395

Query: How is this still a problem. This post was made like 4 years ago and there is still no solution. I'm getting sick of arguing Linux to my friends and them responding with this exact issue. Joking aside I cannot stand windows in the slightest and Im getting tired of looking at the vive in the corner of my room sitting unused for like 3 years. If anyone has any idea in the slightest of how this could be resolved, please come up with an answer.

Major contributor to this issue seems to be the global lock on hidraw devices in the kernel, specifically this mutex.

Patching this so that the lock is non-global (per-device basis) dropped my latency significantly (~50 - ~15 ms)

@questionsdonkey do you have a patch you could share?

@questionsdonkey do you have a patch you could share?

Here's the diff for drivers/hid/hidraw.c.

This is for 5.8.0:

@@ -27,6 +27,7 @@
 #include <linux/mutex.h>
 #include <linux/sched/signal.h>
 #include <linux/string.h>
+#include <linux/mm.h>
 
 #include <linux/hidraw.h>
 
@@ -34,7 +35,7 @@
 static struct cdev hidraw_cdev;
 static struct class *hidraw_class;
 static struct hidraw *hidraw_table[HIDRAW_MAX_DEVICES];
-static DEFINE_MUTEX(minors_lock);
+static struct mutex* minors_locks;
 
 static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos)
 {
@@ -107,7 +108,7 @@
 	__u8 *buf;
 	int ret = 0;
 
-	lockdep_assert_held(&minors_lock);
+	lockdep_assert_held(minors_locks + minor);
 
 	if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
 		ret = -ENODEV;
@@ -159,10 +160,11 @@
 
 static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t count, loff_t *ppos)
 {
+	unsigned int minor = iminor(file_inode(file));
 	ssize_t ret;
-	mutex_lock(&minors_lock);
+	mutex_lock(minors_locks + minor);
 	ret = hidraw_send_report(file, buffer, count, HID_OUTPUT_REPORT);
-	mutex_unlock(&minors_lock);
+	mutex_unlock(minors_locks + minor);
 	return ret;
 }
 
@@ -182,7 +184,7 @@
 	int ret = 0, len;
 	unsigned char report_number;
 
-	lockdep_assert_held(&minors_lock);
+	lockdep_assert_held(minors_locks + minor);
 
 	if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
 		ret = -ENODEV;
@@ -272,7 +274,7 @@
 		goto out;
 	}
 
-	mutex_lock(&minors_lock);
+	mutex_lock(minors_locks + minor);
 	if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
 		err = -ENODEV;
 		goto out_unlock;
@@ -301,7 +303,7 @@
 	spin_unlock_irqrestore(&hidraw_table[minor]->list_lock, flags);
 	file->private_data = list;
 out_unlock:
-	mutex_unlock(&minors_lock);
+	mutex_unlock(minors_locks + minor);
 out:
 	if (err < 0)
 		kfree(list);
@@ -347,7 +349,7 @@
 	struct hidraw_list *list = file->private_data;
 	unsigned long flags;
 
-	mutex_lock(&minors_lock);
+	mutex_lock(minors_locks + minor);
 
 	spin_lock_irqsave(&hidraw_table[minor]->list_lock, flags);
 	list_del(&list->node);
@@ -356,7 +358,7 @@
 
 	drop_ref(hidraw_table[minor], 0);
 
-	mutex_unlock(&minors_lock);
+	mutex_unlock(minors_locks + minor);
 	return 0;
 }
 
@@ -369,7 +371,7 @@
 	struct hidraw *dev;
 	void __user *user_arg = (void __user*) arg;
 
-	mutex_lock(&minors_lock);
+	mutex_lock(minors_locks + minor);
 	dev = hidraw_table[minor];
 	if (!dev || !dev->exist) {
 		ret = -ENODEV;
@@ -465,7 +467,7 @@
 		ret = -ENOTTY;
 	}
 out:
-	mutex_unlock(&minors_lock);
+	mutex_unlock(minors_locks + minor);
 	return ret;
 }
 
@@ -524,18 +526,21 @@
 
 	result = -EINVAL;
 
-	mutex_lock(&minors_lock);
-
 	for (minor = 0; minor < HIDRAW_MAX_DEVICES; minor++) {
+		mutex_lock(minors_locks + minor);
+
 		if (hidraw_table[minor])
+		{
+			mutex_unlock(minors_locks + minor);
 			continue;
+		}
+
 		hidraw_table[minor] = dev;
 		result = 0;
 		break;
 	}
 
 	if (result) {
-		mutex_unlock(&minors_lock);
 		kfree(dev);
 		goto out;
 	}
@@ -545,7 +550,7 @@
 
 	if (IS_ERR(dev->dev)) {
 		hidraw_table[minor] = NULL;
-		mutex_unlock(&minors_lock);
+		mutex_unlock(minors_locks + minor);
 		result = PTR_ERR(dev->dev);
 		kfree(dev);
 		goto out;
@@ -561,7 +566,7 @@
 	dev->exist = 1;
 	hid->hidraw = dev;
 
-	mutex_unlock(&minors_lock);
+	mutex_unlock(minors_locks + minor);
 out:
 	return result;
 
@@ -572,16 +577,17 @@
 {
 	struct hidraw *hidraw = hid->hidraw;
 
-	mutex_lock(&minors_lock);
+	mutex_lock(minors_locks + hidraw->minor);
 
 	drop_ref(hidraw, 1);
 
-	mutex_unlock(&minors_lock);
+	mutex_unlock(minors_locks + hidraw->minor);
 }
 EXPORT_SYMBOL_GPL(hidraw_disconnect);
 
 int __init hidraw_init(void)
 {
+	unsigned i;
 	int result;
 	dev_t dev_id;
 
@@ -605,6 +611,13 @@
 	if (result < 0)
 		goto error_class;
 
+	minors_locks = kmalloc(sizeof(struct mutex) * HIDRAW_MAX_DEVICES, GFP_KERNEL);
+	if (minors_locks == NULL)
+		goto error_class;
+
+	for (i = 0; i < HIDRAW_MAX_DEVICES; i++)
+		mutex_init(minors_locks + i);
+
 	pr_info("raw HID events driver (C) Jiri Kosina\n");
 out:
 	return result;
@@ -624,4 +637,5 @@
 	class_destroy(hidraw_class);
 	unregister_chrdev_region(dev_id, HIDRAW_MAX_DEVICES);
 
+	kvfree(minors_locks);
 }

This is very interesting. Though many users are having issues unrelated to this, I was unaware of this specific possibility. I am very curious how you came to find this flaw in the kernel. That said - I am curious what we can do to mitigate the issue. @questionsdonkey if you have a good handle on which function call into hidraw is the one that's the primary offender, we can see if we can split that out into a different thread...

That said, it seems that the mutex is not involved in hidraw_read but if you have already done the profiling to identify the entry that would be very helpful. Considering we use hidapi, the issue may be confounded.

@questionsdonkey – you should use diff -u, and you probably want to use

kmalloc_array(HIDRAW_MAX_DEVICES, sizeof(struct mutex), GFP_KERNEL)

– yes, it's safe as is, but this way has better self-documentation.

This is very interesting. Though many users are having issues unrelated to this, I was unaware of this specific possibility. I am very curious how you came to find this flaw in the kernel. That said - I am curious what we can do to mitigate the issue. @questionsdonkey if you have a good handle on which function call into hidraw is the one that's the primary offender, we can see if we can split that out into a different thread...

That said, it seems that the mutex is not involved in hidraw_read but if you have already done the profiling to identify the entry that would be very helpful. Considering we use hidapi, the issue may be confounded.

There are two ioctl calls that will block in the kernel while acquiring minors_lock: HIDIOCGFEATURE and HIDIOCSFEATURE

You're likely correct in assuming that hidraw_read uses a separate mutex.

There may also be other locks being held in the underlying HID driver.

@questionsdonkey – you should use diff -u, and you probably want to use

kmalloc_array(HIDRAW_MAX_DEVICES, sizeof(struct mutex), GFP_KERNEL)

– yes, it's safe as is, but this way has better self-documentation.

I've updated my previous comment with a diff in unified format.

Specifically, @questionsdonkey I was wondering what mechanisms I could use to see if there was anything we can do on the SteamVR side to reduce the impact of this mutex. We are unsure what would cause the feature get/set in the same thread as the system which takes on lighthouse, IMU data and input.

Does the HIDIOCGFEATURE and HIDIOCSFEATURE also block the user thread doing hidraw_read

A huge help may be if you can give us the contents of the offending HIDIOCGFEATURE and HIDIOCSFEATURE calls? Also if you can send a system report from a system that's suffering from performance that would be a massive help.

@questionsdonkey just wanting to mention you here on this issue, did you end up giving more info to @charleslvalve through somewhere else? I don't understand the specifics beyond you found something beneficial to change in the kernel for steamvr, but if I could help test in some way, I've got a Valve Index along with a Ryzen 5 1600 and an RX 5700.

I hope I'm not throwing everyone a red herring but I'm having this same issue on Manjaro with an AMD Radeon RX580 with my HTC Vive.

KDE Plasma version: 5.21.5
Kernal version: 5.12.9-1-MANJARO
SteamVR build ID: 6834725
Steam Proton: Proton 6.3-4 (not that it matters, latency was so bad I couldn't even open a game without getting super nauseous after less than a minute)

Also probably worth mentioning the OpenGL 2.0 and 3.1 compositors stopped working until SteamVR was closed. I've tried a few kernels but get the same result.

Anyone having luck with SteamVR 1.18.2? I played some Beat Saber and some H3VR today and didn't encounter a single case where the latency would noticeably raise (other than the occasional frame drop, unrelated to this issue.) Can anyone reproduce this behavior? I'm not 100% confident that I didn't just have really good luck with SteamVR today.

The changelog for 1.18.2 contain the following line under the Linux subheading:

Enable async-reprojection on compatible nvidia 470 series drivers

It would be funny if this solved the issue considering the 470 series driver isn't even available at the time of writing, but it's possible that this might have had unintended benefits to the current series of NVidia driver as well.

@tizzir

I gave it a try but didn't notice any improvement on my side. #395 also seems to still be there.

@questionsdonkey do you have a patch you could share?

Here's the diff for drivers/hid/hidraw.c.

This is for 5.8.0:

...

Is it worth actually submitting this patch to the Linux kernel? Are there any downsides to using this patch?

I believe i've found a solution from the most unlikely of places.
Please excuse me if i get things wrong, i'm still a fairly new linux user.

Earlier today i was trying out steamvr and noticed the mentioned latency issues which became very apparent (and sickening) when moving.

I stopped playing beatsaber as i was dying of heatstroke with this heatwave and went to learn how to use my midi keyboard.

I was following a post about playing with midi devices, and one thing that was mentioned is running the kernel in low latency mode to play in realtime

sudo apt install ubuntustudio-audio linux-lowlatency
seemed to have patched my kernel to run in low latency mode, and ever since then my steamvr has been running way smoother.

this seems to be ubuntu-only but i'm sure users of different flavors of linux could research into how to run the kernel in low latency mode

Interesting find about the low latency kernel, @RinLovesYou. I'm not using Ubuntu, so I can't test that exact kernel, but I can attest that using a kernel I compiled with TKG to have quite a few latency optimization for gaming doesn't help the issue for me.

After doing some more "testing" (IE playing some Beat Saber and No Man's Sky) in VR today, it seems that the occurrence of latency increases has been significantly reduced, with SteamVR 1.18.2 but not completely eliminated. I still ran into a few times where latency would jump up and stay up until I opened the SteamVR overlay.

Speaking of which, now that Nvidia GPUs support asynchronous reprojection using the 470 series dirver, I encountered #395 for the first time. You win some, you lose some I guess :smile:

EDIT: I think the latency issue that I'm encountering might actually be #227. It seems to line up with my experience of a temporary performance blip causing increased latency until there's another performance blip (such as from opening the SteamVR overlay.)

Something I've noticed with SteamVR on Windows is that async/legacy reprojection seems to have a noticable latency impact. It's subtle but I can immediately feel the difference and I am significantly better at the game when async reprojection on in BS.

If async reprojection isn't working right on Linux (as I suspect is the case for me, probably due to external issues), that could be another factor.

I'm also experiencing delayed tracking when I started SteamVR (beta) and am in that start screen. I did not have this all the time, but it started a couple of months ago and it is really irritating.
Interestingly, yesterday I switched from 90 Hz to 120 Hz just to see if this would improve things, and actually the delay is pretty much gone at that setting. Of course I hardly can render stuff at 120fps, but overall it's a better experience. Not sure why it's so bad at 90 Hz.

Thanks @RinLovesYou! I have been struggling with SteamVR, and mostly avoiding it, for years. One of the major persistent issues has been like a hitching of the view, but not quite. No CPU/GPU spikes (after CPU profile is set to "performance"), yet moving my head gently would always have some subtle perceptual lag and a jarring snap at roughly 1s intervals which seemed to be two frames of overshoot then undershoot. Whether it was a super simple SteamVR Home scene, or HalfLife:Alyx. Smooth rendering, but my head motion was "rough, with jank".

I originally installed Ubuntu 18 on this machine because it was the "recommended"/baseline system people were supposedly testing against. This is the first time I've read mention of installing a lowlatency kernel. And it worked -- my head motion feels smooth now. Still not perfect, but so much better: playable! Maybe the lowlatency configuration is just helping to hide the underlying issue though. And I had a system crash, within about an hour of play... can't remember the last time that happened. Hopefully not related and doesn't recur. I'll see...

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-873119408

If you're on Nvidia make sure you are using the 470 series drivers. If you're on AMD make sure it shows Async reprojection enabled. The 470 drivers fixed everything for me except for the in-game overlay latency wise.

I decided to compare with linux-rt 5.11.4 but I honestly can't see any improvement. I did notice my framerates were a bit poorer going from linux-zen. For myself I still get the best experience with zen, but this issue still exists on both kernels as far as I can tell.

I tested with async reprojection off because of it being broken currently.

I've recently done some testing with the approaches that people have been sharing for combating this latency issue.

Approaches that I tested:

• Running with Ubuntu's5.11.0-22-lowlatency kernel (vs. 5.11.0-22-generic)
• Running with SteamVR Beta 1.18.4 vs. 1.17.16
• Running the Index's HMD at 90Hz, 120Hz, and 144Hz
• Disabling async reprojection (using the method mentioned here)

I ran these tests on a system with a Ryzen 7 1700 (16GB RAM) and RX 480 (8GB), running off of a completely fresh install of Ubuntu 21.04.

Notes from testing:

• I tested both SteamVR Home and Neos VR. In every test that I ran, Neos was running at half of the frame rate of SteamVR Home, with ~100% of frames reprojected:

• Running with the -lowlatency kernel image perceptibly reduced the delay in tracking over the -generic kernel image but did not fix the issue, especially at lower frame rates/refresh rates.

• Running SteamVR Beta 1.18.4 also perceptibly reduced the delay in tracking over SteamVR 1.17.16 and generally performed better. At 90Hz in Neos VR, 1.17.16 was running a ghastly ~5ms over budget on every frame vs. <~1ms with 1.18.4.

• At every refresh rate, I did not notice any delay in tracking while in SteamVR home. As I increased the HMD's refresh rate, the delay in Neos became far less noticeable. At 144Hz in Neos (running at 72 FPS, reprojected) the delay would have been imperceptible if I weren't actively looking for it.

• Disabling async reprojection did not seem to affect performance or tracking delay in any way. I will note, however, that the SteamVR overlay was ridiculously unstable and unusable (flickering, crashing, etc.) for the duration of my testing, until I disabled async reprojection. The chaperone boundaries and overlay panel also followed my HMD's position with a significant delay until async reprojection was disabled. Once it was disabled (again, using the method mentioned here), the SteamVR overlay was perfectly usable.

Observations:

The tracking latency on my system seems to be inversely correlated with pre-reprojection frame rate.

I'd be interested in hearing from any of the nVidia users who can now benefit from async reprojection to see if they are also experiencing a broken SteamVR overlay with it enabled.

Misc. Notes:

Leaving these here for anyone else who might be debugging their Linux VR setup in general:

• Audio did not work until I set the audio device to "DisplayPort 3", and I couldn't adjust the volume from within VR (this is a known issue). Additionally, my audio was horribly blown out and crackly at first, but this was fixed by restarting SteamVR.

• Microphone didn't work at all, though installing PipeWire seems to be a solution for this.

I'd be interested in hearing from any of the nVidia users who can now benefit from async reprojection to see if they are also experiencing a broken SteamVR overlay with it enabled.

I'm on Nvidia and can confirm that in games the latency seems OK but the overlay is completely unusable and gives me a headache if I move my head too much with it on. The overlay seems to have many frames of delay. I did not try disabling async reprojection.

Latency issues here as well, not massive but definitely enough to cause nausea. Running an RX 5500XT, latency graph shows ~1.3ms constant in the empty skybox generated when nothing's running, but it still happens. Using Mesa 20.3.5, SteamVR 1.18.7, kernel 5.10.0-8 on Debian. Running PipeWire so that audio out works on the HMD.

@questionsdonkey
I will try out your patch tonight and let you know how it feels on nvidia. It applied well to a Gentoo 5.10.49-r1 kernel.

@questionsdonkey
I will try out your patch tonight and let you know how it feels on nvidia. It applied well to a Gentoo 5.10.49-r1 kernel.

I am also very curious in your findings on this!! Thank you for testing it out!

The patch seemed to make a difference! The latency is minimal and very usable, pavlov, vrchat, alyx all good.
However: The broken motion smoothing still exists and it becomes VERY apparent under 20 fps which makes low FPS hurt just that much more. The timing info being used is clearly incorrect, still.

The patch seemed to make a difference! The latency is minimal and very usable, pavlov, vrchat, alyx all good.
However: The broken reprojection still exists and it becomes VERY apparent under 20 fps which makes low FPS hurt just that much more. The timing info being used is clearly incorrect, still.

That's mostly good news! Is that broken reprojection relevant to nvidia? I thought I saw something in SteamVR beta about nvidia getting that feature...can't quite remember though. By timing info do you mean the graph in dev tools is off from what you're actually seeing?

Nvidia now has async reprojection which helps massively.
Both nvidia and amd are having an issue with steam's native motion smoothing. Wrong frames are being used by steam's motion smoothing.

This patch just fixes the massive latency behind tracker movement which makes everything playable as long as you don't drop down too low...

Would the next step be to submit it for addition into the actual kernel,
then? That sounds like something they'd want to add to it, if it makes
hidraw as a whole work more smoothly?

On Mon, Aug 2, 2021, 12:18 PM SpookySkeletons @.***>
wrote:

Nvidia now has async reprojection which helps massively.
Both nvidia and amd are having an issue with steam's native motion
smoothing. Wrong frames are being used by steam's motion smoothing.

This patch just fixes the massive latency behind tracker movement which
makes everything playable as long as you don't drop down too low...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-891196215,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHE6CQKAQNH24LDTZYH3WCLT23HQBANCNFSM4DBO53MQ
.

Any good way to take a peek into openvr to see why it jitters smoothed frames?
Does anyone suppose a vulkan apitrace would give us a clue?

I'd be interested in hearing from any of the nVidia users who can now benefit from async reprojection to see if they are also experiencing a broken SteamVR overlay with it enabled.

@jessiehildebrandt is this still relevant?

I run the following configuration:

OS: Manjaro Linux x86_64
Kernel: 5.10.53-1-MANJARO
CPU: AMD Ryzen 5 3600 (12) @ 3.600GHz
GPU: NVIDIA GeForce RTX 2080 SUPER
WM/DE: Xfwm4 / Xfce 4.16
GPU Driver: NVIDIA 470.57.02
HMD: Valve Index

I had a real struggle getting SteamVR to run at all on my index but eventually everthing fell into place and it worked.

On SteamVR 1.18.7 I have had the issue with games running fine but the overlay dragging behind and glitching. The linux_v1.14 build does not have this issue, but some game won't run on that version.

Diabling steamvr.vrsettings enableLinuxVulkanAsync did wonders for the overlay issue on 1.18.7, no dragging, lagging or glitching. This is related to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/395 . Other than that I couldn't really notice any significant tracking issues. Only other unrelated issue was the audio popping, but setting the sample rate to 48kHz in pulse solved that.

Sorry if I caused any unnecessary noise.

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-808969247

Tested on Debian Sid, 5.10.0-8 kernel, AMD Ryzen 5 2600 CPU, AMD RX 5500XT GPU. This has fixed the tracking latency, my timing graph shows i've gone from 12.8ms per frame to around 4.1, and has fixed a few other unrelated HID bugs in other programs, but... well, SteamVR 1.18.7 in itself is horribly broken after applying this. One of my base stations keeps registering as being 3 feet(!) away from where it should be, tracking is problematic, and most games are now horribly broken. Beat Saber is very, very bugged out, with no text rendering, all blocks I hit are still misses, all bombs that pass me hit no matter what, and the black skybox is around a foot tall. VTOL VR is unplayable, as it thinks i'm spinning around really rapidly when I turn my head even a little. Other games untested as of now.

I don't know if I applied it improperly or if I did something else incorrectly, but i'll go ahead and report this anyway, in case anyone else is experiencing these issues.

@SpookySkeletons did you experience any issues like @ParzivalWolfram mentioned when testing out the patch?

@kedodrill Nope no issues the patch was completely painless

I'll try recompiling, then. Maybe I screwed something up, or some DKMS
module isn't having it, etc.

On Mon, Aug 9, 2021, 12:02 PM SpookySkeletons @.***>
wrote:

@kedodrill https://github.com/kedodrill Nope no issues the patch was
completely painless

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-895386345,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHE6CQP2AXZ7FWP5LOKLHVDT4ACY5ANCNFSM4DBO53MQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

Is there a better hid method for steam to use that doesn't involve this kernel patch?
As much as I like having my custom kernel patched, this needs to be upstreamed if sane, or steamvr needs to not use blocking hid methods.

It is very possible to implement a lighthouse driver with libusb and not go over hid. The question is whether Valve wants to put in that work.

It is quite likely that this hid blocking issue does not affect many users actually, personally I don't believe I have noticed it. One hypothesis is that some other USB peripheral could cause it, for example gaming mice with a high poll rate.

I don't have anything that has an overly high poll rate, and I'm
experiencing the issue. Cheap $5 mouse, $5 keyboard, empty USB hub,
headset, Bluetooth chip on my Intel chipset 802.11AX card, not much else...

On Tue, Aug 10, 2021, 4:04 PM Christoph Haag @.***>
wrote:

It is very possible to implement a lighthouse driver with libusb and not
go over hid. The question is whether Valve wants to put in that work.

It is quite likely that this hid blocking issue does not affect many users
actually, personally I don't believe I have noticed it. One hypothesis is
that some other USB peripheral could cause it, for example gaming mice with
a high poll rate.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-896315465,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHE6CQKZJHCBVYNSOM2J32LT4GH6FANCNFSM4DBO53MQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

I suspect Valve upstreaming a kernel patch to fix blocking would be a better match for their goals than developing a workaround for a single scenario, considering their investments in the platform.

Since high-polling-rate mice are also known to cause performance degradation, is it possible this kernel patch would address that issue? After all, libusb recommends usage of hidapi for devices where applicable, though it does note that one backing implementation is - again - on libusb.

As for whether or not polling from such devices is the root cause of the issue in others, it's fair to say that Parzival's configuration contradicts that scenario.

Replying to [#21 (comment)](https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-808969247)

Tested on Debian Sid, 5.10.0-8 kernel, AMD Ryzen 5 2600 CPU, AMD RX 5500XT GPU. This has fixed the tracking latency, my timing graph shows i've gone from 12.8ms per frame to around 4.1, and has fixed a few other unrelated HID bugs in other programs, but... well, SteamVR 1.18.7 in itself is horribly broken after applying this. One of my base stations keeps registering as being 3 feet(!) away from where it should be, tracking is problematic, and most games are now horribly broken. Beat Saber is very, very bugged out, with no text rendering, all blocks I hit are still misses, all bombs that pass me hit no matter what, and the black skybox is around a foot tall. VTOL VR is unplayable, as it thinks i'm spinning around really rapidly when I turn my head even a little. Other games untested as of now.

I don't know if I applied it improperly or if I did something else incorrectly, but i'll go ahead and report this anyway, in case anyone else is experiencing these issues.

I've reapplied the patch to kernel 5.13, instead of 5.10, and suddenly everything works fine. I'm not sure what the differences are other than that. It's almost entirely eliminated tracking issues and shaved 2-3ms off my latency graph, and nothing's busted this time through. It's even fixed a few other minor things, like DS4 detection.

@questionsdonkey patch looks very interesting - can you email me? pgriffais at valvesoftware

@Plagman did you happen to receive an email from @questionsdonkey about this yet? This seems like it could be a step forward for performance in VR on Linux.

I tried the kernel patch but it did not solve the issue for me, not entirely at least. When I start up SteamVR and load into the empty environment I don't notice the delay. Turning on the controllers (Valve Index) sometimes causes the delay, and starting a game usually causes the delay. What I also noticed is that when i changed the background in the empty environment, the delay suddenly got really bad, probably 80+ ms and changing the background back doesn't fix it.

I'm running Fedora 35 (beta) with kernel 5.14.9 (with the hidraw patch and low latency desktop config option)
My GPU is a GTX 970 and I'm using the 470.74 proprietary NVIDIA driver.

I've tried with the patch a few times and definitely see an improvement with this specific problem and don't see it getting better or worse after doing certain things. I'm using an AMD card instead of Nvidia. Could it be there are graphics card specific problems that are different to what the hidraw patch addresses?

I still experience other performance problems while using VR. https://github.com/ValveSoftware/SteamVR-for-Linux/issues/269 this issue seems to be the best description of what I still get.

I tried the kernel patch but it did not solve the issue for me, not entirely at least. When I start up SteamVR and load into the empty environment I don't notice the delay. Turning on the controllers (Valve Index) sometimes causes the delay, and starting a game usually causes the delay. What I also noticed is that when i changed the background in the empty environment, the delay suddenly got really bad, probably 80+ ms and changing the background back doesn't fix it.

I'm running Fedora 35 (beta) with kernel 5.14.9 (with the hidraw patch and low latency desktop config option) My GPU is a GTX 970 and I'm using the 470.74 proprietary NVIDIA driver.

This is probably just due to the fact that you're using a GTX 970, which is a card from 2014... the background issue is weird, but the game latency issues would be normal for this GPU.

No that's not it, I can play many games including Half Life: Alyx just fine on windows. The rendering is still smooth on linux, but it looks like it's using the HMD transform from some amount of frames ago.

That's rather impressive that it's playable, as the card you have doesn't
meet minimum requirements for HL:A. This is off-topic, though.

On Mon, Oct 11, 2021, 3:49 AM Pjotr Slooff @.***> wrote:

No that's not it, I can play many games including Half Life: Alyx just
fine on windows. The rendering is still smooth on linux, but it looks like
it's using the HMD transform from some amount of frames ago.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-939820999,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHE6CQPPN52XWN37RW3FPQLUGKQKBANCNFSM4DBO53MQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Sad the kernel patch hasn't gone anywhere since emails were exchanged (in theory), I have very strong VR legs but Linux SteamVR in general brings me to my knees.

This commit in linux git master is supposed to solve the problem in a slightly different way https://github.com/torvalds/linux/commit/8590222e4b021054a7167a4dd35b152a8ed7018e

Mailing list: https://lore.kernel.org/lkml/[email protected]/

This commit in linux git master is supposed to solve the problem in a slightly different way torvalds/linux@8590222

By the way this is included in 5.17-rc1, in case anyone wants to test and report back.

I gave it a try the other day. It seems to be much better 👍 thank you for the work.

Wow, that's awesome. I like that solution.

I won't have time to test for a bit. In about 2 months when I am going back to this, hopefully it'll be in some of the released kernels.

Charles

I rebuilt the hid.ko module with this patch in the 5.13 kernel (Ubuntu 21.10) and I had the left controller drop off twice after about half an hour of play. Couldn't get life back into the controller until a SteamVR restart. Has anybody tested else tested this thing patch? It might be something 5.13 related, but I don't see anything specific in this patch that shouldn't work.

Loading modules from a different kernel ABI is not a good idea and can very well cause issues like yours. You need to rebuild the whole kernel with the patch backported.

Loading modules from a different kernel ABI is not a good idea and can very well cause issues like yours. You need to rebuild the whole kernel with the patch backported.

I did an out-of-tree module rebuild. No need to rebuild the whole kernel. No worries there.

Ah, sorry; I misread.

This commit in linux git master is supposed to solve the problem in a slightly different way torvalds/linux@8590222

By the way this is included in 5.17-rc1, in case anyone wants to test and report back.

I've been testing that kernel version.
Good News: It's a lot better
Bad News: It's still not perfect.

Edit:
Now to be clear there's a thousand other problems that could exist and just one of those causes it.

I've been able to play around with it briefly, and my experience was the same. Better, but not 100%.

Yep, new kernel changes things dramatically, but it isn't fixed entirely.
In (proton) games theres a lot less latency compared to SteamVR overlay, but both overlay and games have it.

Using the linux_1.14 beta worked for me

Using the linux_1.14 beta worked for me

it fixed delayed output?
for me it's even worse in previous branches

Yes, it fixed the delayed SteamVR overlay / Chaperone for me.

PLYSHKA @.***> schrieb am Mi., 16. März 2022, 19:14:

Using the linux_1.14 beta worked for me

it fixed delayed output?
for me it's even worse in previous branches

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-1069408321,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALVSZ2LJULE4UDWN6T5JBTVAIQJTANCNFSM4DBO53MQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID:
@.***>

@ImpulseTheFox

You're referring to a different bug. Report is here: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/395

Major contributor to this issue seems to be the global lock on hidraw devices in the kernel, specifically this mutex.

Patching this so that the lock is non-global (per-device basis) dropped my latency significantly (~50 - ~15 ms)

Hello, i was really curious on how did you manage to capture this latency? it would really help to determine the cause of the issues and would make testing new fixes much easier.

Edit: it seems like this mailing list has benchmark tool, i will use it as a reference https://lore.kernel.org/lkml/[email protected]/

This might not be solution for your case, but it is worth checking if you have lib32-amdvlk installed on Nvidia GPU.

I had sluggish tracking when moving head around, a lot of the overlay menus didn't work and I had strange flickering in SteamVR.
I found out that I had lib32-amdvlk installed event though I am running GTX1080. This had happened because when I installed steam with package manager, it had defaulted to amd dependency instead of nvidia.
I had to first install lib32-nvidia-utils and then remove lib32-amdvlk
This fixed all the problems I had with SteamVR

This might not be solution for your case, but it is worth checking if you have lib32-amdvlk installed on Nvidia GPU.

I had sluggish tracking when moving head around, a lot of the overlay menus didn't work and I had strange flickering in SteamVR. I found out that I had lib32-amdvlk installed event though I am running GTX1080. This had happened because when I installed steam with package manager, it had defaulted to amd dependency instead of nvidia. I had to first install lib32-nvidia-utils and then remove lib32-amdvlk This fixed all the problems I had with SteamVR

I'm not seeing either of those packages available to install or uninstall; what's your distro? (I'm on Mint)

Arch linux, I forgot to mention that.
I also spoke too early, after reboot I started having SteamVR issues again, although removing amdvlk did fix the menus but the flickering and sluggish head tracking came back.

Running [linux_1.14] seems to help a lot. It could still be improved.

The SteamVR home-menu seems to not be working on this build, though.

I have nvidia drivers 520.56.06.

"enableLinuxVulkanAsync" : false helped with the flickering that sometimes happened.