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
Although Microsoft uses 1-based numbering on the wire for indexing the
GFX bitmap cache entries, the code in FreeRDP uses 0-based numbering and
therefore the name MaxCacheSlots is less confusing.
Weird but Microsoft uses 1-based indexing in the RDPGFX bitmap
cache PDU's.
This does not seem to be documented but can be deducted from the
RDP client test code in Microsoft's "Windows Protocol Test Suites"
GitHub repository and the observation that mstsc aborts with a
protocol error if the cacheSlot index value 0 is used in e.g. a
GFX surface to cache PDU.
* Now both, dynamic and static channel entries can be defined by
a single channel.
* Added better logging to distinguish between static and dynamic
channel messages.
