removed no more actually used count property of BITMAP_UPDATE struct,
fixed allocating twice as memory for its rectangles - as of refactoring
at e5767f07 BITMAP_UPDATE struct is reused no more
Add support for new graphics redirection protocol (aka VAIL) used by
WSLg. This protocol is currently being documented and the official
documentation will be posted in the near future.
When uploading large ICON (96x96), we end up growing the stream
mid-update. Stream_EnsureCapacity end up reallocating the stream
with a larger capacity to accomodate the large ICON size, but in
doing so, also updating the sealed length for the data currently in
the stream. This breaks the assumption between update_begin_paint
and update_end_paint where the sealed lenght is used to keep track
of the location where we need to update the orders counts after
we're done accumulating update. As a result of the growth and lost
of that location, the number of orders is written to the wrong
location and the resulting stream is invalid which result in a
protocol violation and a connection drop.
The current fix uses a new offsetOrder in the update object to
keep track of where update_end_paint needs to write the number
of orders contained. I think a better fix would be for
Stream_EnsureCapacity to preserve the sealead length of the
stream on growth, but this has a much more significant impact and
careful analysis needs to be done to ensure this doesn't violate
other assumption. Need to follow up with FreeRDP developer to get
their take on this one.
* All channels inheriting from RDPDR_DRIVE base struct
* Add functions to create/free a new device of a type
* Fixed settings array resize code, prevent 0 sizes
The proxy server component might receive input related events
before the proxy client has established the connection to the
target machine.
With this change, the current keyboard state is cached and sent
to the target when it is ready. All input events received before
the target is ready are discarded.
* Added transport_get_context to get rdpContext in IO callbacks.
* Added WINPR_ASSERT where possible.
* Fixed handle count mismatch in transport_get_event_handles
* Split out proxy headers and moved to public API to allow external
modules to be built.
* Split proxy into proxy library and proxy binary. The library
can be used by other applications and provides a simple API
* Improved channel passthrough, now all channels including dynamic
channels work.
* Extended module API to hook more events, improved module samples
* Cleaned up proxy code, removed global static variables used,
added WINPR_ASSERT
* Added transport_get_context to get rdpContext in IO callbacks.
* Added WINPR_ASSERT where possible.
* Fixed handle count mismatch in transport_get_event_handles
RDPSND channel is special, as it has many names.
(e.g. static channel, dynamic channel and UDP one.
Use RDPSND_CHANNEL_NAME to identify the module name instad of
RDPSND_DVC_CHANNEL_NAME
* Use freerdp_settings_* for shadow and sample server
* Added freerdp_peer_set_local_and_hostname
* Code cleanups and WINPR_ASSERT
* Code cleanups
* Use CHANNEL_NAME_LEN where appropriate
* Use temporary variables in loop instead of direct array access
* Fixed research for native PCM format
* Fixed compatibility detection for resampling
* dsp: Makes channel mix and encoding process use separated buffers
* Give FramesPerPacket to freerdp_dsp_context_reset function
* dsp: Fix DVI_ADPCM codec by respecting the required packet size
* Forbid mono channel in macos
* Fix audin command line channel option
* Disable ADPCM codec as it does not work
* Refactor valid native codec research
* Native codec research: Try different channels number
* Fix dsp channel mix
* Fix dsp resample
* Added new function pointers to cancel a pending operation
* Added new function pointers to send custom event flags
* Added exposed feature mask to disable channel features
(some client side channels and all server side channels still need to be
ported to new api)
server: build fix, do not disable threads for rfx encoder
cliprdr client channel: implemented support for DisableThreads option
looks like thread does not make sense at all for this channel
do not initialize disabled image codecs (respect settings)
channels: client: rail: added support for DisableThreads setting
changed "BOOL DisableThreads" to "UINT32 ThreadingFlags"
dropped unnecessary apu changes
draft implementation of threading settings aware message handling api
for addins/channels
rail: use new messaging api
fixed memory leak
msgs handlers external api changes (as requested)
msgs_handlers: init fix
fixed memory leak
logic fix
resolved problems appeared after rebase to master, dropped unnecessary
changes
git clang-format origin/master
fixed TestFreeRDPCodecRemoteFX.c
"formatting, run `clang-format` please"
properly use new "rfx_context_new(BOOL, UINT32)" everywhere
passed Threading Flags to "rfx_context_new" where available
in older C standarts veriables declaration must be done before any code
requested changes
clang-format as requested
use broken signatures of standert C functions for m$ s**tos
clang-format
requested changes
requested changes
moved ThreadingFlags to stable api zone
define type for channel msg handler
typo fix
clang-format
build fix
us ThreadingFlags from server settings
git clang-format origin/master
clang-format
Removes the changes to connection type in gcc_write_client_core_data and
adds some checks if network detection is enabled when receiving network
detection requests.
I personally find it more convenient to have pasted data written to
the X11 PRIMARY selection, so that I can paste it with a fast middle-
button click, than to write to CLIPBOARD which typically needs a key
sequence or menu action.
This commit adds a command-line option to let me express that
preference: now I can say "/clipboard:use-selection:PRIMARY" on the
command line, which not only enables clipboard transfer but also says
which X selection I want it to talk to. The previous options
"+clipboard" and "-clipboard" are also still supported.
This PR gets rid of some unneeded/unused field and functions in the
channel handling code. It also makes it possible to call
VirtualChannelWrite from any thread like the Windows API allows. The
only restriction is that the channel must be initialized
(VirtualChannelInit) from the same thread that called freerdp_connect.
* Pass on proper command type to application
* On send let the server implementation decide to send
2.2.9.2.1 Set Surface Bits Command (TS_SURFCMD_SET_SURF_BITS) or
2.2.9.2.2 Stream Surface Bits Command (TS_SURFCMD_STREAM_SURF_BITS)
Thanks to @viniciusjarina for tracing the issue down.
Armin Novak