fix(dashboard): 🐛 Fix SteamVR launch fail for dangling ADB process #2757
Conversation
zmerp
changed the title
zmerp
force-pushed
the
kill-adb-on-launch
branch
4 times, most recently
from
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) |
The-personified-devil
force-pushed
the
kill-adb-on-launch
branch
from
3ea68c4 to
ac295a8
Compare
The-personified-devil
force-pushed
the
kill-adb-on-launch
branch
from
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
No description provided.