...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 changes Mumble on Windows to run a helper process,
mumble_ol.exe, instead of loading mumble_ol.dll itself.
Prior to this change, Mumble would load mumble_ol.dll and
call PrepareD3D9() and PrepareDXGI() to set up the overlay.
Then, if the overlay was enabled, it would call InstallHooks()
to enable automatic injection of the overlay into new processes.
Similarly, it would call RemoveHooks() to disable automatic
overlay injection when the overlay was disabled in Mmuble.
With this change, Mumble instead runs a helper process called
mumble_ol.exe. This process sets up the overlay (equivalent
to calling PrepareD3D9(), PrepareDXGI() and calling InstallHooks()).
While running, it'll automatically inject the overlay into new
processes, just like Mumble itself did previously. On normal exit,
the helper process calls RemoveHooks() to ensure automatic overlay
injection is disabled.
To enable the overlay, Mumble starts the helper process.
To disable the overlay, Mumble terminates the helper process.
If the helper process dies when it is supposed to be running,
Mumble restarts it to ensure that overlay injection keeps
working as intended.
This change is the first part of enabling both an x86 and an x64
overlay to be active in Mumble at the same time. Since we cannot
load a 32-bit DLL into a 64-bit process (or vice versa), we need
a helper process for each architecture to reach our goal.
Note however that this commit in itself does not make it possible
for Mumble to run both an x86 and an x64 overlay at the same time.
This will come later.
This commit adds MinHook as a 3rd party
dependency and adds an alternative HardHook
implementation that makes use of MinHook.
This new MinHook-based HardHook implementation
allows us to provide an overlay for Mumble on
Windows x64.
The x64 overlay hasn't seen much testing in
real-world x64 games, except some minor testing
for World of Warcraft running in x64 mode, where
it works just fine.
There seems to be a compatibility with the Uplay
overlay, which causes Far Cry 4 to crash at the
"Press any key to continue" screen that is shown
just after launching the game. However,
Assassin's Creed: Unity works fine, so it might
just be a Far Cry 4 issue.
The x64 overlay also seems to interoperate with
the Steam overlay just fine.
I think this is a good starting point for the
feature. Let us get it into snapshots and let
us try to squash any addition bugs we find.
