This fixes#976, fixes#974, fixes#444.
On Windows the standard stream open() functions expect bytes encoded in
current system encoding, not UTF8. Since we're dealing with UTF8
throughout the application this results in wrong paths being passed and
failure to open files. As a solution, we convert the paths to UTF16 via
the WCHAR character type and use the special Windows-specific overloads
of open() functions.
This reverts commit 402801e0a6.
We should use UTF8 throughout the application and convert to platform
encodings only at the edge. Otherwise it's not clear which data uses
which encoding and we result in extremele brittle system.
We have a check for windows here anyway, let's move the defines here and we
can drop it in the common header file. And since on Unix HAVE_CONFIG_H is
always defined, we can drop the else condition too.
The following logs are extracted from pasting texts to Firefox's address
bar and a Google Doc page in Firefox, respectively.
[2021-05-16T00:03:14] DEBUG1: request for clipboard 342, target text/plain;charset=utf-8 (600) by 0x03000044 (property=GDK_SELECTION (511))
[2021-05-16T00:03:22] DEBUG1: request for clipboard 342, target application/x-moz-nativehtml (603) by 0x03000044 (property=GDK_SELECTION (511))
Inspired by https://github.com/debauchee/barrier/pull/461. Should fix
pasting unicode on X11 https://github.com/debauchee/barrier/issues/344.
The SSL_get_client_ciphers API has been available since LibreSSL 2.9.1
and is thus present in all supported versions (3.2.x and 3.3.x). In
the upcoming LibreSSL 3.4.x release the SSL_CIPHER struct will become
opaque hence the build will break.
The non-ASCII symbols missing in CP_THREAD_ACP but present in current KB
layout were processed incorrectly. Do not rely on ANSI => UTF16
conversion, obtain UTF16 directly from KB layout driver. BTW, ToAscii is
implemented via ToUnicode + RtlUnicodeToMultiByteN, so this is really
optimization.
cmake sets HAVE_DPMS_PROTOTYPES unconditionally to 1 if we have the dpms
headers. So code inside HAVE_X11_EXTENSIONS_DPMS_H never needs to check for
it.
And since there's only one place that cared for this, we can remove the define
in cmake as well.
Many tools strip trailing whitespaces by default, so after editing a file with
whitespace errors we end up with a bunch of unrelated hunks that need to be
reverted locally.
This could be fixed by configuring each tool to not do this (at least for the
barrier repo), or, simpler, we just sed the problem away and make barrier
whitespace-compliant.
sed commands run:
sed -i 's/[ \t]\+$//' **/*.(cpp|h) **/*CMakeLists.txt
Verified with git diff --ignore-space-change, this shows the empty diff.
I've tested this with a german Apple Magic Keyboard with Numeric Keypad (Space Gray)
connected to a non-Apple Linux Laptop running Arch Linux.
keycode 237 (keysym 0x1008ff06, XF86KbdBrightnessDown)
keycode 238 (keysym 0x1008ff05, XF86KbdBrightnessUp)
When disconnected a NOTE log entry is made in the log, when connected it just prints which seems inconsistent to me:
```
[2020-06-01T11:50:55] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
/home/jonathan/barrier/src/lib/net/SecureSocket.cpp,872
connected to server
[2020-06-01T11:52:43] INFO: entering screen
```
vs.
```
[2020-06-01T11:59:01] NOTE: disconnected from server
/home/jonathan/barrier/src/lib/barrier/ClientApp.cpp,315
```
Since everything else logs with a timestamp I suggest changing this to NOTE as well for connection events being logged.
Fixes high cpu usage spikes on win10.
When queue was containing messages of only non-QS_POSTMESSAGE type the
"while (m_buffer->isEmpty())" busy-looped in EventQueue::getEvent
since isEmpty was true (checked only QS_POSTMESSAGE message type),
but waitForEvent returned immediately (checked more message types).
Investigation shows that the difference was introduced in
https://github.com/debauchee/barrier/commit/dbfb04a6e
to fix a problem with bad behaviour of GetQueueStatus
Researching showed that a similar problem was fixed in Qt,
and the solution was
"pass different flags to GetQueueStatus depending on version of windows"
https://bugreports.qt.io/browse/QTBUG-29097
So this patch makes changes to a barrier non-GUI core similar to Qt fix.
QLength() may return 0 even if there are events pending because they
need to be read from the display socket in order to become visible. We
must use XPending() which will poll the socket if QLength() == 0.
Current code base don't use IEventQueue::isEmpty() method.
Remove it to simplify IEventQueue API and to remove confusion with
IEventQueueBuffer with same name.
The IEventQueueBuffer::isEmpty() and all its implementations kept unchanged
This changes the log level for several statuses (started server,
connected to server, server status:) from CLOG_NOTE or CLOG_INFO to
CLOG_PRINT so they will be printed to stdout regardless of the log
level. This allows the GUI to accurately report the status of the
`barriers` or `barrierc` processes in src/gui/src/MainWindow.cpp#L379-L399.
Errors where the socket address is in use will keep the server from connecting
with clients. This should be reported as an ERROR instead of a warning. Also,
if the retry time is shorter issues will be more obvious, since the error will
cause the log to scroll visibly.
Sometimes -lpthread is not enough. This has caused build failures on
Gentoo Linux in the past.
The logic also seems needlessly complex. We check for HAVE_PTHREAD on
UNIX platforms even though CMake errors out if pthreads are not
found. Similarly, we have a fallback for HAVE_PTHREAD_SIGNAL being
false even though we always set it to true.
The commit a841b28 changed the condition for removing job from processing.
New flag MultiplexerJobStatus::continue_servicing become used
instead of checking pointer for NULL.
However for cases when TCPSocket::newJob() returns nullptr
the behaviour changed: earlier the job was removed, but after change
it is called again, since MultiplexerJobStatus equal to {true, nullptr}
means "run this job again".
This leads to problem with eating CPU and RAM on linux
https://github.com/debauchee/barrier/issues/470
There is similar windows problem, but not sure it is related.
https://github.com/debauchee/barrier/issues/552
Since it looks that the goal of a841b28 was only clarifying
object ownership and not changing job deletion behaviour,
this commit tries to get original behaviour and fix the bugs above
by returning {false, nullptr} instead of {true, nullptr}
when TCPSocket::newJob() returns nullptr.
Member initializers are always run in the order defined in the header.
This commit reorders them in the implementation so that their order
reflects their execution order.
Povilas Kanapickas
a1346054
Peter Hutterer
Tomoya Tanjo
Chih-Hsuan Yen
Theo Buehler
Felix Schmidt
Eugene Golushkov
albertony
Balint Reczey
James Le Cuirot
Michael Zimmermann
Chris Simons
GeorgH93
zhexiwang
Jonathan Martens
Dom Rodriguez
Vasily Galkin
Keegan Quinn
Daniel Seither
Casey Barton
Adrian Lucrèce Céleste