xf_cliprdr_send_data_response() is consistently called with NULL
data pointer as a way to report errors, but it was not setting
the msgFlags field accordingly.
Sometimes Windows sends strings with excess null terminating bytes.
For example, when one copies digits from calc.exe. At the same time,
some local applications freak out when they encounter null bytes
(at least LibreOffice is known to be replacing them with '#').
According to the specification of UTF8_STRING format [1], the string
data must not contain any trailing null bytes. So they all should be
trimmed, not only the last one.
Also, if the trailing null byte is not present, the length should not
be adjusted. For example, Firefox is actually sending "HTML Format"
without a null byte while Internet Explorer adds one. The spec for
text/html format [2] says nothing about the teminating null byte, so
we are free to remove it, but at least we should not mistakingly
delete '>' character of "</html>" tag when it is the last character.
[1] http://www.pps.univ-paris-diderot.fr/~jch/software/UTF8_STRING/UTF8_STRING.text
[2] https://www.ietf.org/rfc/rfc2854.txt
Clipboard formats are identified by numerical IDs and literal names.
We can keep using arbitrary defined IDs for local clipboard formats
as we are sure that they have some fixed meaning, but the server can
and will be using its own IDs, which can be different from ours for
the named formats.
Therefore:
1) A correct way to compare a local format to a remote one is
to check the names first, and only then compare their IDs.
(Extra care should be taken to support short format names.)
2) Server IDs cannot be used with wClipboard directly when dealing
with named formats. Format name should be used to extract correct
local ID for the use with Clipboard{Set,Get}Data().
Also, I find the notion of 'alternate' format IDs to be confusing.
We either deal with a fixed ID format (declared in <winpr/user.h>),
or a format that was given an arbitrary fixed ID for local use
(defined in <freerdp/channels/cliprdr.h>), or a remote format
identified by a pair of an ID and a name. Format IDs can be local
and remote, but there are no 'alternates'.
So now:
1) A new function xf_cliprdr_formats_equal() is used to compare
formats correctly in xf_cliprdr_get_server_format_by_atom()
when searching for a server format corresponding to a local
one, and in xf_cliprdr_server_format_list() when constructing
a local TARGETS list from the server format list.
2) Correct local format IDs are used with wClipboard conversions
by xf_cliprdr_process_requested_data() and
xf_cliprdr_server_format_data_response().
3) We refer to formatId and formatName when doing requests,
and srcFormatId and dstFormatId when doing conversions,
instead of using formatId and altFormatId for both purposes.
4) Server format ID and name are used to identify cached clipboard
contents. The name is compared directly as a pointer because it
will be a pointer from the same clipboard->serverFormats array.
Also, the clipboard contents are invalidated when format list
arrives, so xf_cliprdr_server_format_list() now also clears
the format ID and name together with the data.
The functions now have appropriate names which tell what exactly
they are searching for:
xf_cliprdr_get_client_format_by_id()
Get a client-provided format by client-side ID.
xf_cliprdr_get_client_format_by_atom()
Get a client-provided format by client-side format name.
xf_cliprdr_get_server_format_by_atom()
Get a corresponding server format by client-side format name.
The return types of functions have been adjusted accordingly and
correct formats are now used everywhere without mixing them up:
client-side formats are used for client -> server data flow,
while server-side ones are used for server -> client tranfers.
This resolves the issue #1414 as, for some reason, xfreerdp required
server format list to be present to be able to provide its own client
formats. Actually, we need only client format list to provide these.
Also, CF_RAW special case is handled in a more elegant way: it is
assumed to be present in every server format list (which is true).
Don't set the identifier to "winpr" as default value because journald
will use the programs name as default if no identifier is set.
This way a program using WLog doesn't need to set an identifier (except
it want something different then it's name).
This patch is needed when wanting to install binaries/libraries to other
locations than data. The linux distro Exherbo installs binaries and
libraries to /usr/<chost>/bin, /usr/<chost>/lib respectively but
manpages should still go in /usr/share/man/ because they are
architecture independent, without this patch they go in
/usr/<chost>/share/man unconditionally.
cmake documentation states:
DATAROOTDIR - read-only architecture-independent data root (share)
So this patch makes it use that so that its configurable.
* only expose necessary functions and types in header
* don't expose appender internals
* add generic function WLog_ConfigureAppender to have the possibility
to configure appender specific settings
* detect appender availability if WLog_SetLogAppenderType or
WLog_Appender_New return FALSE or NULL respectively the appender isn't
available or the initialization failed. This is very useful for the
use with optional appenders.
* add Free to the appender interface. At the time of the Free the
appender is known and available so it can be called directly (instead
of calling the right function according to the type)
* make all appender internal function static
* all appenders return the generic wLogAppender type now. Typecasts
are internally done where necessary this abstracts the appenders more
cleanly
build-config.h should contain configure/compile time settings that are
relevant for projects that use FreeRDP.
For example the compiled in plugin search paths.
This appender allows to receive the logs over a network connection using UDP packets.
You can see the logs using a listening netcat, for example: nc -ul 127.0.0.1 20000.
- fixed wrong calculation of xfc->fullscreenMonitors.[right|bottom]
- only use _NET_WM_FULLSCREEN_MONITORS if at least 2 monitors are involved
- call XMoveWindow before setting the _NET_WM_STATE_FULLSCREEN property
