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.
Use memcpy to copy the bytes when we can assure that the memory areas does not overlap.
When the areas overlap, copy the area that doesn't overlap repeatly.
With this change, the copy is ~30x faster.
The length check and field sizes in _update_read_pointer_large
were off, corrected according to [MS-RDPBCGR] 2.2.9.1.2.1.11
Fast-Path Large Pointer Update (TS_FP_LARGEPOINTERATTRIBUTE)
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.
In case xf_OutputExpose is called with GFX or async-update a race
condition occured in combination with dynamic-resolution.
To prevent the deadlock update the screen on a best effort basis.
In desktop area, the next color has high odds to be the same of previous color.
If we cache the value, it can be reused by the next pixel avoiding recalculation.
This optimization can halve the function's processing.
O_TMPFILE is used since version 2.0.0 and
52ef8079ea
However, this will result in the following build failure on uclibc or
uclibc-ng:
/home/fabrice/buildroot/output/build/freerdp-2.0.0/uwac/libuwac/uwac-os.c:228:18: error: ‘O_TMPFILE’ undeclared (first use in this function); did you mean ‘EMFILE’?
fd = open(path, O_TMPFILE | O_RDWR | O_EXCL, 0600);
^~~~~~~~~
EMFILE
To fix this build failure, define O_TMPFILE if needed
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
