It is now possible to add usb devices both via vid+pid and via bus+addr
at the same time. To do this, the ids are directly
given to the corresponding command line options:
/usb🆔<vid+pids>,addr:<bus+addrs>
The dev option still works like before: /usb:id,dev:<vid+pids> or
/usb:addr,dev:<bus+addrs>
The /usb:dev command line option failed silently, because it tried to add the
devices before urbdrc gets initialized. This commit adds a new function
to udevman, that gets called when the urbdrc addin is initialized.
Registering of the given devices is now performed there.
Currently since the hash/keyCompare/keyClone members on the
context->cache were never being set, we were using the
HashTable_Pointer* variants, meaning that lookup always
failed (since we never ask for the same *pointer* twice).
This also revealed that the logic for autoallocate on these ops
was a bit backwards, and some error codes and support for the
"freshness" counter were missing.
In Win10 (at least with some card minidrivers) the freshness
counter is load-bearing and smartcard login won't work without
implementing a very basic version of it.
Refactored urbdrc_udevman_register_devices with its helper functions,
because the old implementation was a bit quirky. Removed a unsafe
strcpy, that led to a buffer overflow when given misonstructed command
line options. Doing something like "/usb:id,dev🔢1234##abcd:abcd"
won't work anymore, too.
* libusb polling thread now is responsible for hotplug registration
and removal as well as cleanup.
* Only register hotplug callback on systems with support.
- fixed and consolitate the duplicated code for sending the
CLOSE_REQUEST_PDU to the server into dvcman_close_channel
- call dvcman_close_channel if a dynamic channel plugin fails
to process the received channel data
- rdpegfx: don't try to remove a non-existing cache entry,
return an error instead which now will close the channel, as
expected by Microsoft's windows protocols test suite
