search

ThomasVon2021 / blikvm

Open and cost-effective "KVM-over-IP". BliKVM comes in 4 different models, v1 CM4, v2 PCIe, v3 HAT and v4 Allwinner, based on Raspberry Pi and Allwinner SoC.
https://thomasvon2021.github.io/blikvm/
GNU General Public License v3.0
355 stars 30 forks source link

[Feature Request] USB K/M pass thru #125

Open owendelong opened 5 months ago

owendelong commented 5 months ago

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.

ThomasVon2021 commented 5 months ago

I want to know why don't you connect the HID device to the target computer?

owendelong commented 5 months ago

I suppose that’s an option, but FWIW, this is a feature present on most IP KVM devices.

m50S79sM6SRNp8Jn commented 5 months ago

I want to know why don't you connect the HID device to the target computer?

The user may be 1000 miles away.

m50S79sM6SRNp8Jn commented 5 months ago

Related to https://github.com/ThomasVon2021/blikvm/issues/100

ThomasVon2021 commented 5 months ago

I want to know why don't you connect the HID device to the target computer?

The user may be 1000 miles away.

I didn't understand this reason, KVM and machine are in the same place.

owendelong commented 5 months ago

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. What I was hoping for was hostUSB->KVM->HID, 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.

hzzfly commented 5 months ago

Thank you for your suggestion. We have understood your needs and will start development at the right time.

owendelong commented 5 months ago

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:

-- Switch to screen -- Switch to the next screen after the current one (1->2->3->4->1) -- Switch to the previous screen (4->3->2->1->4) If multiple KVM units are being controlled, then / are used to toggle next/previous KVM unit. I realize that might be a tall order, but hey, if you don't ask, you never get. ;-)
hzzfly commented 5 months ago

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.

mluna0101 commented 4 months ago

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.

owendelong commented 4 months ago

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.

mluna0101 commented 4 months ago

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.

owendelong commented 4 months ago

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.

owendelong commented 4 months ago

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.

mluna0101 commented 4 months ago

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.

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.

owendelong commented 4 months ago

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: Bus 005 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1a86 QinHeng Electronics idProduct 0x7523 CH340 serial converter bcdDevice 81.34 iManufacturer 0 iProduct 2 USB Serial iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 104mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Device Status: 0x0000 (Bus Powered)

So the interface class is 0xff "Vendor Specific Class"

vs: Bus 003 Device 006: ID 046d:c077 Logitech, Inc. Mouse Bus 003 Device 008: ID 1b1c:1b4f Corsair [unknown]

The unknown Corsair device is a keyboard... Verbose: Bus 003 Device 006: ID 046d:c077 Logitech, Inc. Mouse Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 [unknown] bDeviceSubClass 0 [unknown] bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0xc077 Mouse bcdDevice 72.00 iManufacturer 1 Logitech iProduct 2 USB Optical Mouse iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0022 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 46 Report Descriptors: UNAVAILABLE Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 10 Device Status: 0x0000 (Bus Powered)

Bus 003 Device 008: ID 1b1c:1b4f Corsair [unknown] Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 [unknown] bDeviceSubClass 0 [unknown] bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1b1c Corsair idProduct 0x1b4f [unknown] bcdDevice 3.24 iManufacturer 1 Corsair iProduct 2 CORSAIR K68 RGB Mechanical Gaming Keyboard iSerial 3 0E020008AF4B8D245CBC9CCDF5001BC3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0042 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 192 Report Descriptors: UNAVAILABLE Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 29 Report Descriptors: UNAVAILABLE Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Device Status: 0x0000 (Bus Powered)