- handle WAIT_TIMEOUT result as error in async transport thread
if an INFINITE timeout was specified in WaitForMultipleObjects
- fix mfreerdp's async transport handling to not use
freerdp_get_event_handles/freerdp_check_event_handles if async
transport is activated
1)
Added missing checks for CreateEvent which also required the
following related changes:
- changed freerdp_context_new API to BOOL
- changed freerdp_peer_context_new API to BOOL
- changed pRdpClientNew callback to BOOL
- changed pContextNew callback to BOOL
- changed psPeerAccepted callback to BOOL
- changed psPeerContextNew callback to BOOL
2)
Fixed lots of missing alloc and error checks in the
changed code's neighbourhood.
3)
Check freerdp_client_codecs_prepare result to avoid segfaults
caused by using non-initialized codecs.
4)
Fixed deadlocks in x11 caused by missing xf_unlock_x11() calls
in some error handlers
5)
Some fixes in thread pool:
- DEFAULT_POOL assignment did not match TP_POOL definition
- don't free the pool pointer if it points to the static DEFAULT_POOL
- added error handling and cleanup in InitializeThreadpool
- removed some unneeded null checks for free()
- fixed a memory leak in shadow_client
- removed rfx_compose_message_header from API
Changed the following functions to BOOL, check the result
where they are called and handle failures:
- rfx_compose_message
- rfx_compose_message_header
- rfx_write_tile
- rfx_write_message_tileset
- rfx_write_message_frame_begin
- rfx_write_message_region
- rfx_write_message_frame_end
- rfx_write_message
rfx_process_message:
- check memory allocation failures
- verify protocol-conform order of data messages to prevents memory
leaks caused by repeated allocations
- verify that header messages were parsed/received before the
data messages
- treat unknown rlgr mode as error
- fixed/added error handling
- fixed all callers to check/handle result
rfx_encode_message:
- fixed incorrect usage of realloc
- missing malloc check
- missing check of CreateThreadpoolWork
- correct cleanup on failure (threadpool, memory)
- check rfx_encode_message result
rfx_encode_messages:
- check rfx_split_message result
- correct cleanup on failure
- prevent memory leak on failure
rfx_write_message_context:
- fixed invalid channelId value (must be 0xFF for WBT_CONTEXT)
rfx_process_message_codec_versions:
- fixed invalid read size of codec_version (it is 16bit)
rfx_process_message_channels:
- verify protocol conform channelId value
rfx_process_message_region:
- replaced invalid reallocs with malloc
- read and verify regionType and numTileSets from stream
rfx_process_message_tileset:
- check allocation results
- fixed incorrect usages of realloc
setupWorkers:
- fixed incorrect usages of realloc
rfx_split_message:
- removed dead code
- missing malloc check
rfx_compose_message:
- fixed a memory leak
- check/handle rfx_encode_message result
* top level GDI functions return 0 on error and != 0 otherwise but the
low level functions (16bpp.c, 8bpp.c 32bpp.c) which are called did it
exactly the other way around. Those were adapted.
* change gdi_InvalidateRegion to BOOL and check calls where appropriate
* integrate comments from pull request
The window width/height variables and in turn SmartSizingWidth/Height
get automatically updated in th the configure notify event handler.
If the window is created initially the values don't differ from the
event values and therefore SmartSizing was not applied until the
window was resized.
- make smart-sizing work again which was killed in previous commits
- removed several unnecessary/ugly workarounds
- miscellaneous small fixes
- new feature: restore previous window position when toggling out of
fullscreen mode
- new feature: if /f is specified in combination with /smart-sizing:WxH
we run the session in the /smart-sizing dimensions scaled to full screen
Since several contributers in the past repeatedly made the error
to treat xfc->width and xfc->height as equal with the x11 window
width and heigth I've renamed these variables to sessionWidth and
sessionHeight.
+ add: COMMAND_LINE_IGN_UNKNOWN_KEYWORD flag for CommandLineParseArgumentsA to ignory unknown keys without fail
+ add: lot of WLog_DBG() in drdynvc, add function names in existing
* change: error text in rdpsnd OSS
* fix: dev in rdpsnd does not work
* fix/change: audio-dev renamed to dev and now work in audin
* fix dynamic channels now work again
Command line detection is run with dummy settings where not everything
is allocated. Collections (device, dynamic channel and static
channel) didn't handle this case properly.
Small cleanup of passing around decorations flag.
Limit PercentScreen to single monitor vs. entire desktop. IMO - this is better behavior in a multimonitor environment.
Handle fullscreen windows better:
1. Ensure that size hints are set to allow resizing before setting a window to fullscreen as some window managers do not behave properly.
2. Handle fullscreen toggles without destroying and recreating window.
3. Use NET_WM_STATE_FULLSCREEN Extended Window Manager Hint for fullscreen functionality
4. Use the NET_WM_FULLSCREEN_MONITORS Extended Window Manager Hint when appropriate
5. When a single monitor fullscreen is requested - use the current monitor(as determined from mouse location)
6. Handle cases where there is no local monitor at coordinate 0,0. The Windows server expect there to be a monitor at this location, so we maintain offset if necessary between our local primary monitor and the server side primary monitor located at 0,0.
1. Don't draw to screen if server sends begin/end paint
messages without any real updates.
2. Redraw only summary region that covers really invalidated
part of screen.
Remove use of the visibleOffset, this completely breaks the display of all windows except for the main application window. Instead,
just maintain a local offset correction of the windowOffset.
Apply workaround to determining the workArea for remote app mode.
Since XWarpPointer generates an pointer motion event, as if the mouse
was moved by hand, xfreerdp sends back the received mouse position to
the server. This behavior is wrong since pointer positions set via
server pointer update pdu shouldn't get sent back to the server
(it's not a "real" mouse move).
To fix this problem change the x windows event mask to not handle
pointer motion events before setting the new pointer position and change
it back again afterwards.
Possible downside of this is that some pointer motion events might get
lost but this shouldn't be noticeable.
Thanks to nfedera for the neat idea ;).
The input->FocusInEvent callback implementations (normal and fast-path) have
always sent the mouse position even if the pointer was outside of the freerdp
client area. In addition xfreerdp used the wrong pointer coordinates which
were relative to the root window instead of its own.
On focus-in the pointer position must only be sent if the pointer is
currently within the program's client area. However, the clients had no way
to pass that information to input->FocusInEvent which required an API change.
- removed mouse pointer x, y parameters from input interface's FocusInEvent
- clients are responsible to call input->MouseEvent on focus-in if necessary
- fixed xfreerdp and wfreerdp accordingly
Note: /gdi:sw was working fine, this commit fixes /gdi:hw
* calculate color channel shifts based on X11 visual color masks
* fast path to skip conversion if visual color masks equal rdp color masks
* successfully tested 8/15/16/24/32 bpp rdp sessions on 16/24/32 bpp visuals
* fix problem with REMOVE_DUPLICATES on undefined lists
* since 3.1 file(GLOB FILEPATHS RELATIVE .. returns single / instead of // as
previously - necessary adoptions for regex and matches done. Should
work with all cmake versions.
Tested with 3.1.0-rc3
Set the following policies to "OLD" if cmake version is greater than
2.8.12:
CMP0026 - Disallow use of the LOCATION target property
CMP0045 - Error on non-existent target in get_target_property
[MS-RDPBCGR] Section 5.3 describes the encryption level and method values for
standard RDP security.
Looking at the current usage of these values in the FreeRDP code gives me
reason to believe that there is a certain lack of understanding of how these
values should be handled.
The encryption level is only configured on the server side in the "Encryption
Level" setting found in the Remote Desktop Session Host Configuration RDP-Tcp
properties dialog and this value is never transferred from the client to the
server over the wire.
The possible options are "None", "Low", "Client Compatible", "High" and
"FIPS Compliant". The client receices this value in the Server Security Data
block (TS_UD_SC_SEC1), probably only for informational purposes and maybe to
give the client the possibility to verify if the server's decision for the
encryption method confirms to the server's encryption level.
The possible encryption methods are "NONE", "40BIT", "56BIT", "128BIT" and
"FIPS" and the RDP client advertises the ones it supports to the server in the
Client Security Data block (TS_UD_CS_SEC).
The server's configured encryption level value restricts the possible final
encryption method.
Something that I was not able to find in the documentation is the priority
level of the individual encryption methods based on which the server makes its
final method decision if there are several options.
My analysis with Windows Servers reveiled that the order is 128, 56, 40, FIPS.
The server only chooses FIPS if the level is "FIPS Comliant" or if it is the
only method advertised by the client.
Bottom line:
* FreeRDP's client side does not need to set settings->EncryptionLevel
(which was done quite frequently).
* FreeRDP's server side does not have to set the supported encryption methods
list in settings->EncryptionMethods
Changes in this commit:
Removed unnecessary/confusing changes of EncryptionLevel/Methods settings
Refactor settings->DisableEncryption
* This value actually means "Advanced RDP Encryption (NLA/TLS) is NOT used"
* The old name caused lots of confusion among developers
* Renamed it to "UseRdpSecurityLayer" (the compare logic stays untouched)
Any client's setting of settings->EncryptionMethods were annihilated
* All clients "want" to set all supported methods
* Some clients forgot 56bit because 56bit was not supported at the time the
code was written
* settings->EncryptionMethods was overwritten anyways in nego_connect()
* Removed all client side settings of settings->EncryptionMethods
The default is "None" (0)
* Changed nego_connect() to advertise all supported methods if
settings->EncryptionMethods is 0 (None)
* Added a commandline option /encryption-methods:comma separated list of the
values "40", "56", "128", "FIPS". E.g. /encryption-methods:56,128
* Print warning if server chooses non-advertised method
Verify received level and method in client's gcc_read_server_security_data
* Only accept valid/known encryption methods
* Verify encryption level/method combinations according to MS-RDPBCGR 5.3.2
Server implementations can now set settings->EncryptionLevel
* The default for settings->EncryptionLevel is 0 (None)
* nego_send_negotiation_response() changes it to ClientCompatible in that case
* default to ClientCompatible if the server implementation set an invalid level
Fix server's gcc_write_server_security_data
* Verify server encryption level value set by server implementations
* Choose rdp encryption method based on level and supported client methods
* Moved FIPS to the lowest priority (only used if other methods are possible)
Updated sample server
* Support RDP Security (RdpKeyFile was not set)
* Added commented sample code for setting the security level
xf_cliprdr_process_selection_notify calls xf_cliprdr_send_client_format_list
if the SelectionNotify event property was None.
xf_cliprdr_send_client_format_list called XConvertSelection even if there
was no clipboard owner. In that case the XServer generates a SelectionNotify
event to the requestor (us) with property None and so on ...
The most obvious fix is to ensure that XConvertSelection is not called if
the owner is None which is done in this commit.
In case of server side initiated desktop resize it could happen that the
client was "scaling" even if smart-sizing was disabled. The reason for
this was that the "scaled" width and height was set when the X Configure
event arrived but not in xf_desktop_resize.
* fixed crash on server-initiated desktop resize and fullscreen toggle with /gdi:sw
* implemented desktop resize for /gdi:sw
* check for availibility of XRender extension and show error messages if a setting would require it
* fixed compile error if xrender devel packages are missing
* fixed bug with server-initiated desktop resize in fullscreen mode
Most of xfreerdp's hw gdi callbacks did the the same X11 drawing operation
twice: Initially on the primary pixmap to keep the back buffer up to date
and then directly on the window in order to see the result.
This sequence is followed by a call to gdi_InvalidateRegion() to mark the
rectangular area of the drawing operation.
Since in xfreerdp's current design (or better current evolved state) the
backbuffer pixmap is obligatory, all drawing operations directly targeting
the window are redundant because of the subsequent EndPaint (mapped to
xf_hw_end_paint) where the damaged region is copied from the backbuffer
to the drawable.
- removed X11 drawing operations which directly target the window drawable
- fixed some errors in the calculation of the required update regions
This commit does the following:
* fix the keyboard logic (which now fully works), add support for vertical mouse wheel events ;
* make the rendering a lot more efficient, by using RDP damage information to refresh only the relevant part of the buffer ;
* fix two race conditions. wlfreerdp should not crash anymore now ;
* fix shm_open() and shm_unlink() calls ;
* improve the code style.
Signed-off-by: Manuel Bachmann <tarnyko@tarnyko.net>
Added a condition to redraw a rect only when region is invalidated. For
example. this avoids a redraw when only the cursor changes on the
remote machine.
We split the one massive source file into multiple separate
source files and headers, just like it is done for other
clients.
We add a new "wlfInput" interface which will try to
initialize mouse and keyboard at startup. Mouse inputs
already work, keyboard inputs need further investigation.
Signed-off-by: Manuel Bachmann <tarnyko@tarnyko.net>
X11 gdi polyline has been broken by commit 3de5c62.
We don't need to convert the point coordinates if XDrawLines is called with
coordinate mode CoordModePrevious.
Also Use ANDROID_APP_TARGET_SDK for application compatibility project.
It is now automatically set/updated during build.
Note: The ANDROID_APP_TARGET_SDK version need to be larger or equal to the
version required by the used Android support library (appcompat).
Allow the user to decide if he trusts a new certificate
or not, just like we do with xfreerdp ; this allow running
wlfreerdp without using xfreerdp prior for this sole task.
Signed-off-by: Manuel Bachmann <tarnyko@tarnyko.net>
The fOpRedundant field of the GlyphIndex primary drawing order
(MS-RDPEGDI, chapter 2.2.2.2.1.1.2.13) was neglected which resulted in some
severe text rendering errors.
This commit fixes the following errors
by removing or replacing old functions:
wlfreerdp.c:(.text.startup+0xc): undefined reference to
`freerdp_channels_global_init'
wlfreerdp.c:(.text.startup+0x72): undefined reference to
`freerdp_client_parse_command_line_arguments'
wlfreerdp.c:(.text.startup+0x9b): undefined reference to
`freerdp_channels_global_uninit'
Implement an initial Wayland client, which will build if
the wayland-client development libraries are detected
(or if -DWITH_WAYLAND:BOOL=ON is set). It is currently
view-only, but inputs will be implemented soon.
It uses the software SHM interface, which means it does not
require GL acceleration to run. It should be compatible
with any compositor
Signed-off-by: Manuel Bachmann <tarnyko@tarnyko.net>
"libfreerdp" consisted of multiple (small) single libraries. If the cmake
option MONOLITHIC was used only one library was build combining all of
the libfreerdp-* libraries.
The only exceptions to this are libfreerdp-server and libfreerdp-client these
are build as separate libraries.
This commit obsoltes non-monolithic builds and makes monolithic builds
the default. The cmake option MONOLITHIC is also removed.
Conflicts:
channels/drdynvc/client/dvcman.c
include/freerdp/codec/h264.h
libfreerdp/codec/h264.c after this merge h264 doesn't work anymore!!
libfreerdp/utils/svc_plugin.c
* client/X11/xf_client.c (xf_pre_connect): Set the field `colormap' of
`struct xfContext' to the default colormap.
* client/X11/xfreerdp.h (xf_gdi_get_color): Declare new external function.
* client/X11/xf_gdi.c (xf_gdi_get_color): Define new external function.
Use xf_gdi_get_color() to get the appropriate X color index from the GDI
color representation.
* client/X11/xf_graphics.c: Likewise.
representation.
* client/X11/xf_gdi.c:
Use freerdp_color_convert_drawing_order_color_to_gdi_color() to convert
from drawing order color representation to GDI color representation
troughout.
* client/X11/xf_graphics.c: Likewise.
* Zeroing xevent helped address some erratic behavior.
* valgrind complained about using xfBitmap uninitialized
during shutdown, traced it back to the initialization.
Bitmap_Prototype->size > sizeof(rdpBitmap).
* Early exit from recv_tpkt_pdu is necessary to address
a shutdown crash - the channelId value was being used
without being set in the disconnect case.
* client/Android/FreeRDPCore/jni/android_freerdp.c:
(android_post_connect): Pass the proper flags to gdi_init().
(copy_pixel_buffer): Do not invert the framebuffer data when using 32bpp
framebuffer.
1.0 had the ability to specifiy window geometry by a percentage.
The support is still there, just needed command line support.
Example in 1.1 syntax: /size:85%
* client/Android/FreeRDPCore/jni/android_freerdp.c:
(jni_freerdp_set_performance_flags): Always pass the user specified performance
settings to FreeRDP.
