Skip to content
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

Open
donaldchai opened this issue Oct 3, 2015 · 5 comments
Open

Feature request: switch between host/client via menu item #15

donaldchai opened this issue Oct 3, 2015 · 5 comments

Comments

@donaldchai
Copy link
Contributor

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:

  • Host Mode: ...
  • (checkbox) Auto Toggle Display
  • (greyed-out if above checked, or unconnected) Toggle Display
  • (checkbox) Bluetooth follows Display (or something to this effect)

The menu on the client computer will have:

  • Client Mode: ...
  • (greyed-out if unconnected) Toggle Display
  • (checkbox) Bluetooth follows Display (or something to this effect)

Notes:

  1. If "Bluetooth follows Display" is checked on only one machine, the behavior is undefined.
  2. I don't know of a simple way to grey-out "Toggle Display" on the client if "Auto Toggle Display" is enabled on the host. In this case, selecting "Toggle Display" will have no lasting side effects, but is expected to toggle things back and forth. Users with "Auto Toggle Display" will not interact with the menus very often, so I don't consider this to be a serious issue.

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.

@donaldchai
Copy link
Contributor Author

Amendment:
When "Toggle Display" is selected on either machine (and "Bluetooth follows Display" is enabled), Bluetooth should be disabled immediately instead of waiting for the next {-,+}TDM event. This should expedite the transfer of any peripherals.

@xlc
Copy link
Contributor

xlc commented Apr 24, 2016

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.

@donaldchai
Copy link
Contributor Author

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.

@xlc
Copy link
Contributor

xlc commented Apr 26, 2016

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.

@donaldchai
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants