This also changes the log message to be equivalent to the one used
by the transmit-switcher toolbar item.
This makes the strings more consistent. This should make both users
and translators happy.
The new 'no_include_pwd' CONFIG option introduced by
d855b67d10 showed us this bug.
Before that commit, OS X *did* include PWD in the INCLUDEPATH
by default. Because of that, the equivalent of '../speex-build'
was *already* in the INCLUDEPATH, because 'speex-build' is the
PWD of the .pro file.
Now that we explicitly require the PWD not to be included, our
own inclusion of 'speex-build' must be spelled correctly to work.
This commit fixes that.
This commit fixes an issue caused by a new behavior in Qt 5.4.1 that
causes
PWD to be included in the default INCLUDEPATH on Windows with the nmake/VS
generators.
This new behavior was implemented in the following Qt commit:
qtbase/a90bb5b89a - centralize/unify/sanitize INCLUDEPATH "enrichment")
a90bb5b89a
This is a problem because our codecs in 3rdparty use two distinct
config.h files: one for Win32, and one for everything else.
The Win32 variant lives in the Win32 subdirectory of the build root.
The build root is the directory that will be added automatically by
the new Qt behavior. Typically, the build root has a build suffix,
for example 'speex-build'.
The regular config.h - the one for everything else but Win32 - lives
in the buildroot itself.
This new Qt behavior caused the wrong config.h file to be included
on Windows. Since the build root is now in the INCLUDEPATH,
the config.h file that lives in the build root now takes precedence
over the one in the Win32 directory.
To restore the old behavior for the codec builds, we use Qt config
option called 'no_include_pwd'. That explicitly tells qmake to not
include the PWD in the INCLUDEPATH. This restores the previous
behavior on Windows.
The 'no_include_pwd' config option has been around in Qt for a while.
It was not introduced with the aforementioned change to Qt, so it
doesn't break backwards compatibility for us.
...and gate it behind the hidden 'shortuct/linux/evdev/enable'
config option.
We don't actively want people to use evdev unless
they really have to (as it requires people to change the
permissions of their keyboard device node to be quite wide-open
to be useful).
Our evdev code has also caused problems for users of
Yubikeys and other gadgets that identify themselves as
keyboards. Those problems should be a thing of the past
with this commit.
Fixes#1145
Some configurations of Qt 5.X explicitly disable deprecated
parts of the API, such as 'QSsl::TlsV1'. To allow Mumble to build
on those configurations, we have to use 'QSsl::TlsV1_0' instead,
like we did in the prior to 71e522f4c4.
This commit also fixes an issue where QSsl::SecureProtocols was only
selected on the base 5.4.0 release, and not subsequent patch releases.
We upstreamed a patch for adding the self-explanatory
QSsl::TlsV1_0OrLater, QSsl::TlsV1_1OrLater and QSsl::TlsV1_2OrLater
enums to QSsl.
Before this, we had a patch in our Qt 5.4 build (on Windows), that
changed the meaning of QSsl::TlsV1_0 to mean "TLSv1.0 or later".
However, that approach wouldn't work in the real world (some setups
require very specific TLS versions), so it was dropped in favour of
the TlsV1_0OrLater and friends.
Since our patch is in Qt 5.5, it means that we now can use
QSsl::TlsV1_0OrLater in the Mumble tree (ifdef'd to QT_VERSION
>= 0x050500), and not break anything for distros.
For Qt 5.4, we can rely on QSsl::SecureProtocols, because Qt 5.4
deprecated SSLv3. Thus, in Qt 5.4, QSsl::SecureProtocols means the
same thing as TlsV1_0OrLater means in Qt 5.5.
Why do we need TlsV1_0OrLater and friends if we have
QSsl::SecureProtocols? Because we don't have a guarantee that
QSsl::SecureProtocols will keep having TLSv1.0 as its minimum
version. The current Mumble protocol requires TLS 1.0.
If something comes up in the future that makes us abandon TLSv1.0,
we'll still handshake it. Rejection can happen at the Mumble protocol
level instead, providing a better user experience.
This removes the date and time macro to attempt to get us to
reproducible builds. While I do like the date and time included, it
doesn't really add that much value to our users.
Extracted common code for getting the mix format for an
IAudioClient and checking whether it is supported to
separate getAndCheckMixFormat function.
Added support for 16bit PCM besides 32bit IEEE float.
As described in #1589 the WASAPI backend made the invalid
assumption that a WAVEFORMATEX struct returned by GetMixFormat
can always be cast to the extended WAVEFORMATEXTENSIBLE type.
This is only true if the wFormatTag of the structure is
WAVE_FORMAT_EXTENSIBLE.
This patch tries to correct all invalid assumptions about this
in the backend by making casting to WAVEFORMATEXTENSIBLE and
access to its extended fields dependant on the correct format
tag being present. If given a pure WAVEFORMATEX structure
workarounds are applied where needed.
As before only IEEE_FLOAT sample formats are supported.
In my patch for #971 I tried to enable clipping for formats that
are not float and not vorbis (which is float by default) but checked
them like they were flags. This caused clipping to never actually
enable for formats whose submask contained at least one bit similar
to either the float or vorbis type.
This patch uses SF_FORMAT_SUBMASK and a straight comparison instead
and should fix this issue.
PulseAudio automatically creates monitors for devices.
These devices were previously explicitly excluded from the
list of input devices by Mumble. Excluding these devices
blocks people from combining multiple streams into Mumble
via PulseAudio.
One possible scenario is listed below:
Requirement:
- One wants to combine headset input and sound output
of a script into mumble.
Solution:
- With PulseAudio one creates a virtual sink. Let's
call it "vscrd1".
- The headset's input is looped to "vscrd1".
- The script's audio output is directly directed to
"vscrd1".
- Mumble is configured to use the input device
"vscrd1.monitor"
Now one can talk and send sound to Mumble at the same time.
It also helps much when using sound bots (music etc.).
This allows users to more easily issue SocketRPC
requests to a running Mumble client.
Currently, only commands for muting/deafning are
supported.
Example:
$ mumble rpc mute # Mute a running Mumble client
$ mumble rpc unmute # Unmute a running Mumble client
[...]
Supported commands are currently:
'mute' - Unmute self
'unmute' - Unmute self
'deaf' - Deafen self
'undeaf' - Undeafen self
(You can also see them via 'mumble rpc --help')
This commit removes macx/overlay and merges
the OS X overlay into the Unix overlay in
overlay_gl.
Most of the overlay logic is exactly the same,
with most of the differences being in the
initialization code and the addition of few new
messages for the interactive client-in-overlay
feature that the OS X overlay suports.
The initialization code is factored out into
init_unix.c for Unix-likes and init_mac.c
for OS X.
These init files are #included by overlay.c.
That is, they're not separate translation
units. Doing it this way cuts down on the
total LOC count and overall complexity of the
code.
The interactive overlay support is ported
directly from the OS X overlay. It's mostly
a matter of supporting a few new message types:
OVERLAY_MSGTYPE_PID and OVERLAY_MSGTYPE_INTERACTIVE.
The overlay_gl.pro file in this commit is mostly
just a combination of the .pro files of the two
overlays, with a minor difference in the CFLAGS
for the OS X overlay. In old OS X overlay, the
overlay had an ".m" file extension, signalling
that it is an Objective-C source file to the
C compiler. Since the combined overlay has a
".c" extension, "-x objective-c" is added to
CFLAGS on OS X to tell the compiler to compile
the overlay as Objective-C code.
Prior versions of mach_override were small (a single file),
and we just had its source live in the OS X overlay directory.
Newer versions of mach_override use libudis86, so the file count
goes up a fair bit. So much so that it doesn't make sense to
have it live inside the OS X overlay anymore.
Because of that, this commit moves it into 3rdparty.
