The userland side consists of three programs and one header file:

wscons_event_dump.c - This is a simple wscons event dumper.  You give
it a /dev/wsmouseN or /dev/wskbdN device and it will dump the raw
wscons events are keys are hit or mouse movements and buttons are
used.

get_export_list.c - This is a very simple client that talks to a USBIP
server and asks for the exported devices.  It was written quickly
mostly and may have to be run more than once to get results.  It
really needs to read until it gets the entire export structure back.

t_usbip9.c - This is the 9th version of the test client and may be the
most functional.  It requires a number of arguments to work correctly:

t_usbip9 IP BUSID PORT DEBUG_LEVEL SLOW_POLL FAST_POLL POLL_MODE

IP - the name or IP address of the USBIP server

BUSID - the busid of the device that one wants to import and attach
to.  This will be known when a "bind" is done on the device or you can
run get_export_list mentioned above.

DEBUG_LEVEL - This is a bit field, and will accept hex input.  Use the
following:

        0x01nn - Control packet handling
        0x02nn - Interrupt packet handling
        0x04nn - Bulk packet handling
        0x08nn - Isochronous packet handling
        0x10nn - Network packet handling
        nn - debug level

As a practical matter, one can put in 0xffff and get full debugging
output, but you may not want to if the device is very chatty.  It is
possible to cause problems with timeouts due to the scrolling of the
debugging messages.

SLOW_POLL - In the main polling loop of the client this is the poll
interval used by network traffic and all end points except ISOCHRONOUS
end points.  Usually one can leave this at -1 which means wait until
there is something to read from vhci or from the network.

FAST_POLL - This is used by ISOCHRONOUS end points and should be 0 or
at least a very small number. (Although to be honest, it might work
with -1 too).

POLL_MODE - This is a bit map which will alter the behavior of the
polling loop.  Usually one can just use 0 which means honor the busy
flag, poll both network and incoming vhci packets when you have just
received a vhci packet, and check all endpoints for incoming packets
when any one of them have incoming packets.

        0x01 - Ignore busy endpoint flag (this one in partcular, is
	     probably a very had idea to set as one really should not
	     try sending anything to an endpoint waiting for a
	     response)
	0x02 - after doing a packet poll only for the network and not
	network and packet
	0x04 - strict sequence..  if a packet from a endpoint is
	handled, handle the network next rather then looking at the
	rest of the end points

Usually one can get away with running the client like this:

t_usbip9 <IP> <busid> 1 0 -1 0 0


usbip.h

It was thought that there might have to be a support library for the
USBIP protocol.  However, it ended up just being a header file.  This
header is more or less a translation of
https://www.kernel.org/doc/html/latest/usb/usbip_protocol.html into
stdlib.h types.  There is a lot of undocumented behavior in USBIP that
could only be found by working with it and packet dumps.  These are
mentioned in the source code for the test client.



More about the test client:

The test client starts out by doing a device import on the busid that
was asked for.  If this works, it calls the ioctl against the vhci
driver to attach to a port.  Then it enters the polling loop.

At start up, the polling loop waits only for vhci incoming packets as
there should not be anything from the network.  After the first vhci
packet is handled the loop will listen for both network and vhci
traffic.  Handling network traffic first, and then the 4 USB traffic
types for each end point (assuming that the end point has some
traffic, of course).

The client mostly just reports about exceptions and does a poor job at
recovering from them or otherwise exiting.  Further, the client makes
no use of the USBIP unlink calls to stop a already-sent USBIP packet
from hitting the device.

If the test client is interrupted or otherwise exits while there are
outstanding USB transactions going on it is very likely that the
kernel will panic.  This is both the fault of the client and the vhci
driver itself and maybe a bunch of other stuff.  It is very much like
pulling a USB device out while it is in use.

To build any of the userland code, simply unpack it and use the
Makefile provided.  That assumes that there is a parallel directory to
where the client code is called libusbip that contains the usbip.h
header file.