Open kzdixon opened 1 year ago
Hey,
super excited to see someone trying to get the beyond to work on linux and that you have made so much progress already :) Can't wait for mine to arrive.
Until then, since i'm very eager to find a solution (we apparently even both use the same graphics card)… i have a few ideas on what you could try. I had my own fair share of troubleshooting with SteamVR on linux in the last few weeks ^^;
I looked into your logs and i see several lines of "leaving standby" and "entering standby". That sounds to me like the proximity sensor works? Unless it means a different kind of standby…
If the display remains black, i can't help but wonder if that is a problem with the graphics output alltogether. I remember there being some bugs with Display Stream Compression on the newer AMD GPUs in latest linux kernels, though your version seems to be new enough so there shouldn't be any issues…
Still, i wonder if you might get different results if you set the Beyond to 70Hz (through the beyond config tool on Windows, and lets hope that will also carry over to linux then) and see if that helps.
Otherwise i would wonder if the GPU can output to the beyond under linux at all. If it's always black, the issue might be related to that for all we know. I wonder if there's a way to add the beyond's display to the desktop as a non-direct-mode video output device and see if you get an image that way?
Also… when in doubt… even though Wayland should have the best support with SteamVR nowadays, maybe it works better on X11?
I looked into your logs and i see several lines of "leaving standby" and "entering standby". That sounds to me like the proximity sensor works? Unless it means a different kind of standby…
Currently the only idle detection that seems to work is moving the hmd while tracked.
If the display remains black, i can't help but wonder if that is a problem with the graphics output alltogether. I remember there being some bugs with Display Stream Compression on the newer AMD GPUs in latest linux kernels, though your version seems to be new enough so there shouldn't be any issues…
No issues on Windows in either mode. Generally when DSC was busted like with the non-official-DSC-style 144hz mode on the Index, the VR view would appear in a window on the desktop and it would complain about not being in Direct Render mode. Initial attempt was in 75hz mode before I swapped over to Windows.
Currently the only idle detection that seems to work is moving the hmd while tracked.
Ah, i see. I also just saw the Invalid input type click for controller (/user/head/proximity)
line in the logs… Still, there should at least be output then while the headset is moving i think?
No issues on Windows in either mode. Generally when DSC was busted like with the non-official-DSC-style 144hz mode on the Index, the VR view would appear in a window on the desktop and it would complain about not being in Direct Render mode. Initial attempt was in 75hz mode before I swapped over to Windows.
Sure, but it could still be a linux-specific issue with one of those output modes.
Ah, i see. I also just saw the Invalid input type click for controller (/user/head/proximity) line in the logs… Still, there should at least be output then while the headset is moving i think?
That line shows up in the Windows logs as well so it isn't out of the ordinary apparently for this HMD. I was told that the prox sensor isn't fully exposed to OpenXR yet as well and is basically all managed on the deivce currently for its interactions.
Sure, but it could still be a linux-specific issue with one of those output modes.
Well... Both don't work :(.
That line shows up in the Windows logs as well so it isn't out of the ordinary apparently for this HMD. I was told that the prox sensor isn't fully exposed to OpenXR yet as well and is basically all managed on the deivce currently for its interactions.
Oh, that's unfortunate… hm.
Well... Both don't work :(.
Could still have something to do with the output not working in general. It would be cool if you'd check if you can get it do display something in non-direct mode or if it works with x11. Otherwise i will, but that might still take 2 months ^^
It would be cool if you'd check if you can get it do display something in non-direct mode or if it works with x11.
I was unable to do so after changing that property. It was an idea after the initial plug-in on Windows was showing the display extended to the device until it was set to the maximum resolution. After that, SteamVR figured out what to do and properly hid it from Windows.
I received my Beyond today. I experienced exactly the same as described in the original post: everything seemed to work out of the box, except for the part where the displays never turned on/were always black.
I'm using X11/Nvidia 3080/Manjaro.
I booted into windows, used the tool to change the refresh rate to 90, (verified that the device does work fine in windows), then booted back into linux. Now Steam-VR says "Failed to connect to headset display" with an option to restart Steam-VR.
Based on a pcap via Wireshark comparing between Win10 and Linux, it seems that this string of packets being sent to the device for full wake-up is missing:
810600220000
810600220000
810600220000
810600220100
810600220200
These are not present in the linux pcap Only present in the windows pcap They're all Request HID report with a response sent in top to bottom sequence each with a response HID report This looks like how you turn on the board inside The first two are sent to adjacent devices on the USB Last three are all sent to a single device 7.17.0 Those last three look like the board power on for the HMD Total size of the packet looks to be 36byte
Is it possible to replay these packets on Linux to wake it up manually?
Has anyone managed to make any further progress on this? I'd love to buy one of these but really want it to work on Linux.
I want to look into it myself if noone else does, but unfortunately i'm part of the European crowd and it looks like shipping there is still being delayed for a few more months at least
I read on the rFactor 2 discord that shipping is actually quicker unless you have prescription lenses. I think the March date is worst case. I'm based in the UK so I hope that's the case.
I'd love to buy one and don't mind tinkering around to get it working but I'm determined to stay away from Windows now that I've moved over and need to know the BSB will work on Linux.
I look forward to your exploits! Have you actually ordered one?
I read on the rFactor 2 discord that shipping is actually quicker unless you have prescription lenses. I think the March date is worst case. I'm based in the UK so I hope that's the case.
I recommend joining the Discord Server exclusive for people who bought a bigscreen beyond. Europe shipping has been delayed further and further because of legal requirements taking longer to resolve than expected and "late Q1" has been mentioned as the earliest realistic estimate very recently.
Edit: Just realized you haven't even ordered one. Uh, well, no discord access for you then until you do ^^; Maybe you should, or it will take even longer potentially? Who knows.
Edit Edit: maybe as a non-EU customer you might not be affected, who knows
Ah, good to know.
I'd love to order one, however, until I know they work on Linux or someone tells me that they will once we all work together to solve the issues, it's a lot of money to put down on something that may or may not work on my desired platform. So far I've not booted Windows for about 6 months and I'd like to keep it that way.
I previously had a G2 but when I switched to Linux even though some support exists in Monado I couldn't get working in my case. In theory, the BSB should be easier as it's native SteamVR.
I think I'd also be okay if someone said they are working on it, don't know when it'll be working but it will eventually work then I'd probably take the plunge. Then at least I could help with testing.
I'll be attempting to work on it once I've gotten my headset, still just waiting here in Australia with the shipping delays.
(Dont plan on moving back to windows either)
They are definitely not working on it themselves, and they have mentioned multiple times that it is not a something they are planning to do at all. often with very questionable explanations as to why. They seem to strictly believe the myth that Linux is a difficult unsupportable territory.
Their transparency on all kinds of issues, even directly from the CEO has been absolutely amazing and makes me appreciate what they do. But then, that same CEO posts a take along the lines of "it can never be supported until NVIDIA makes better drivers and DSC is supported on linux" and i just shake my head in disbelief, given that i'm literally using my Valve Index, with DSC, on linux, right now – using a graphics card made by a small unknown company called checks notes AMD – and i'm not sure what they are talking about regarding NVIDIA tbh? Does DSC not work on Linux with NVIDIA cards?
I think it's up to us as a community to prove them wrong and show them that one can make it work. Maybe they will pick up on it then.
I think you mean DSC and as of July last year, NVIDIA added support to the Linux driver so yeah, not sure what the CEO is on about. https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/238
Yeah I've got a NVIDIA RTX4090 and with the Index it's been pretty straightforward to setup. But I need higher res (and a lighter HMD of course!)
You keep talking, I might just place an order!
You keep talking, I might just place an order!
I mean, it's refundable. The way they interact with community and provide transparency about all kinds of hickups they face on the way and now even started actively supporting and embracing community mods has made me very appreciative what they do, even if i might need to put some work myself into getting it to work on linux ^^ If you preorder and join the server you can see it for yourself.
I placed a pre-order! I'll do what I can to get this going!
Is there a way to download the driver files without owning a Beyond?
@yshui it should be app 2467050
on steam\
So you should be able to get it by going to steam://install/2467050
@coolGi2007 neat, thanks.
Hmm, the driver manifest says it's resource only, but it does have a .exe
. How does SteamVR know it needs to run that exe?
The .exe included in it is for their own utility that does stuff like change the fan speed or brightness. Technically, it's not required for SteamVR, but it's a nice to have.
This is the first image I found on the Discord (message) for what the utility looks like
Hopefully someone can make a native Linux version (as I doubt wine likes apps talking to USB devices, although I haven't checked as my unit hasn't arrived) for at least changing the brightness and refresh rate.
If they release the source of this app, I would be very happy to buy a headset and work on porting it to Linux. The GUI is made with imgui and talking through USB is pretty doable.
I see, then it looks like Beyond is probably using the default lighthouse driver? Or is there a custom driver_xxxx.so
/driver_xxxx.dll
in ~/.local/share/Steam/steamapps/common/SteamVR/drivers/bigscreenbeyond
?
I see, then it looks like Beyond is probably using the default lighthouse driver?
Indeed! The main blocker right now are subtle differences in the lighthouse driver between Windows and Linux.
See https://github.com/ValveSoftware/SteamVR-for-Linux/issues/610#issuecomment-1761905276
~I created a Discord server where we can discuss Bigscreen Beyond on Linux. I thought it made sense to have a place to collaborate in while we try to get this thing working on Linux. Join us here: https://discord.gg/ztgm4eX72E~
You're now best off heading over to the Linux VR Adventures Discord for support issues as support for the BSB and other headsets will be landing in mainline Linux in due course. (source)
@kzdixon, can you provide that pcap you mentioned? It could be really useful to some of the other folks trying to work on this.
Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/610#issuecomment-1761905276
Could you like the pngcap of the specific packets. I'm trying to manually send those via with hidapi, but I can't understand what part of the usb packet those numbers represents.
Just as a side note / update for people watching this ticket who aren't wired directly into three different Discord servers, Bigscreen claims Valve needs to reach out to them to fix this. (I'm not sure if this means Bigscreen knows what's wrong with the driver and is just waiting for Valve to ask or what.)
There hasn't been much success with trying to reverse engineer things as outsiders.
The Bigscreen Beyond appears to work finally (display giving visible picture) on kernel 6.7.6 (zen in my case) with the following patches that have yet to be upstreamed:
Note: At least one of these patches had to be updated for the zen codebase I was using from zen-sources as of 6.7.5+.
Optionally, an EDID Quirk patch can be used just in case, but may not be necessary:
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3b4065099..639699e3b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -189,6 +189,9 @@ static const struct edid_quirk {
/* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
EDID_QUIRK('E', 'T', 'R', 13896, EDID_QUIRK_FORCE_8BPC),
+ /* Bigscreen Beyond Headset */
+ EDID_QUIRK('B', 'I', 'G', 0x1234, EDID_QUIRK_NON_DESKTOP),
+
/* Valve Index Headset */
EDID_QUIRK('V', 'L', 'V', 0x91a8, EDID_QUIRK_NON_DESKTOP),
EDID_QUIRK('V', 'L', 'V', 0x91b0, EDID_QUIRK_NON_DESKTOP),
The Beyond has been observed working on both Linux SteamVR 2.3.5 (1.27 should work as well I assume) and Monado via Envision.
As soon as those DSC patches get upstreamed (they were taken on a whim from https://github.com/santeri3700/vive-pro-2-on-linux/blob/master/KERNEL.md since DSC is involved with the Beyond as well), the Beyond should theoretically start working out of the box for users, though edits/updates to udev rules may be necessary for hidraw (not verified).
In theory this may prove that it was never a SteamVR issue after all but at the very least this gave us a spot to track the issue.
EDIT: Since I am on RDNA3 I can't speak to if this works or not on Nvidia but other users seem to imply that Nvidia may still have further work to do to allow the BSB's DSC setup to work properly.
EDIT 2: Small update... Seems this isn't quite stable yet and may not mingle well with further changes that 6.7.7 added in. Don't count on these few patches quite yet for solving Beyond on Linux as there is likely some more work to be done.
The EDID quirk is 100% necessary, upstream it when you can.
Wayland has no means to mark a display non-desktop && not many want to have to do this by hand each login.
Edit: These patches will presumably allow the vive pro 2 to function and possibly the upcoming somnium VR1 and much more exotic HMDs that are lighthouse based.
The Bigscreen Beyond appears to work finally (display giving visible picture) on kernel 6.7.6 (zen in my case) with the following patches that have yet to be upstreamed:
Hiya, as someone who doesn't have experience with patching kernels, how would I go about doing this? I'm running arch if that makes a difference I tried to look up tutorials for patching the Linux kernel, but they seem to be telling me to use a patch file of some kind, whereas the linked sites provided seem to just have text content, so I'm really not sure where to start. I'm buusy for the next few days but advice would be appreciated!
The Bigscreen Beyond appears to work finally (display giving visible picture) on kernel 6.7.6 (zen in my case) with the following patches that have yet to be upstreamed:
Hiya, as someone who doesn't have experience with patching kernels, how would I go about doing this? I'm running arch if that makes a difference I tried to look up tutorials for patching the Linux kernel, but they seem to be telling me to use a patch file of some kind, whereas the linked sites provided seem to just have text content, so I'm really not sure where to start. I'm buusy for the next few days but advice would be appreciated!
Pop over to this Discord: https://discord.gg/CTmD94Vw (Linux VR Adventures) when you're ready and someone will be able to help you.
Edit: These patches will presumably allow the vive pro 2 to function and possibly the upcoming somnium VR1 and much more exotic HMDs that are lighthouse based.
Vive Pro 2 will not work OOB due to nonstandard lens calibration config, In my Vive Pro 2 driver for Linux (https://github.com/CertainLach/VivePro2-Linux-Driver/) I had to use wine to call Vive provided calibration libraries directly.
Good to hear that my dsc bits-per-pixel patch can be useful for at least two VR headsets, maybe it is the time I will finally update and upstream it.
Wayland has no means to mark a display non-desktop && not many want to have to do this by hand each
Actually, you can replace headset EDID to provide display use-case as VR, Vive Pro 2 does that, and kernel respects this EDID section now, without need to rely on quirks.
Talking to the users on various discords it seems currently BSB is working well on AMD but haven't heard any feedback from anyone else on NVIDIA.
On NVIDIA, the non-desktop property is detected and set out of the box so the EDID patches aren't needed and the HMD display can wake up fine on SteamVR/Monado. However at least on my setup (Arch Linux, RTX 4090, proprietary nvidia-dkms 550.90 drivers) the BSB is stuck on a gray screen (which normally would indicate lighthouse tracking fail, though they work fine on Windows) and there's this rectangular plane of fuzzy static noise on the top half of both eyes that doesn't go away whether you're looking at SteamVR Home or demo apps like xrgears etc.
I took a badly lit picture of it here noise pattern looks like:
This was on the 90hz mode, I haven't tested 75hz yet.
From what I was able to find, on Nvidia it seems to be a general issue, which either requires someone to look into the Open Kernel from Nvidia, or Nvidia themselves fixing it on their side. https://forums.developer.nvidia.com/t/bigscreen-beyond-hmd-unable-to-be-initialized-on-nvidia-possibly-due-to-dsc-bpp-issue/294108
But if it works on AMD, that means the problem is definetly on the GPU driver side not somewhere else.
@Hisanatos I submitted that nvidia issue but I do not have an nvidia GPU nor a BSB to help debug this issue
All available in this thread please make an account on nvidia's issue tracker and relocate this problem to help nvidia address. Their rep needs more info on the issue ticket, please do send what you can.
@SpookySkeletons Why nvidia? I am experiencing this issue on my AMD GPU
Bigscreen Beyond HMD seems to have some hurdles to overcome for working properly on Linux.
~/.local/share/Steam/steamapps/common/Bigscreen Beyond Driver
to~/.local/share/Steam/steamapps/common/SteamVR/drivers/bigscreenbeyond
remedies this. Arch apparently did not need this tweak.lighthousedb.json
reports not being found under{bigscreenbeyond}
path. This error/warning invrserver.txt
does not occur on Windows.lighthousedb.json
under~/.local/share/Steam/config/bigscreenbeyond
.On Wayland with kernel 6.4.12, it appears as such via
xrandr
:I also pre-emptively added
to
/lib/udev/rules.d/60-steam-vr.rules
, assuming it would be necessary.After making the aforementioned tweaks to load the icons and such from the separate locations, we get to this state:
The display remains black, but we can view the mirrored view and see that it shows the dashboard and tracks properly with all four lighthouses that I have.
The best guess is that the proximity sensor either isn't working on Linux (doesn't seem to affect idle state if it times out from not moving), or that a proper display wake packet is just not being sent or being sent to the right place.
To Reproduce Steps to reproduce the behavior:
DP-3
inxrandr
). Leave Beyond unplugged.Expected behavior The Beyond HMD should output an image to the displays which should be visible through the lenses.
System Information (please complete the following information):
I verified that the Mic and Audio both work fine on Linux with SteamVR active. Only thing that seems to be missing in this puzzle is the proximity sensor (which works on Windows 10). Otherwise whatever sends the wake-up packet to the display should be the key.