You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I thought this project might be particularly interesting for use on a VM host.
Currently, Qemu supports a simple emulated keyboard (PS/2 or USB, or more exotic buses on more exotic machine types), and it also supports USB device passthrough (by way of Spice project's usbredir).
On the off chance someone would want to use xMK with a virtual machine, it might save latency and other potential timing issues by connecting the virtual xMK device to the Qemu guest's USB bus, rather than to a virtual USB on the host that is then passed through back to the guest.
In other words, in order to use xMK on a VM (without running it natively inside the VM), currently we would do:
Keyboard → physical USB port → xMK → (USB over IP) virtual USB port → host machine → (USB over IP) virtual USB port → Qemu USB controller
But in a perfect world we would simply do:
Keyboard → physical USB port → xMK → (USB over IP) virtual USB port → Qemu USB controller
Probably the biggest blocker from having this "just work" with current code is that USBRedir is a completely different protocol from the USBIP that xMK is written against, though.
I was doing some reading, and back in 2010 there was a proposal to integrate USBIP into Qemu (instead of what became USBRedir). It didn't get implemented (and now we have USBredir), and their reasoning against USBIP was:
Still overall I agree with you that usbip is not very useful:
It is dead upstream
The libusb version of the usb-host software is quite ugly code (as the author admits it is a quick hack developed according to the test it, fix it, test it, till it works cycle).
The protocol itself is far from ideal.
Number 3 is the big deal breaker for me. I've looked at the (undocumented) protocol by sifting through the source. And it is very low level, all it does is shove usb packets back and forth over the network. It has no concept of configuration setting (the docs say make sure the device is in the right configuration before sharing it). No concept of caching things like descriptors, active configuration, per interface alt setting,
etc._[…]
Unfortunately, I don't see any more activity on the USBIP side of things since then, either. That is, USBIP is still, as Hans put it 13 years ago, "dead upstream."
I don't suppose switching from USBIP to USBredir would be simple, but it would probably provide a lot more flexibility and compatibility, too.
Anyway, I just wanted to mention this as a potential use case for xMK, though not without a project attached to it…
The text was updated successfully, but these errors were encountered:
Hi,
I thought this project might be particularly interesting for use on a VM host.
Currently, Qemu supports a simple emulated keyboard (PS/2 or USB, or more exotic buses on more exotic machine types), and it also supports USB device passthrough (by way of Spice project's usbredir).
On the off chance someone would want to use xMK with a virtual machine, it might save latency and other potential timing issues by connecting the virtual xMK device to the Qemu guest's USB bus, rather than to a virtual USB on the host that is then passed through back to the guest.
In other words, in order to use xMK on a VM (without running it natively inside the VM), currently we would do:
Keyboard → physical USB port → xMK → (USB over IP) virtual USB port → host machine → (USB over IP) virtual USB port → Qemu USB controller
But in a perfect world we would simply do:
Keyboard → physical USB port → xMK → (USB over IP) virtual USB port → Qemu USB controller
Probably the biggest blocker from having this "just work" with current code is that USBRedir is a completely different protocol from the USBIP that xMK is written against, though.
I was doing some reading, and back in 2010 there was a proposal to integrate USBIP into Qemu (instead of what became USBRedir). It didn't get implemented (and now we have USBredir), and their reasoning against USBIP was:
Unfortunately, I don't see any more activity on the USBIP side of things since then, either. That is, USBIP is still, as Hans put it 13 years ago, "dead upstream."
I don't suppose switching from USBIP to USBredir would be simple, but it would probably provide a lot more flexibility and compatibility, too.
Anyway, I just wanted to mention this as a potential use case for xMK, though not without a project attached to it…
The text was updated successfully, but these errors were encountered: