-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: switch between host/client via menu item #15
Comments
Amendment: |
I am not sure if I understand your intention of this requested feature correctly. But you can use screen sharing to control your iMac and never need to switch to host. |
No, I cannot, due to my particular VPN setup. Hence the requirement: "It is assumed that communication between VirtualKVM processes occurs strictly through the Thunderbolt connection (or lack thereof)." Even if I could, I really would prefer not to (a) make my iMac accessible via the public Internet, and (b) effectively round-trip packets over the Internet, through my employer's VPN gateway, and back, just to use the computer on my desk. |
Yes, you can. Your (at least my) macs can VNC/Screen Sharing using thunderbolt connection. You don't even need them have WiFi or ethernet enabled. When you connect macs with thunderbolt or ethernet cable, they can discover each other with Bonjour. You can verity it with Bonjour Browser. |
Thank you for the link. I've verified that Bonjour Browser works when my VPN is enabled, but Screen Sharing works if and only if the VPN is off. This makes a bit of sense; as far I know, Bonjour works at level 2 of the OSI stack, while Screen Sharing requires TCP (Bonjour Browser says so!). This doesn't directly solve my use case, but gives some ideas about how to communicate 1 bit of data between VirtualKVM processes. |
VirtualKVM v1.1.0 allows users to transfer control of a keyboard/mouse/display (in particular the iMac display) by connecting or disconnecting a Thunderbolt cable. My setup involves two computers that may be connected indefinitely, and I would like to avoid stressing the hardware with repeated (dis)connections. This request is for the addition of a menu item to transfer KVM control.
It is assumed that communication between VirtualKVM processes occurs strictly through the Thunderbolt connection (or lack thereof).
Changes to existing behavior
The "Auto Toggle Bluetooth" and "Auto Toggle Display" options of VirtualKVM v1.1.0 effectively allow a user to toggle the Bluetooth keyboard/mouse independently of the display. It does not make much sense to me for a wired connection to only toggle a wireless protocol and do nothing else. The below proposal removes this functionality.
Definitions
The abbreviations "TDM", "hBT", "cBT", and "cTB" stand for "Target Display Mode", "host Bluetooth", "client Bluetooth", and "client Thunderbolt", respectively. The prefixes "-" and "+" used with one of these abbreviations denote actions/events depending on the context. For example, "+TDM" means both "host enters TDM via key code 144" and "client observes TDM being entered via 'system_profiler SPDisplaysDataType'". Note that not all actions can be observed on the other end.
Proposal
The VirtualKVM menu on the host computer will have these items:
The menu on the client computer will have:
Notes:
When "Bluetooth follows Display" is enabled, both host and client watch for -TDM and +TDM events and react accordingly. This means that manually toggling the display via Command-F2 (as opposed to the VirtualKVM UI) will transfer control of the KVM to the client.
When "Auto Toggle Display" is enabled, the host will +TDM if a +cTB is observed. (-TDM always happens upon -cTB.)
When "Toggle Display" is selected on the host, these actions/events occur:
Host: +TDM
Client: nothing
When "Toggle Display" is selected on the client, these events occur:
Client: -cTB, wait 2x polling interval, +cTB
Host: -TDM (the OS should do this automatically in reaction to -cTB)
Thunderbolt can be enabled/disabled programmatically via some kernel extensions . I have not personally tried any of the cited tools.
The text was updated successfully, but these errors were encountered: