We need this in case there's a bug in one of the overlay helpers.
Without this, we would restart a crashed helper immediately. If this
bug is triggered every time the helper is run, we'd get into an infinite
restart loop, potentially making the host computer unresponsive.
OverlayPrivateWin used to only listen for process
termination. Technically, this should work just fine.
This change makes OverlayPrivateWin listen for process
errors as well, by subscribing to the error() signal
of the QProcess of each of our helpers.
The idea is that this could provide us helpful error
messages when troubleshooting issues where overlay
helpers are exiting untimely.
When Qt terminates a QProcess via the terminate()
method, it sends a WM_CLOSE message.
However, the overlay helper did not know of WM_CLOSE,
so it would quietly ignore it.
This commit teaches the overlay helper to exit on
WM_CLOSE.
This change adds a function, canRun64BitPrograms() to OverlayWinPrivate.
If the program is built for x64, the function unconditionally
returns true.
If the program is built for x86, the function uses a call to the
runtime-resolved kernel32!IsWow64Process to determine whether or
not the system is x64 capable.
This functionality is needed to avoid spawning the x64 helper in
case the system cannot support it. Doing so without care, like we
did previously, could be fatal because Mumble immediately restarts
the helper process if it terminates. This would presumably make the
host computer unusable.
Vtable offsetes is almost all that we store in the shared memory,
and they vary by architecture.
So, don't share the memory between arches. Instead, crate
arch-specific shared memory regions.
This splits fx11 into an x86 variant and an x64 variant.
This creates effects11_x86.lib and effects11_x64.lib, instead
of the single effects11.lib we had previously.
The minhook build is also tweaked. However, since minhook
is only used on x86_64, it is only built for x86_64.
Consequently, the library is still called minhook.lib.
The overlay itself is split into mumble_ol.dll and mumble_ol.exe
for x86, and mumble_ol_x64.dll and mumble_ol_x64.exe for x86_64.
These CONFIG options allow a .pro file to select which toolchain
its target should be built with.
To force a target to always be built for x86 (in both x86 and
x86_64 build environments), set CONFIG+=force-x86-toolchain.
The same thing is possible with force-x86_64-toolchain.
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')
