Currently TLS version 1.0 is used implicitly by using the TLSv1_method.
To be able to also use TLS 1.1 and later use SSLv23_client_method
instead. To make sure SSLv2 or SSLv3 isn't used disable them.
Extend winpr and client/common to support a new option "/buildconfig".
When used build the following build specific information is print:
* cmake options
* cflags
* compiler
* target architecture
* cmake build type
With this commit the "exported" components (usable with pkg-config and
cmake find module package)
* winpr - winpr library and headers
* freerdp - core library and headers
* freerdp-client - client specific library
* freerdp-server - server specific library
* rdtk - rdtk headers and library
To allow the installation of multiple different version (different major
number) the include files were moved into the respective sub folder:
freerdp -> freerdp{MAJOR}/freerdp (currently freerdp2/freerdp/)
winpr -> winpr{MAJOR}/winpr (currently winrp1/winpr/)
rdtk -> rdpk{MAJOR}/rdtk (currently rdtk0/rdtk/
The generated pkg-config and cmake find modules now also include the major
version number. Currently the following pkg-config are generated and
installed.
* winpr1
* freerdp2
* freerdp-server2
* freerdp-client2
* rdtk0
As cmake is able to handle multiple versions out of the box the
following can be used to find a specific module:
find_package(WinPR)
find_package(FreeRDP)
find_package(FreeRDP-Server)
find_package(FreeRDP-Client)
find_package(RdTk)
As cmake doesn't automatically resolve dependencies for packages it is
necessary to manually include the requirements. For example if
FreeRDP-Client is required WinPR and FreeRDP need to be included
(find_package) as well.
This commit also fixes the installation when STATIC_CHANNELS are built.
WITH STATIC_CHANNELS all channels are linked into libfreerdp-client, for
this all channels are generated as linker archive and linked together in
the final step. Before the intermediate linker archives were, although
not required and useful, installed. Same applies for server side
channels.
It will be completely possible to implement subsystem with only include/freerdp/server/shadow.h and libfreerdp-shadow.
Details as following:
1. Exported surface structure as subsystem implementations deeply depend on it to send image update
2. Export capture APIs. They are actually indepent APIs to help compare and calculate image difference.
3. Introduce API to trigger client frame update. Conceal details in subsystem->updateEvent
4. Pass client to client callbacks. Subsystem implementation may need to know 'which client' send the interaction event as well as the authentication request.
Add this support in callback definition before anyone really use shadow framework APIs to implement a custom subsystem.
Also added callback for client capability exchange
5. Remove X11_ShadowSubsystem Mac_ShadowSubsystem Win_ShadowSubsystem from libfreerdp-shadow.
Discard FREERDP_API mark on ShadowSubsystemEntry functions and make them be compiled together with shadow.c in CMakeLists.txt.
This is required from PR #2751.
Now subsystem implementations and shadow.c could be regarded as an example for shadow framework.
The Miscellaneous section is chosen because choosing not to map the
buttons is not a property of the input system, but rather an ad-hoc
setting to be applied to this session.
In case the old behaviour of not reverse-mapping the mouse buttons is
desirable, a command-line option is added to disable the mapping. This
option is made experimental for the time being.
The default is to do the reverse mapping, as this is the intuitive
behaviour (the mouse then works as it would on the console).
If XInput extension is available, then find the (first) pointer device
and use the button mapping of that one. If there are more than one
pointer devices, they could have different button mappings, but it is
not clear how this should be communicated to the RDP server.
If XInput is not available, attempt to fallback to the old global
mapping. (This mapping exists, but is not correct if there actually
is an XInput extension loaded, as it is then not used).
RDP expects to receive an indicator of the physical mouse button that
was pressed on the client, whereas X11 deliver a value for which
logical mouse button that was pressed.
This patch introduces a (reverse) mapping from logical mouse buttons to
physical mouse buttons, so that the RDP server can do correct mapping
for the event on its end.
However, no actual mapping is done here; this patch just introduces the
framework to do so. Thus, there should be no behavioural change from
this patch alone.
There is an implicit assumption that only the first three buttons are
mapped to eachother. Enabling more a general mapping would require
extensive changes to the event handling as fourth logical button and
up is used for special functionality such as wheel.
Horizontal mouse wheel input capabilities are now checked
and if available mouse buttons 6 and 7 are mapped to the
horizontal wheel for the X11 client.
