It's possible that FreeRDP was built against FFmpeg, but it doesn't support
H.264. In that case, just continue without H.264 support instead of failing
hard before even trying to connect.
This is especially useful for Linux distributions which can't ship H.264
support in FFmpeg out of the box (patent issues), but allow enabling H.264
later by installing a version of FFmpeg which has it enabled.
In case the seat has no default_cursor, which happens on client device with
no mouse attached (e.g. tablets), freerdp would fail to connect because it
won't be able to set cursor image. Check for this condition and skip setting
the cursor image.
Signed-off-by: Marek Vasut <marex@denx.de>
In either case of wlf_handle_touch_up()/wlf_handle_touch_down(), the
UINT16 flags are set to fixed values, so there is little reason for
checking presence of specific flag in them again. The conditional is
always true no less, so just call freerdp_input_send_mouse_event().
Moreover, the flags submitted to the remote are wrong. The code should
send BUTTON1/DOWN/MOVE on wlf_handle_touch_down(), so the remote would
pick not only the button down event, but also the coordinate update,
else the remote would receive a mouse click at the wrong coordinates.
The wlf_handle_touch_motion() should update the pointer location too,
make it send plain MOVE event.
Signed-off-by: Marek Vasut <marex@denx.de>
The wlf_handle_touch_down() implements fallback to mouse event submission
in case RDPEI is not available. This fallback is currently never reached,
because the WINPR_ASSERT(rdpei); triggers before the fallback conditional
is reached.
Move the WINPR_ASSERT(rdpei); after the RDPEI availability check to permit
the fallback to do its job.
Signed-off-by: Marek Vasut <marex@denx.de>
This partially reverts commit 67f3fff2. The legacy provider is now loaded
from the `winpr_InitializeSSL` function, so it is not needed to load it from
the `winpr_RC4_New` function again.
The `winpr_enable_fips` function is called twice from the `winpr_InitializeSSL`
function after commit 49936a7b. I believe this is a bug, which might lead to
some undesired behavior. Let's call that only once.
With OpenSSL 3.O, FreeRDP log contains errors like:
```
4036740A4C7F0000:error:0308010C:digital envelope routines:
inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:346:
Global default library context, Algorithm (MD4 : 85), Properties ()
```
This leads to connection failures in some cases. This is because algorithms
like MD4 are now part of the legacy provider, which is not loaded by
default. Let's explicitly load that provider. With this change, also the
other provides has to be explicitely loaded.
* fix libusb libusb_device usage (manually unref required usb devices, versus freeing all when we still hold references to the ones we want)
* disabled detach_kernel_driver & attach_kernel_driver on win32 since libusb does not support them
* fixed libusb async event handling
* add log for transfer request error
* Update libusb_udevice.c
* refactor code
