[Feature Request] USB K/M pass thru #125
Comments
|
I want to know why don't you connect the HID device to the target computer? |
|
I suppose that’s an option, but FWIW, this is a feature present on most IP KVM devices. |
The user may be 1000 miles away. |
|
Related to #100 |
I didn't understand this reason, KVM and machine are in the same place. |
|
There's no special reason other than wanting to keep the cable paths for the display and the USB parallel... In your scenario, it's hostUSB->HID and hostHDMI->KVM->Monitor. This becomes even slightly more desirable when you consider that the KVM is connecting to the control and HDMI and USB ports of a multiport KVM which then connects to the HDMI and USB ports of the multiple target hosts. I have it working as HID->Multiport->Host(s) and Monitor->v4->Multiport->hosts, but I would prefer to be able to go HID+Monitor->v4->multiport->hosts. At this point, since the multiport has enough USB ports to accommodate both the v4 and the HID, it's not a major issue, but FWIW, some multiport solutions are a bit short on USB ports, so this would be important in some of those cases. |
|
Thank you for your suggestion. We have understood your needs and will start development at the right time. |
|
I did find an additional reason... The multiport KVM may be inconveniently located and you cannot connect both the remote control and the BLIKVM v4 to the multiport KVM at the same time. While the local K/V/M don't have access to the v4 UI, it would be nice to add a hot-key sequence to the v4 that would allow you to command it to switch the multiport (if attached). Many KVMs implement this using one or more of a CTRL or ALT or CMD key (either left or right, usually not both), Caps-Lock key, or Scroll-Lock key. The best implementations provide this as a configurable choice. Usually it requires a rapid double-tap of the hot-key followed by one of the following sequences: I realize that might be a tall order, but hey, if you don't ask, you never get. ;-) |
|
You envisioned a great use case and I already understand the need for this feature. We will design a solution that is suitable for this application scenario. |
|
This is useful when you don't have the multiport KVM-over-IP. It's true that you can connect directly to the machine but it just makes sense to passthrough the USB in some scenarios. (Like not having more than one USB port available) Please don't make this the default behavior. Rather give the user a "USB PASSTHROUGH" button in the web interface and a command in the CLI as it's also useful to have a USB available for the Blicube itself. |
|
I don't think there's any benefit to having an HID device speak to the BLIKVM on USB. Sure, Mass Storage and other types of devices, but HID class devices (unless I'm missing something) serve no purpose on the BLIKVM and should just be automatically passed through. |
|
I don't know if USB to RS232 adapter falls under HID, which is used to control the Blicube multiport KVM-over-IP switch, but I don't want to make assumptions here. If it does then you would be passing the switch control to the remote machine and it would never work. That's why I'm saying that it is best to give the user the control and decide if they want to passthrough the USB port or not. Something as simple as having a "passthrough" button for the web interface and a command for the terminal would work great. |
|
That comes in on the USB-C port... I'm proposing that this only be applied to the vertical USB-A port, so it should be distinguishable that way. |
|
The problem here is that because pass thru is for use when local (not via the web interface), a button on the web interface is very awkward for the user present at the KVM trying to do work in the data center. |
That does not come in on the USB-C port. If you have a BliKVM v4 Allwinner and a KVM-over-IP switch, the control cable that comes with the kit goes to the vertical USB-A port. If you take that away there's no other means of controlling the KVM-over-IP switch making it pointless. |
|
I stand corrected... I had misremembered the cabling. However: As you can see from the below lsusb output, the CH340 is USB Interface class 0xff (Vendor Specific Class) and they keyboard and mouse are both USB Interface class 0x03 Human Interface Device. This does, however, mean that to use it with the multiport KVM, a hub will be needed on that port (not really a big deal). But it is safe to pass through HID devices, since only devices that provide a Human->Machine interface should be in that class (e.g. pointers, keyboards, game controllers, etc.). This entire class of device has no meaning to the KVM directly. Bus 005 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter Verbose: So the interface class is 0xff "Vendor Specific Class" vs: The unknown Corsair device is a keyboard... Bus 003 Device 008: ID 1b1c:1b4f Corsair [unknown] |
It seems to me that there's no "USEFUL" application for a keyboard or mouse plugged into the USB port in the current operating environment. However, mass storage devices are a different story.
As such, I think the ideal behavior would be to set up a daemon that can be attached by UDEV rules when an HID device is connected to the vertical USB port on the v4 (possibly equivalent places on other KVM models) which would essentially pass the HID device through to the target host as if it were directly connected to the target host.
This would allow a local KB and/or Mouse to act in the same manner as the HDMI pass thru while still preserving the ability for mass storage and other devices to be used for emulation/etc. as currently practiced.
This would bring the behavior of the BliKVM v4 much closer to user expectations from a KVM device. I admit I have no idea how easy or hard this will be to code.
The text was updated successfully, but these errors were encountered: