I've seen the same issue. When my Index is functioning on the USB 3 ports, the cameras don't appear to show up. I believe they do show up in dmesg, though so they are detected.

Same for me.

Same on pop os (ubuntu) 19.04, steamvr report: https://gist.github.com/ebbit1q/18f1de3192d8ae4b64e5c5b015c8b81d

After switching to USB 3 again, I've noticed that SteamVR still can't seem to find the cameras.

Here's the dmesg log when I plug in the headset at the Trident cable:

[24773.428780] usb 5-3: new high-speed USB device number 23 using xhci_hcd
[24773.582033] usb 5-3: New USB device found, idVendor=28de, idProduct=2613, bcdDevice= 1.82
[24773.582035] usb 5-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[24773.633821] hub 5-3:1.0: USB hub found
[24773.634007] hub 5-3:1.0: 3 ports detected
[24776.620729] usb 5-3.3: new high-speed USB device number 24 using xhci_hcd
[24776.731135] usb 5-3.3: New USB device found, idVendor=0424, idProduct=2744, bcdDevice= 2.21
[24776.731138] usb 5-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[24776.731139] usb 5-3.3: Product: USB2744
[24776.731140] usb 5-3.3: Manufacturer: Microchip Tech
[24776.769796] hub 5-3.3:1.0: USB hub found
[24776.770010] hub 5-3.3:1.0: 5 ports detected
[24776.856758] usb 6-3: new SuperSpeed Gen 1 USB device number 10 using xhci_hcd
[24776.881061] usb 6-3: New USB device found, idVendor=0424, idProduct=5744, bcdDevice= 2.21
[24776.881063] usb 6-3: New USB device strings: Mfr=2, Product=3, SerialNumber=0
[24776.881064] usb 6-3: Product: USB5744
[24776.881065] usb 6-3: Manufacturer: Microchip Tech
[24776.897709] hub 6-3:1.0: USB hub found
[24776.897731] hub 6-3:1.0: 4 ports detected
[24777.132728] usb 5-3.3.1: new full-speed USB device number 25 using xhci_hcd
[24777.261657] usb 5-3.3.1: New USB device found, idVendor=28de, idProduct=2300, bcdDevice= 2.00
[24777.261659] usb 5-3.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[24777.261660] usb 5-3.3.1: Product: Index HMD
[24777.261661] usb 5-3.3.1: Manufacturer: Valve
[24777.261662] usb 5-3.3.1: SerialNumber: LHR-11BF2815
[24777.457435] hid-generic 0003:28DE:2300.001D: hiddev5,hidraw9: USB HID v1.11 Device [Valve Index HMD] on usb-0000:2b:00.3-3.3.1/input0
[24777.467892] hid-generic 0003:28DE:2300.001E: hiddev6,hidraw10: USB HID v1.11 Device [Valve Index HMD] on usb-0000:2b:00.3-3.3.1/input1
[24777.478881] hid-generic 0003:28DE:2300.001F: hiddev7,hidraw11: USB HID v1.11 Device [Valve Index HMD] on usb-0000:2b:00.3-3.3.1/input2
[24777.560721] usb 5-3.3.5: new high-speed USB device number 26 using xhci_hcd
[24777.671175] usb 5-3.3.5: New USB device found, idVendor=0424, idProduct=2740, bcdDevice= 2.00
[24777.671176] usb 5-3.3.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[24777.671177] usb 5-3.3.5: Product: Hub Controller
[24777.671177] usb 5-3.3.5: Manufacturer: Microchip Tech
[24778.028708] usb 5-3.3.2: new full-speed USB device number 27 using xhci_hcd
[24778.159656] usb 5-3.3.2: New USB device found, idVendor=28de, idProduct=2102, bcdDevice= 1.00
[24778.159658] usb 5-3.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[24778.159659] usb 5-3.3.2: Product: Valve VR Radio
[24778.159660] usb 5-3.3.2: Manufacturer: Valve Corporation
[24778.159661] usb 5-3.3.2: SerialNumber: C030191C6C-RYB
[24778.290233] hid-generic 0003:28DE:2102.0020: hiddev8,hidraw12: USB HID v1.11 Device [Valve Corporation Valve VR Radio] on usb-0000:2b:00.3-3.3.2/input0
[24778.290316] cdc_acm 5-3.3.2:1.1: ttyACM0: USB ACM device
[24778.512704] usb 5-3.3.3: new full-speed USB device number 28 using xhci_hcd
[24778.635654] usb 5-3.3.3: New USB device found, idVendor=28de, idProduct=2102, bcdDevice= 1.00
[24778.635657] usb 5-3.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[24778.635658] usb 5-3.3.3: Product: Valve VR Radio & HMD Mic
[24778.635659] usb 5-3.3.3: Manufacturer: Valve Corporation
[24778.635660] usb 5-3.3.3: SerialNumber: 8B37344787-LYM
[24778.739078] hid-generic 0003:28DE:2102.0021: hiddev11,hidraw15: USB HID v1.11 Device [Valve Corporation Valve VR Radio & HMD Mic] on usb-0000:2b:00.3-3.3.3/input0
[24779.388830] usb 6-3.1: new SuperSpeed Gen 1 USB device number 11 using xhci_hcd
[24779.638454] usb 6-3.1: New USB device found, idVendor=28de, idProduct=2400, bcdDevice= 0.04
[24779.638456] usb 6-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[24779.638457] usb 6-3.1: Product: 3D Camera
[24779.638458] usb 6-3.1: Manufacturer: Etron Technology, Inc.
[24779.638459] usb 6-3.1: SerialNumber: 00000001
[24779.691086] uvcvideo: Found UVC 1.00 device 3D Camera (28de:2400)
[24779.762943] uvcvideo 6-3.1:1.0: Entity type for entity Extension 4 was not initialized!
[24779.762945] uvcvideo 6-3.1:1.0: Entity type for entity Processing 3 was not initialized!
[24779.762947] uvcvideo 6-3.1:1.0: Entity type for entity Camera 1 was not initialized!
[24779.763018] input: 3D Camera: eTronVideo as /devices/pci0000:00/0000:00:08.1/0000:2b:00.3/usb6/6-3/6-3.1/6-3.1:1.0/input/input37

This also results in the addition of the /dev/video0 and /dev/video1 devices, however VLC doesn't seem to know what to do with them (and completely fails to open /dev/video1).

Same issue here, all headset functions work but Steam says camera is disconnected.

SteamVR says camera not available for me too.

The cameras work fine with guvcview (take ~2 seconds to initialize though).

I've also confirmed that the cameras work fine in Chromium.

i've found that the camera isn't added to the steam-vr udev rules yet.
Try adding the line

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2400", MODE="0660", TAG+="uaccess"

to the end of /lib/udev/rules.d/60-steam-vr.rules

Added it, rebooted and doesn't change anything. SteamVR says "camera not available" as always. Does it work for you?

Same problem here on Arch Linux. Cameras are "not available" on any USB ports, but guvcview can load them up just fine.

Same problem. Do you guys have installed openvr Input emulator?

Edit. Removing openvr Input emulator fixed for me. But I need that program, so no cam for now.

No I haven't. Interesting that removing it fixes the camera for you though

AFAIK Input Emulator is a Windows only application, and it's known to break the camera functionality in SteamVR. It breaks it on the Vive too from what I'd read.

Tried a different udev rule, didn't really accomplish much, but maybe useful to someone else:

KERNEL=="6-4.1", SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2400", MODE="0660", TAG+="uaccess"

Still get

Sat Oct 26 2019 14:04:48.309281 - lighthouse: TrackedCamera: OnWorkThread_OpenCamera()
Sat Oct 26 2019 14:04:48.309451 - lighthouse: TrackedCamera: Couldn't find Dual Cameras at USB VID:28DE, USB PID:2400
Sat Oct 26 2019 14:04:48.324364 - lighthouse: TrackedCamera: Worker thread OpenCamera result: NotFound.
Sat Oct 26 2019 14:04:48.324441 - lighthouse: InitTrackedCamera(): Failed to open expected camera on (LHR-11BF2815): NotFound. Camera services not available.
Sat Oct 26 2019 14:04:48.324462 - lighthouse: TrackedCamera: Stopping Video Stream For Camera Shutdown.
Sat Oct 26 2019 14:04:48.339593 - lighthouse: TrackedCamera: OnWorkThread_CloseCamera()

In the logs.

The camera is also not working for me on a basic install of Fedora 31 with XFCE.

@kedodrill It would be more surprising if it did work as I don't think it works for anyone currently.

@jcc10 Figured as much, this post hasn't been updated in over a month so I figured I'd just throw that out there. The camera isn't super useful for me or a core component IMO but it would be nice for all of the hardware to work. I would much rather have Bluetooth work first so I can update my base stations.

@kedodrill While updating & putting the stations to sleep would be nice, chaperone has a feature where when you are near the border you can see outlines of objects. Which in my room would help stop me from hitting lamps & monitors.

TBH, I think that base stations should be the easier one of the two to implement, but both are the only real features I feel I'm missing by being on Linux.

@jcc10 Oh, I didn't know that about chaperone. That sounds super useful.

And that sums it up quite nicely. If both of these features were implemented it would be so much more feature complete. Fingers crossed we get some good news soon!

I've noticed that the new UI in SteamVR Beta has some more options for the camera to enable / disable it and also includes chaperone options. However, when switching the camera to enabled, it still does not work. I haven't played around with chaperone settings much but I'm guessing that it still doesn't work either. Still...progress? I'm hopeful...

I'd rather have the ui admit that the valve index camera on linux isn't working in steamvr (it works separately, why it doesn't work like the vive camera baffles me)

@ebbit1q I would as well, but it is a beta and an entirely new UI so I'm guessing that they are still testing, adding, and removing things.

Has anyone played with permissions on the appropriate /dev/video[0..9] devices?

Getting the hardware soon and ill do what i can.

I havent played with permissions per se but I used guvcview to watch the video feed from the cameras as user which worked fine. So this doesnt seem to be a permission issue.

It could also be apparmor or selinux simillar. Really looking forward to
getting hardware in soon.

On Thu, Dec 12, 2019, 9:16 AM Farmboy0 [email protected] wrote:

I havent played with permissions per se but I used guvcview to watch the
video feed from the cameras as user which worked fine. So this doesnt seem
to be a permission issue.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/231?email_source=notifications&email_token=AJHHO2QPMUUOWIMZU35A4YTQYJBVFA5CNFSM4ILERZGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGWZNWA#issuecomment-565024472,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJHHO2USTQJDCYJP2U64NBLQYJBVFANCNFSM4ILERZGA
.

this doesn't seem to be on any priority list, does it?

Valve doesn't seem to care about the camera.
Issues with the camera are being reported on Windows as well (not only on Index, but on Vives as well).

would be nice to have at least basic functionality of an advertised feature though.
I personally don't care so much about the camera, but it should work at least.

Not sure if it's better to just 👍 the issue or comment "Me too", but... me too. Same symptom and logs, Ubuntu 19.10, SteamVR 1.11.

would be nice to have at least basic functionality of an advertised feature though.
I personally don't care so much about the camera, but it should work at least.

Well, I would really love if the passthrough finally worked... it was already quite nice on the Vive and that was without depth.
I'd also personally like to use it for some 3d vision projects (for example some sort of advanced chaperone that also warns you when people walk into your play space). There's quite a few possibilities with the tracking + dual camera setup.

Not only guvcview works with the camera, but cheese too.

Not only guvcview works with the camera, but cheese too.

it works everywhere... i can even use it on firefox video calls (it takes a few secs to start tho)

Also confirming this issue on ArchLinux (btw)

That Linux Support needs a few asterisks at least at this point.

On Wed, Jun 10, 2020 at 8:17 AM slackerbob [email protected] wrote:

Also confirming this issue on ArchLinux (btw)

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

--
Sincerely Dale,
Linux Admin for the Future

yay, "Introducing Room View 3D" https://steamcommunity.com/app/250820/eventcomments/2523653167120001494
uh, oh...

Yeah, no room view 3d for us.....

So it is a year later now since this bug was filed and I am still seeing it.

Cheese (webcam app) can see the cameras from the index just fine on Linux. I booted into Windows to test and the camera mostly works there. Somehow the Linux SteamVR implementation can't see them. Very strange.

So it is a year later now since this bug was filed and I am still seeing it.

@Semperverus Agreed, Valve Index has now been available for the past 12+ months and still missing basic functional parity, despite stating Linux as an officially supported platform!

@kisak-valve @JoeLudwig While we truly appreciate all the hard work and effort to date Valve really needs to step up given this would be an unacceptable situation for any product failing to work as advertized.

Positive news in 2020 is always welcome. :crossed_fingers:

I recently acquired a Vive Pro, and I can confirm that the cameras work in SteamVR on Linux.

The camera is very glitchy-- this is true in the preview as well. See here:

This could be specific to my Vive Pro, as it is used, and I have not personally tested it under Windows.

However, the stereo room view does work. So it isn't that the cameras [or Stereo cameras] are broken entirely in SteamVR-- it's just the Index that doesn't work.

Any updates for how to fix this? It's been almost 5 months since the last comment. The cameras still don't work for me in SteamVR for Ubuntu 20.04.1 despite being recognized by cheese and other programs.

Any updates for how to fix this? It's been almost 5 months since the last comment. The cameras still don't work for me in SteamVR for Ubuntu 20.04.1 despite being recognized by cheese and other programs.

They havent said anything since 2019 so nope

So if you really want to use your VR headset Camera, just go back to the ancient Linux Beta, as it work fine every time I load it up. However it's very buggy. Best option would be to try to figure out what code used to run the Cameras, and then put in a pull request to bring it into the MainBranch

Do you know the beta number? I tried the Linux beta that shows up in the steam client but that didn't work for me either. Also, does anyone know how to isolate the logs specific to the "test camera and performance" subroutine? I'm down to try to spend some time debugging, but I just need to know where to look.

IIRC Valve Index camera support was never implemented in any previous SteamVR build.
Doesn't make any sense, but streaming the guvcview camera window to the HMD using vr-video-player (and playing with the command line options) is fun for some minutes (view is distorted with every mode though).

Issues like this seemingly being completely ignored for such a long time probably do not contribute to a broader interest in VR gaming (on linux). Sure - Valve-time, but leaving the few users completely alone with it without any updates is not too great.

I have the same issue, Camera settings are accessible, but the camera isn't properly detected by vrserver so it cannot be used at all within SteamVR.

It's very frustrating not knowing whether that's simply unimplemented, or buggy, as it's not listed in the known issues.

Apart from @SkylerFur's comment I have seen no sign of it ever working on linux, though, but I really can't see much info about it.

I tried the latest release, old beta (linux_v1.14) and the current beta, with no result.

Since the logs mention vrserver trying to access the camera (“TrackedCamera: Couldn't find Dual Cameras at USB VID:28DE, USB PID:2400”), I wanted to strace it to have a sense of how whether it really tried accessing it and failed for some reason, but I couldn't find out how to launch it properly yet.

renaming vrserver to vrserver.bin and creating a vrserver script with

#!/bin/bash
strace -f -t -e trace=file  -o /tmp/vrserver.log bin/linux64/vrserver.bin "$@"

creates a valid strace log (including several video references - haven't looked at it too closely and maybe not only logging file access makes more sense here(?))
I only tried it with absolute path to vrserver.bin, but pwd is the SteamVR dir (so usually ~/.steam/steam/steamapps/common/SteamVR), so I assume above relative path does work.

Edit:
A little snip from the log:

163696 15:18:03 openat(AT_FDCWD, "/sys/class/video4linux/video1/device/../idVendor", O_RDONLY) = 183
163696 15:18:03 openat(AT_FDCWD, "/sys/class/video4linux/video1/device/../idProduct", O_RDONLY) = 183
163696 15:18:03 openat(AT_FDCWD, "/sys/class/video4linux/video1/index", O_RDONLY) = 183
163696 15:18:03 openat(AT_FDCWD, "/sys/class/video4linux/video0/device/../idVendor", O_RDONLY) = 183
163696 15:18:03 openat(AT_FDCWD, "/sys/class/video4linux/video0/device/../idProduct", O_RDONLY) = 183
163696 15:18:03 openat(AT_FDCWD, "/sys/class/video4linux/video0/index", O_RDONLY) = 183
163696 15:18:03 openat(AT_FDCWD, "/dev/video0", O_RDWR <unfinished ...>

the O_RDWR <unfinished ...> part doesn't really look correct I guess :)

For some reason, wrapping vrserver with a shell script stops it from working correctly. The logs do contain the same file access attempts than in your case, though, without the “unfinished” part:

136250 15:28:20 openat(AT_FDCWD, "/sys/class/video4linux", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 215
136250 15:28:20 openat(AT_FDCWD, "/sys/class/video4linux/video1/device/../idVendor", O_RDONLY) = 216
136250 15:28:20 openat(AT_FDCWD, "/sys/class/video4linux/video1/device/../idProduct", O_RDONLY) = 216
136250 15:28:20 openat(AT_FDCWD, "/sys/class/video4linux/video1/index", O_RDONLY) = 216
136250 15:28:20 openat(AT_FDCWD, "/sys/class/video4linux/video0/device/../idVendor", O_RDONLY) = 216
136250 15:28:20 openat(AT_FDCWD, "/sys/class/video4linux/video0/device/../idProduct", O_RDONLY) = 216
136250 15:28:20 openat(AT_FDCWD, "/sys/class/video4linux/video0/index", O_RDONLY) = 216
136250 15:28:20 openat(AT_FDCWD, "/dev/video0", O_RDWR) = 216

So it does seem to open it, and for some reason purely within its application code, decide it doesn't like it… I should have checked earlier, but while vrserver is running properly, it seems to hold a reference on the v4l2 device:

$ lsof /dev/video0
COMMAND      PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
Web\x20Th 150605 claire  200u   CHR   81,0      0t0  904 /dev/video0
steamtour 150774 claire  200u   CHR   81,0      0t0  904 /dev/video0
steamtour 150778 claire  200u   CHR   81,0      0t0  904 /dev/video0

I'm just messing around a bit with the broken VR variables as well and thought it didn't work correctly, because of my other changes. Sorry that I didn't mention it.

I've got a hold of Steam Support, and they stated the following:

Certain features of the Index headset are not supported on Linux. This includes Bluetooth features, base station power management features, firmware updates, microphone, and camera passthrough functionality, among other things. The Room View/camera passthrough feature hasn't been implemented on Linux yet, and the other features require a special type of device driver only available on Windows 10 to expose additional hardware functionality.

Steam Support has no information regarding patches or future updates, so I'd recommend adding your voice to the bug report you found if you have not already.

So it appears it's just not implemented yet, and it's not a hardware or software configuration issue.

I feel like we're really get back burnered here with 1.17 having the overlay draw ordering issues that got introduced in 1.15 still present and no desktop capture anymore.

Hmm, the camera V4L device has just stopped showing up for me recently. Is it just me?

Hmm, the camera V4L device has just stopped showing up for me recently. Is it just me?
Sort of, that sometimes happens to me. Try unplugging it from the electrical outlet and plugging it in again. Then it should reappear in the systems (just tested that with cheese and guvcview, and doing find /dev/v4l before and after replugging).

I found out I was using a USB port that can't support the number of USB devices on the Index. Changing to another USB port fixed the problem.

Could you elaborate on what the difference was in the spec of the port you
were on , and the one you moved over to?

On Thu, Nov 4, 2021, 8:27 PM yshui @.***> wrote:

I found out I was using a USB port that can't support the number of USB
devices on the Index. Changing to another USB port fixed the problem.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/SteamVR-for-Linux/issues/231#issuecomment-961600254,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJDKA67KL7AL6CFURDKKRTUKNFJVANCNFSM4ILERZGA
.

Since Valve has been inactive on this for so long, I decided to put something together: https://github.com/yshui/index_camera_passthrough

It is still incomplete, but I wanted to share so people know there is progress being made. Currently it just shows your camera in the VR space at a fixed location.

Thanks for your work on this, @yshui!

Update: I think I've got this program into a usable state, it does pretty sure everything I wanted it to do now. If someone can give it a go and tell me if it works for them, that will be appreciated!

@yshui works for me after adding a blank 1920×960 splash.png. The stereo view looks odd especially for close objects but I suppose it's due to how far apart the cameras are on the Index and not much can be done to improve that (I have never experienced the official camera passthrough features so I can't compare).

@ClearlyClaire Ah sorry I forgot to commit that file. Fixed now!

The official stereo view is definitely better than mine, but close objects looks weird (double vision is what I experience) in it too.

Is there a way to hack this work into SteamVR's room view somehow?

It might be possible to write a custom openvr driver that exposes the camera stream. But I am happy with what this can do so I won't spend time on that.

I'm just here writing a comment to remind Valve, that this issue still exists. I would love to use the camera outline-view for better orientation. As Valve is heavily into making everything Linux-playable. I don't get why they want all VR-players to get a Windows install. I don't have Windows and I don't want it.

Valve is heavily committed into making everything Steam Deck-playable, and the Deck doesn't officially supports VR. It's different. (BTW, it can run VR on Quest2 via ALVR, but it can't do VR with the Valve Index, something about direct mode not working)

But I have to say that I too would love this to be resolved, of course. VR is in kind of a low profile right now, although there are new, deep titles appearing on the store (RFVR, Soul Scathe, Barbaria, Green Hell VR, etc.). I hope VR gets on the spotlight again so Valve can justify investing on it for the tiny amount of us linux users.

Just a reminder, this is still an issue.

Just a reminder, this is still an issue.

SteamVR 2.0.x has complicated this as an issue, I can in HMD in the settings run the test Camera(s) and it works fully. It's an odd warped view, but it totally works. However no other aspect of SteamVR acknowledges a working HMD camera

Good to see them working on it, at least.

2.x has not seemed to fix this on my end

The issue still persists

February 2024. My Valve Index cameras don't respond either.

Since the camera shows up as a V4L2 device, vr-video-player (Arch, OpenSUSE TW) is also an option if you already have it. Eg vr-video-player --flat --no-stretch --video 'av://v4l2:/dev/video0' --mpv-profile low-latency . (vr-video-player uses libmpv so mpv's av://v4l2:/ URI syntax works with it too.)

The result is very cross-eyed though and I didn't figure out a way to adjust it to work.

The result is very cross-eyed though and I didn't figure out a way to adjust it to work.

You can fix that by recompiling vr-video-player after editing src/main.cpp and changing float offset = 0.0f; on line 2802 to float offset = -0.5f;.
Note that this program leaves a config file in ~/.config/vr-video-player/config in case you wonder why things like zoom values aren't restored when leaving them out of the command.
I prefer --sphere instead of --flat unless combined with --overlay.

Thanks, that fixed it.

I made up a quick and dirty patch to add a --eye-left-offset -0.5 CLI option so that I don't have to recompile it for every video. (Added to the OpenSUSE package already.)

From 92e96a15ac06f9da5a90ee61e94357c0b82e5053 Mon Sep 17 00:00:00 2001
From: Arnav Singh <[email protected]>
Date: Tue, 11 Jun 2024 02:26:07 -0700
Subject: [PATCH] Add `--eye-left-offset` to support overriding left eye
 offset.

Ref: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/231#issuecomment-2156754932
---
 src/main.cpp | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/main.cpp b/src/main.cpp
index 7e13ec9..d4a9871 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -394,6 +394,7 @@ private: // X compositor
 	double zoom = 0.0;
 	float cursor_scale = 2.0f;
 	ViewMode view_mode = ViewMode::LEFT_RIGHT;
+	double eye_left_offset = 0.0f;
 	bool stretch = true;
 	bool cursor_wrap = true;
 	bool free_camera = false;
@@ -637,6 +638,9 @@ CMainApplication::CMainApplication( int argc, char *argv[] )
 			zoom = atof(argv[i + 1]);
 			++i;
 			zoom_set = true;
+		} else if(strcmp(argv[i], "--eye-left-offset") == 0 && i < argc - 1) {
+			eye_left_offset = atof(argv[i + 1]);
+			++i;
 		} else if(strcmp(argv[i], "--cursor-scale") == 0 && i < argc - 1) {
 			cursor_scale = atof(argv[i + 1]);
 			++i;
@@ -2783,7 +2787,7 @@ void CMainApplication::RenderScene( vr::Hmd_Eye nEye )
 
 	if( nEye == vr::Eye_Left )
 	{
-		float offset = 0.0f;
+		float offset = eye_left_offset;
 		float scale = 0.5f;
 		if(view_mode == ViewMode::RIGHT_LEFT) {
 			offset = 0.5f;
-- 
2.45.2

if it hasn't finished booting then i guess it never finishes booting, because after being plugged in for hours this doesn't change and steamvr can't see the camera either... what's next to test to figure this out? can i do a firmware reflash and if so how?

eTronVideo_BootLoader suggests the headset's camera firmware is in some kind of inconsistent state after an update, I presume running a firmware update while missing the USB resources to access the camera results in this situation.

There must be some good method to force re-flash the whole firmware lineup for the headset to solve this issue.

@SpookySkeletons there's a method to do so.

1. Connect HMD to PC
2. Make sure camera shows as "eTronVideo_BootLoader" in devmgmt.msc
3. Switch SteamVR to beta branch "oculus_win7and8"
4. Launch SteamVR, it must have popup window saying that Camera firmware needs to be restored

you might want to try https://github.com/yshui/index_camera_passthrough

(recently found it, haven't tested it, but likely better than waiting for an official integration)

@ada-af there isn't devmgmt.msc on OP's Manjaro or on any Linux distro for that matter. But I presume you're referring to the list of devices, so looking at lspci would do… However, you're saying to switch to a branch that has "win7 and 8" in the name, which I'm not sure why would help here.

@Hi-Angel My bad, haven't noticed this is Linux discussion.

Still, can confirm that when there's firmware issue, dmesg mentions "eTron_Video_BootLoader"

@ada-af that's somewhat workable! I did not expect any sort of fix even on windows.