2017-11-10 17:56:13 +00:00
|
|
|
// Copyright 2017 Dolphin Emulator Project
|
2021-07-05 01:22:19 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2017-11-10 17:56:13 +00:00
|
|
|
|
|
|
|
#include "InputCommon/ControllerInterface/Win32/Win32.h"
|
|
|
|
|
2017-11-10 20:30:37 +00:00
|
|
|
#include <windows.h>
|
|
|
|
|
2019-03-31 12:46:58 +00:00
|
|
|
#include <array>
|
|
|
|
#include <future>
|
InputCommon: fix default input config default device not being loaded/found
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
2021-11-27 12:31:04 +00:00
|
|
|
#include <mutex>
|
2017-11-10 20:30:37 +00:00
|
|
|
#include <thread>
|
|
|
|
|
2021-05-15 09:20:20 +00:00
|
|
|
#include "Common/Flag.h"
|
2021-12-12 21:50:18 +00:00
|
|
|
#include "Common/HRWrap.h"
|
2017-11-10 20:30:37 +00:00
|
|
|
#include "Common/Logging/Log.h"
|
|
|
|
#include "Common/ScopeGuard.h"
|
2020-08-22 09:55:31 +00:00
|
|
|
#include "Common/Thread.h"
|
2017-11-10 17:56:13 +00:00
|
|
|
#include "InputCommon/ControllerInterface/DInput/DInput.h"
|
|
|
|
#include "InputCommon/ControllerInterface/XInput/XInput.h"
|
|
|
|
|
2017-11-10 20:30:37 +00:00
|
|
|
constexpr UINT WM_DOLPHIN_STOP = WM_USER;
|
|
|
|
|
2021-05-15 09:20:20 +00:00
|
|
|
// Dolphin's render window
|
|
|
|
static HWND s_hwnd;
|
|
|
|
// Windows messaging window (hidden)
|
2017-11-10 20:30:37 +00:00
|
|
|
static HWND s_message_window;
|
|
|
|
static std::thread s_thread;
|
InputCommon: fix default input config default device not being loaded/found
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
2021-11-27 12:31:04 +00:00
|
|
|
static std::mutex s_populate_mutex;
|
2021-05-15 09:20:20 +00:00
|
|
|
static Common::Flag s_first_populate_devices_asked;
|
2017-11-10 20:30:37 +00:00
|
|
|
|
|
|
|
static LRESULT CALLBACK WindowProc(HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam)
|
|
|
|
{
|
|
|
|
if (message == WM_INPUT_DEVICE_CHANGE)
|
|
|
|
{
|
2021-05-15 09:20:20 +00:00
|
|
|
// Windows automatically sends this message before we ask for it and before we are "ready" to
|
|
|
|
// listen for it.
|
|
|
|
if (s_first_populate_devices_asked.IsSet())
|
|
|
|
{
|
InputCommon: fix default input config default device not being loaded/found
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
2021-11-27 12:31:04 +00:00
|
|
|
std::lock_guard lk_population(s_populate_mutex);
|
2021-05-15 09:20:20 +00:00
|
|
|
// TODO: we could easily use the message passed alongside this event, which tells
|
|
|
|
// whether a device was added or removed, to avoid removing old, still connected, devices
|
|
|
|
g_controller_interface.PlatformPopulateDevices([] {
|
|
|
|
ciface::DInput::PopulateDevices(s_hwnd);
|
|
|
|
ciface::XInput::PopulateDevices();
|
|
|
|
});
|
|
|
|
}
|
2017-11-10 20:30:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return DefWindowProc(hwnd, message, wparam, lparam);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ciface::Win32::Init(void* hwnd)
|
2017-11-10 17:56:13 +00:00
|
|
|
{
|
2017-11-10 20:30:37 +00:00
|
|
|
s_hwnd = static_cast<HWND>(hwnd);
|
2017-11-10 17:56:13 +00:00
|
|
|
XInput::Init();
|
2017-11-10 20:30:37 +00:00
|
|
|
|
2019-03-31 12:46:58 +00:00
|
|
|
std::promise<HWND> message_window_promise;
|
|
|
|
|
|
|
|
s_thread = std::thread([&message_window_promise] {
|
2020-08-22 09:55:31 +00:00
|
|
|
Common::SetCurrentThreadName("ciface::Win32 Message Loop");
|
|
|
|
|
2019-03-31 12:46:58 +00:00
|
|
|
HWND message_window = nullptr;
|
|
|
|
Common::ScopeGuard promise_guard([&] { message_window_promise.set_value(message_window); });
|
|
|
|
|
2021-12-12 21:50:18 +00:00
|
|
|
HRESULT hr = CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED);
|
|
|
|
if (FAILED(hr))
|
2017-11-10 20:30:37 +00:00
|
|
|
{
|
2021-12-12 21:50:18 +00:00
|
|
|
ERROR_LOG_FMT(CONTROLLERINTERFACE, "CoInitializeEx failed: {}", Common::HRWrap(hr));
|
2017-11-10 20:30:37 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
Common::ScopeGuard uninit([] { CoUninitialize(); });
|
|
|
|
|
|
|
|
WNDCLASSEX window_class_info{};
|
|
|
|
window_class_info.cbSize = sizeof(window_class_info);
|
|
|
|
window_class_info.lpfnWndProc = WindowProc;
|
|
|
|
window_class_info.hInstance = GetModuleHandle(nullptr);
|
|
|
|
window_class_info.lpszClassName = L"Message";
|
|
|
|
|
|
|
|
ATOM window_class = RegisterClassEx(&window_class_info);
|
|
|
|
if (!window_class)
|
|
|
|
{
|
2021-12-12 21:50:18 +00:00
|
|
|
NOTICE_LOG_FMT(CONTROLLERINTERFACE, "RegisterClassEx failed: {}",
|
|
|
|
Common::HRWrap(GetLastError()));
|
2017-11-10 20:30:37 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
Common::ScopeGuard unregister([&window_class] {
|
|
|
|
if (!UnregisterClass(MAKEINTATOM(window_class), GetModuleHandle(nullptr)))
|
2021-12-12 21:50:18 +00:00
|
|
|
ERROR_LOG_FMT(CONTROLLERINTERFACE, "UnregisterClass failed: {}",
|
|
|
|
Common::HRWrap(GetLastError()));
|
2017-11-10 20:30:37 +00:00
|
|
|
});
|
|
|
|
|
2019-03-31 12:46:58 +00:00
|
|
|
message_window = CreateWindowEx(0, L"Message", nullptr, 0, 0, 0, 0, 0, HWND_MESSAGE, nullptr,
|
|
|
|
nullptr, nullptr);
|
|
|
|
promise_guard.Exit();
|
|
|
|
if (!message_window)
|
2017-11-10 20:30:37 +00:00
|
|
|
{
|
2021-12-12 21:50:18 +00:00
|
|
|
ERROR_LOG_FMT(CONTROLLERINTERFACE, "CreateWindowEx failed: {}",
|
|
|
|
Common::HRWrap(GetLastError()));
|
2017-11-10 20:30:37 +00:00
|
|
|
return;
|
|
|
|
}
|
2019-03-31 12:46:58 +00:00
|
|
|
Common::ScopeGuard destroy([&] {
|
|
|
|
if (!DestroyWindow(message_window))
|
2021-12-12 21:50:18 +00:00
|
|
|
ERROR_LOG_FMT(CONTROLLERINTERFACE, "DestroyWindow failed: {}",
|
|
|
|
Common::HRWrap(GetLastError()));
|
2017-11-10 20:30:37 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
std::array<RAWINPUTDEVICE, 2> devices;
|
|
|
|
// game pad devices
|
|
|
|
devices[0].usUsagePage = 0x01;
|
|
|
|
devices[0].usUsage = 0x05;
|
|
|
|
devices[0].dwFlags = RIDEV_DEVNOTIFY;
|
2019-03-31 12:46:58 +00:00
|
|
|
devices[0].hwndTarget = message_window;
|
2017-11-10 20:30:37 +00:00
|
|
|
// joystick devices
|
|
|
|
devices[1].usUsagePage = 0x01;
|
|
|
|
devices[1].usUsage = 0x04;
|
|
|
|
devices[1].dwFlags = RIDEV_DEVNOTIFY;
|
2019-03-31 12:46:58 +00:00
|
|
|
devices[1].hwndTarget = message_window;
|
2017-11-10 20:30:37 +00:00
|
|
|
|
|
|
|
if (!RegisterRawInputDevices(devices.data(), static_cast<UINT>(devices.size()),
|
|
|
|
static_cast<UINT>(sizeof(decltype(devices)::value_type))))
|
|
|
|
{
|
2021-05-04 20:37:06 +00:00
|
|
|
ERROR_LOG_FMT(CONTROLLERINTERFACE, "RegisterRawInputDevices failed: {}", GetLastError());
|
2017-11-10 20:30:37 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
MSG msg;
|
|
|
|
while (GetMessage(&msg, nullptr, 0, 0) > 0)
|
|
|
|
{
|
|
|
|
TranslateMessage(&msg);
|
|
|
|
DispatchMessage(&msg);
|
|
|
|
if (msg.message == WM_DOLPHIN_STOP)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
});
|
2019-03-31 12:46:58 +00:00
|
|
|
|
|
|
|
s_message_window = message_window_promise.get_future().get();
|
2017-11-10 17:56:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void ciface::Win32::PopulateDevices(void* hwnd)
|
|
|
|
{
|
2017-11-10 20:30:37 +00:00
|
|
|
if (s_thread.joinable())
|
|
|
|
{
|
|
|
|
s_hwnd = static_cast<HWND>(hwnd);
|
InputCommon: fix default input config default device not being loaded/found
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
2021-11-27 12:31:04 +00:00
|
|
|
// To avoid blocking this thread until the async population has finished, directly do it here
|
|
|
|
// (we need the DInput Keyboard and Mouse "default" device to always be added without any wait).
|
|
|
|
std::lock_guard lk_population(s_populate_mutex);
|
2021-05-15 09:20:20 +00:00
|
|
|
s_first_populate_devices_asked.Set();
|
InputCommon: fix default input config default device not being loaded/found
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
2021-11-27 12:31:04 +00:00
|
|
|
ciface::DInput::PopulateDevices(s_hwnd);
|
|
|
|
ciface::XInput::PopulateDevices();
|
2017-11-10 20:30:37 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-05-04 20:37:06 +00:00
|
|
|
ERROR_LOG_FMT(CONTROLLERINTERFACE,
|
2020-10-22 21:49:29 +00:00
|
|
|
"win32 asked to populate devices, but device thread isn't running");
|
2017-11-10 20:30:37 +00:00
|
|
|
}
|
2017-11-10 17:56:13 +00:00
|
|
|
}
|
|
|
|
|
2021-05-15 09:20:20 +00:00
|
|
|
void ciface::Win32::ChangeWindow(void* hwnd)
|
|
|
|
{
|
|
|
|
if (s_thread.joinable()) // "Has init?"
|
|
|
|
{
|
|
|
|
s_hwnd = static_cast<HWND>(hwnd);
|
InputCommon: fix default input config default device not being loaded/found
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
2021-11-27 12:31:04 +00:00
|
|
|
std::lock_guard lk_population(s_populate_mutex);
|
2021-05-15 09:20:20 +00:00
|
|
|
ciface::DInput::ChangeWindow(s_hwnd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-10 17:56:13 +00:00
|
|
|
void ciface::Win32::DeInit()
|
|
|
|
{
|
2021-05-04 20:37:06 +00:00
|
|
|
NOTICE_LOG_FMT(CONTROLLERINTERFACE, "win32 DeInit");
|
2017-11-10 20:30:37 +00:00
|
|
|
if (s_thread.joinable())
|
|
|
|
{
|
|
|
|
PostMessage(s_message_window, WM_DOLPHIN_STOP, 0, 0);
|
|
|
|
s_thread.join();
|
2019-03-31 12:46:58 +00:00
|
|
|
s_message_window = nullptr;
|
2021-05-15 09:20:20 +00:00
|
|
|
s_first_populate_devices_asked.Clear();
|
|
|
|
DInput::DeInit();
|
2017-11-10 20:30:37 +00:00
|
|
|
}
|
2021-05-15 09:20:20 +00:00
|
|
|
s_hwnd = nullptr;
|
2017-11-10 20:30:37 +00:00
|
|
|
|
2017-11-10 17:56:13 +00:00
|
|
|
XInput::DeInit();
|
|
|
|
}
|