Repository navigation
fix(dashboard): 🐛 Fix SteamVR launch fail for dangling ADB process - #2757
Conversation
zmerp
changed the title
79ddef4 to
3ea68c4
Compare
|
Tested by @0JXI0, ready to review |
|
As things stand, probably this PR shouldn't be merged. I could get some help making another PR fixing this the proper way, as suggested by @The-personified-devil |
|
I mean I can take a look at it tmrw, but I'm not entirely sure how to ideally handle this yet |
|
@The-personified-devil We would need to detect if the current alive adb server is spawned from the current process or not. if it's the local ADB installation it's always spawned by the driver, if not then it's safe to let the ADB instance live because it will not block SteamVR. the crate sysinfo should be able to tell if the parent process is SteamVR (check if adb is spawned by the current process) |
3ea68c4 to
ac295a8
Compare
ac295a8 to
0822988
Compare
| if let Some(path) = adb::get_adb_path(&crate::get_filesystem_layout()) { | ||
| adb::kill_server(&path).ok(); | ||
| } |
There was a problem hiding this comment.
This is alright but it would unnecessarily kill a global adb server instance. Better would be to get only the local adb path and try to kill that. But better yet would be to get the current running adb processes and kill any that is child of SteamVR (vrserver). This last solution would also be resistant to edge cases where the users installs a global adb server while running SteamVR
There was a problem hiding this comment.
note though, i think you can't run two adb instances as well, so you kinda have to replace one instance with another anyway
|
This shouldn't be closed, still very much an issue |
|
Whops, this slipped through |
0822988 to
6c1cd1c
Compare
|
@The-personified-devil I finally implemented the check you requested months ago. I think the PR is ready |
| RichText::new(format!( | ||
| "ALVR requires running SteamVR! {}", | ||
| "Devices will not be discovered or connected" | ||
| )) |
There was a problem hiding this comment.
Huh? This is the exact same just more complicated
There was a problem hiding this comment.
No, rustmt was broken for a few lines around that bit because of the line that couldn't wrap. The reason this fix is here isolated is because i did some edits and then undid them. But yeah it's baffling that rustfmt hasn't fixed this issue yet.
There was a problem hiding this comment.
this issue haunts me as well, too long line? too bad, won't format at all.
No description provided.