Aside not being well written code, it did not consider that the
pumptools's piuio API is abstracting any kind of sensor multiplexing
to hardware.
With the game still calling the libusb API like usual, which is
8 calls (4 ins and 4 outs) for a single IO state update, this layer
issued 4 times as many calls to any pumptools piuio API implementation.
When using the piuio-real wrapper impl. this means that the real IO
hardware was polled 4 times as often as the game actually intended to
do.
That might have also lead to rather high CPU load on older hardware,
e.g. stock MK6/9 builds.
If you also have the piubtn connected, it will be opened as well, hitting
the open section in the module. It did forward everything correctly, but
the warning didn't make any sense because the same device was not opened
again. Re-work the code to create a meaningful flow. Also return the open
handle if it ever happens that the device gets re-opened without being
closed.
Required for piuio-khack which needs to convert a single libusb
call into 8 separate calls. In that case, we want to advance the
handlers downstream but reset it once we go back up to the invocation
which needs to scatter to multiple calls. As stated by the documentation,
state handling of the irp is not taken care of. This is fine, since
at this point, we don't know what the function is and the caller needs
to take care of regarding saving and recovering any state in the irp.
This module takes care of emulating the ITG 2 piuio kernel driver
hack. As a separate module, this can be hooked into any chain of
existing hooks providing a greater level of flexibility and
transparency.
