2013-07-09 22:49:58 -08:00
|
|
|
// Copyright 2013 Max Eliaser
|
2021-07-05 03:22:19 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2013-07-09 22:49:58 -08:00
|
|
|
|
2021-12-09 18:22:16 -08:00
|
|
|
#include "InputCommon/ControllerInterface/Xlib/XInput2.h"
|
|
|
|
|
2014-02-17 05:18:15 -05:00
|
|
|
#include <X11/XKBlib.h>
|
2023-03-23 13:55:04 -05:00
|
|
|
|
2023-04-15 02:13:01 -07:00
|
|
|
#include <X11/extensions/XInput2.h>
|
2013-07-09 22:49:58 -08:00
|
|
|
#include <cmath>
|
2015-10-05 22:45:55 -05:00
|
|
|
#include <cstdlib>
|
2014-09-18 23:17:41 -05:00
|
|
|
#include <cstring>
|
2014-02-17 05:18:15 -05:00
|
|
|
|
2019-11-22 14:10:28 -05:00
|
|
|
#include <fmt/format.h>
|
|
|
|
|
2023-04-15 02:13:01 -07:00
|
|
|
#include "Common/Logging/Log.h"
|
2018-07-16 16:55:25 -04:00
|
|
|
#include "Common/StringUtil.h"
|
|
|
|
|
2022-07-15 21:48:46 +02:00
|
|
|
#include "Core/Host.h"
|
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// This is an input plugin using the XInput 2.0 extension to the X11 protocol,
|
|
|
|
// loosely based on the old XLib plugin. (Has nothing to do with the XInput
|
|
|
|
// API on Windows.)
|
|
|
|
|
|
|
|
// This plugin creates one KeyboardMouse object for each master pointer/
|
|
|
|
// keyboard pair. Each KeyboardMouse object exports four types of controls:
|
2018-07-16 16:55:25 -04:00
|
|
|
// * Mouse button controls: hardcoded at 32 of them, but could be made to
|
2013-07-09 22:49:58 -08:00
|
|
|
// support infinitely many mouse buttons in theory; XInput2 has no limit.
|
|
|
|
// * Mouse cursor controls: one for each cardinal direction. Calculated by
|
|
|
|
// comparing the absolute position of the mouse pointer on screen to the
|
|
|
|
// center of the emulator window.
|
|
|
|
// * Mouse axis controls: one for each cardinal direction. Calculated using
|
|
|
|
// a running average of relative mouse motion on each axis.
|
|
|
|
// * Key controls: these correspond to a limited subset of the keyboard
|
|
|
|
// keys.
|
|
|
|
|
|
|
|
// Mouse axis control tuning. Unlike absolute mouse position, relative mouse
|
|
|
|
// motion data needs to be tweaked and smoothed out a bit to be usable.
|
|
|
|
|
|
|
|
// Mouse axis control output is simply divided by this number. In practice,
|
|
|
|
// that just means you can use a smaller "dead zone" if you bind axis controls
|
|
|
|
// to a joystick. No real need to make this customizable.
|
2014-02-16 15:30:18 -05:00
|
|
|
#define MOUSE_AXIS_SENSITIVITY 8.0f
|
2013-07-09 22:49:58 -08:00
|
|
|
|
|
|
|
// The mouse axis controls use a weighted running average. Each frame, the new
|
|
|
|
// value is the average of the old value and the amount of relative mouse
|
|
|
|
// motion during that frame. The old value is weighted by a ratio of
|
|
|
|
// MOUSE_AXIS_SMOOTHING:1 compared to the new value. Increasing
|
|
|
|
// MOUSE_AXIS_SMOOTHING makes the controls smoother, decreasing it makes them
|
|
|
|
// more responsive. This might be useful as a user-customizable option.
|
2014-02-16 15:30:18 -05:00
|
|
|
#define MOUSE_AXIS_SMOOTHING 1.5f
|
2013-07-09 22:49:58 -08:00
|
|
|
|
2022-12-22 20:21:17 +00:00
|
|
|
// The scroll axis value should decay a lot faster than the mouse axes since
|
|
|
|
// it should ideally register each click of the scroll wheel. Decreasing this
|
|
|
|
// value makes it more likely that a scroll wheel input is registered, but less
|
|
|
|
// likely to differentiate between different inputs, while increasing it will
|
|
|
|
// more cleanly separate each scroll wheel click, but risks dropping some inputs
|
|
|
|
#define SCROLL_AXIS_DECAY 1.1f
|
|
|
|
|
2023-04-15 02:13:01 -07:00
|
|
|
namespace
|
|
|
|
{
|
|
|
|
// We need XInput 2.1 to get raw events on the root window even while another
|
|
|
|
// client has a grab. If we request 2.2 or later, the server will not generate
|
|
|
|
// emulated button presses from touch events, so we want exactly 2.1.
|
|
|
|
constexpr int XINPUT_MAJOR = 2, XINPUT_MINOR = 1;
|
|
|
|
} // namespace
|
|
|
|
|
2019-06-17 16:39:24 -04:00
|
|
|
namespace ciface::XInput2
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2024-03-11 02:20:54 -05:00
|
|
|
constexpr std::string_view SOURCE_NAME = "XInput2";
|
|
|
|
|
2024-03-11 01:42:32 -05:00
|
|
|
class InputBackend final : public ciface::InputBackend
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
using ciface::InputBackend::InputBackend;
|
|
|
|
void PopulateDevices() override;
|
2024-03-11 02:20:54 -05:00
|
|
|
void HandleWindowChange() override;
|
2024-03-11 01:42:32 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
std::unique_ptr<ciface::InputBackend> CreateInputBackend(ControllerInterface* controller_interface)
|
|
|
|
{
|
|
|
|
return std::make_unique<InputBackend>(controller_interface);
|
|
|
|
}
|
|
|
|
|
2024-03-11 02:20:54 -05:00
|
|
|
void InputBackend::HandleWindowChange()
|
|
|
|
{
|
|
|
|
GetControllerInterface().RemoveDevice(
|
|
|
|
[](const auto* dev) { return dev->GetSource() == SOURCE_NAME; }, true);
|
|
|
|
|
|
|
|
PopulateDevices();
|
|
|
|
}
|
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// This function will add zero or more KeyboardMouse objects to devices.
|
2024-03-11 01:42:32 -05:00
|
|
|
void InputBackend::PopulateDevices()
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2024-03-11 01:42:32 -05:00
|
|
|
const WindowSystemInfo wsi = GetControllerInterface().GetWindowSystemInfo();
|
|
|
|
if (wsi.type != WindowSystemType::X11)
|
|
|
|
return;
|
|
|
|
|
|
|
|
const auto hwnd = wsi.render_window;
|
|
|
|
|
2014-03-09 21:14:26 +01:00
|
|
|
Display* dpy = XOpenDisplay(nullptr);
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// xi_opcode is important; it will be used to identify XInput events by
|
|
|
|
// the polling loop in UpdateInput.
|
|
|
|
int xi_opcode, event, error;
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// verify that the XInput extension is available
|
|
|
|
if (!XQueryExtension(dpy, "XInputExtension", &xi_opcode, &event, &error))
|
2023-04-15 02:13:01 -07:00
|
|
|
{
|
|
|
|
WARN_LOG_FMT(CONTROLLERINTERFACE, "XInput extension not available (XQueryExtension)");
|
2013-07-09 22:49:58 -08:00
|
|
|
return;
|
2023-04-15 02:13:01 -07:00
|
|
|
}
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2023-04-15 02:13:01 -07:00
|
|
|
int major = XINPUT_MAJOR, minor = XINPUT_MINOR;
|
|
|
|
if (XIQueryVersion(dpy, &major, &minor) != Success || major < XINPUT_MAJOR ||
|
|
|
|
(major == XINPUT_MAJOR && minor < XINPUT_MINOR))
|
|
|
|
{
|
|
|
|
WARN_LOG_FMT(CONTROLLERINTERFACE, "XInput extension not available (XIQueryVersion)");
|
2013-07-09 22:49:58 -08:00
|
|
|
return;
|
2023-04-15 02:13:01 -07:00
|
|
|
}
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// register all master devices with Dolphin
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2014-02-16 15:30:18 -05:00
|
|
|
XIDeviceInfo* all_masters;
|
|
|
|
XIDeviceInfo* current_master;
|
2022-12-22 20:21:17 +00:00
|
|
|
double scroll_increment = 1.0f;
|
2014-02-16 15:30:18 -05:00
|
|
|
int num_masters;
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
all_masters = XIQueryDevice(dpy, XIAllMasterDevices, &num_masters);
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
for (int i = 0; i < num_masters; i++)
|
|
|
|
{
|
|
|
|
current_master = &all_masters[i];
|
2022-12-22 20:21:17 +00:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
if (current_master->use == XIMasterPointer)
|
2016-06-25 21:46:39 +02:00
|
|
|
{
|
2022-12-26 17:27:48 +00:00
|
|
|
// We need to query the master for the scroll wheel's increment, since the increment used
|
|
|
|
// varies depending on what input driver is being used. For example, xf86-libinput uses 120.0.
|
2022-12-22 20:21:17 +00:00
|
|
|
for (int j = 0; j < current_master->num_classes; j++)
|
|
|
|
{
|
|
|
|
if (current_master->classes[j]->type == XIScrollClass)
|
|
|
|
{
|
|
|
|
XIScrollClassInfo* scroll_event =
|
|
|
|
reinterpret_cast<XIScrollClassInfo*>(current_master->classes[j]);
|
|
|
|
scroll_increment = scroll_event->increment;
|
2022-12-23 22:35:09 +00:00
|
|
|
break;
|
2022-12-22 20:21:17 +00:00
|
|
|
}
|
|
|
|
}
|
2013-07-09 22:49:58 -08:00
|
|
|
// Since current_master is a master pointer, its attachment must
|
|
|
|
// be a master keyboard.
|
2024-03-11 01:42:32 -05:00
|
|
|
GetControllerInterface().AddDevice(
|
2022-12-26 17:27:48 +00:00
|
|
|
std::make_shared<KeyboardMouse>((Window)hwnd, xi_opcode, current_master->deviceid,
|
|
|
|
current_master->attachment, scroll_increment));
|
2016-06-25 21:46:39 +02:00
|
|
|
}
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
XCloseDisplay(dpy);
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
XIFreeDeviceInfo(all_masters);
|
|
|
|
}
|
|
|
|
|
2022-12-26 17:27:48 +00:00
|
|
|
KeyboardMouse::KeyboardMouse(Window window, int opcode, int pointer, int keyboard,
|
2023-02-02 15:36:15 -08:00
|
|
|
double scroll_increment_)
|
2022-12-26 17:27:48 +00:00
|
|
|
: m_window(window), xi_opcode(opcode), pointer_deviceid(pointer), keyboard_deviceid(keyboard),
|
2023-02-02 15:36:15 -08:00
|
|
|
scroll_increment(scroll_increment_)
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
|
|
|
// The cool thing about each KeyboardMouse object having its own Display
|
|
|
|
// is that each one gets its own separate copy of the X11 event stream,
|
|
|
|
// which it can individually filter to get just the events it's interested
|
|
|
|
// in. So be aware that each KeyboardMouse object actually has its own X11
|
|
|
|
// "context."
|
2014-03-09 21:14:26 +01:00
|
|
|
m_display = XOpenDisplay(nullptr);
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2023-04-15 02:13:01 -07:00
|
|
|
int major = XINPUT_MAJOR, minor = XINPUT_MINOR;
|
|
|
|
XIQueryVersion(m_display, &major, &minor);
|
|
|
|
|
2020-10-19 10:21:28 -05:00
|
|
|
// should always be 1
|
|
|
|
int unused;
|
|
|
|
XIDeviceInfo* const pointer_device = XIQueryDevice(m_display, pointer_deviceid, &unused);
|
2013-07-09 22:49:58 -08:00
|
|
|
name = std::string(pointer_device->name);
|
|
|
|
XIFreeDeviceInfo(pointer_device);
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2023-04-13 20:10:00 -07:00
|
|
|
// Tell core X functions which keyboard is "the" keyboard for this
|
|
|
|
// X connection.
|
|
|
|
XISetClientPointer(m_display, None, pointer_deviceid);
|
|
|
|
|
2020-10-19 10:21:28 -05:00
|
|
|
{
|
|
|
|
unsigned char mask_buf[(XI_LASTEVENT + 7) / 8] = {};
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
XISetMask(mask_buf, XI_RawButtonPress);
|
|
|
|
XISetMask(mask_buf, XI_RawButtonRelease);
|
2020-10-19 10:21:28 -05:00
|
|
|
XISetMask(mask_buf, XI_RawMotion);
|
|
|
|
|
|
|
|
XIEventMask mask;
|
|
|
|
mask.mask = mask_buf;
|
|
|
|
mask.mask_len = sizeof(mask_buf);
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2023-04-15 02:13:03 -07:00
|
|
|
mask.deviceid = pointer_deviceid;
|
|
|
|
XISelectEvents(m_display, DefaultRootWindow(m_display), &mask, 1);
|
2020-10-19 10:21:28 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
unsigned char mask_buf[(XI_LASTEVENT + 7) / 8] = {};
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
XISetMask(mask_buf, XI_RawKeyPress);
|
|
|
|
XISetMask(mask_buf, XI_RawKeyRelease);
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2020-10-19 10:21:28 -05:00
|
|
|
XIEventMask mask;
|
|
|
|
mask.mask = mask_buf;
|
|
|
|
mask.mask_len = sizeof(mask_buf);
|
2023-04-15 02:13:03 -07:00
|
|
|
mask.deviceid = keyboard_deviceid;
|
|
|
|
XISelectEvents(m_display, DefaultRootWindow(m_display), &mask, 1);
|
2020-10-19 10:21:28 -05:00
|
|
|
}
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// Keyboard Keys
|
2020-10-19 10:21:28 -05:00
|
|
|
int min_keycode, max_keycode;
|
|
|
|
XDisplayKeycodes(m_display, &min_keycode, &max_keycode);
|
2013-07-09 22:49:58 -08:00
|
|
|
for (int i = min_keycode; i <= max_keycode; ++i)
|
|
|
|
{
|
2020-10-19 10:21:28 -05:00
|
|
|
Key* const temp_key = new Key(m_display, i, m_state.keyboard.data());
|
2013-07-09 22:49:58 -08:00
|
|
|
if (temp_key->m_keyname.length())
|
|
|
|
AddInput(temp_key);
|
|
|
|
else
|
|
|
|
delete temp_key;
|
|
|
|
}
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2019-10-25 19:33:59 -05:00
|
|
|
// Add combined left/right modifiers with consistent naming across platforms.
|
|
|
|
AddCombinedInput("Alt", {"Alt_L", "Alt_R"});
|
|
|
|
AddCombinedInput("Shift", {"Shift_L", "Shift_R"});
|
|
|
|
AddCombinedInput("Ctrl", {"Control_L", "Control_R"});
|
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// Mouse Buttons
|
2018-07-16 16:55:25 -04:00
|
|
|
for (int i = 0; i < 32; i++)
|
2014-10-02 02:20:46 -04:00
|
|
|
AddInput(new Button(i, &m_state.buttons));
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// Mouse Cursor, X-/+ and Y-/+
|
|
|
|
for (int i = 0; i != 4; ++i)
|
2014-10-02 02:20:46 -04:00
|
|
|
AddInput(new Cursor(!!(i & 2), !!(i & 1), (i & 2) ? &m_state.cursor.y : &m_state.cursor.x));
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2022-12-23 22:35:09 +00:00
|
|
|
// Mouse Axis, X-/+, Y-/+ and Z-/+
|
|
|
|
AddInput(new Axis(0, false, &m_state.axis.x));
|
|
|
|
AddInput(new Axis(0, true, &m_state.axis.x));
|
|
|
|
AddInput(new Axis(1, false, &m_state.axis.y));
|
|
|
|
AddInput(new Axis(1, true, &m_state.axis.y));
|
|
|
|
AddInput(new Axis(2, false, &m_state.axis.z));
|
|
|
|
AddInput(new Axis(2, true, &m_state.axis.z));
|
|
|
|
|
|
|
|
// Relative Mouse, X-/+, Y-/+ and Z-/+
|
|
|
|
AddInput(new RelativeMouse(0, false, &m_state.relative_mouse.x));
|
|
|
|
AddInput(new RelativeMouse(0, true, &m_state.relative_mouse.x));
|
|
|
|
AddInput(new RelativeMouse(1, false, &m_state.relative_mouse.y));
|
|
|
|
AddInput(new RelativeMouse(1, true, &m_state.relative_mouse.y));
|
|
|
|
AddInput(new RelativeMouse(2, false, &m_state.relative_mouse.z));
|
|
|
|
AddInput(new RelativeMouse(2, true, &m_state.relative_mouse.z));
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
KeyboardMouse::~KeyboardMouse()
|
|
|
|
{
|
|
|
|
XCloseDisplay(m_display);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Update the mouse cursor controls
|
2022-07-15 21:48:46 +02:00
|
|
|
void KeyboardMouse::UpdateCursor(bool should_center_mouse)
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
|
|
|
double root_x, root_y, win_x, win_y;
|
|
|
|
Window root, child;
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2022-07-15 21:48:46 +02:00
|
|
|
XWindowAttributes win_attribs;
|
|
|
|
XGetWindowAttributes(m_display, m_window, &win_attribs);
|
|
|
|
const auto win_width = std::max(win_attribs.width, 1);
|
|
|
|
const auto win_height = std::max(win_attribs.height, 1);
|
2013-10-29 01:23:17 -04:00
|
|
|
|
2022-07-15 21:48:46 +02:00
|
|
|
{
|
|
|
|
XIButtonState button_state;
|
|
|
|
XIModifierState mods;
|
|
|
|
XIGroupState group;
|
|
|
|
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
// Get the absolute position of the mouse pointer and the button state.
|
2022-07-15 21:48:46 +02:00
|
|
|
XIQueryPointer(m_display, pointer_deviceid, m_window, &root, &child, &root_x, &root_y, &win_x,
|
|
|
|
&win_y, &button_state, &mods, &group);
|
|
|
|
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
// X buttons are 1-indexed, so to get 32 button bits we need a larger type
|
|
|
|
// for the shift.
|
|
|
|
u64 buttons_zero_indexed = 0;
|
|
|
|
std::memcpy(&buttons_zero_indexed, button_state.mask,
|
|
|
|
std::min<size_t>(button_state.mask_len, sizeof(m_state.buttons)));
|
|
|
|
m_state.buttons = buttons_zero_indexed >> 1;
|
|
|
|
|
2022-07-15 21:48:46 +02:00
|
|
|
free(button_state.mask);
|
|
|
|
}
|
2013-07-09 22:49:58 -08:00
|
|
|
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
if (should_center_mouse)
|
|
|
|
{
|
|
|
|
win_x = win_width / 2;
|
|
|
|
win_y = win_height / 2;
|
|
|
|
|
|
|
|
XIWarpPointer(m_display, pointer_deviceid, None, m_window, 0.0, 0.0, 0, 0, win_x, win_y);
|
|
|
|
|
|
|
|
g_controller_interface.SetMouseCenteringRequested(false);
|
|
|
|
}
|
|
|
|
|
2020-01-24 00:06:39 -06:00
|
|
|
const auto window_scale = g_controller_interface.GetWindowInputScale();
|
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// the mouse position as a range from -1 to 1
|
2022-07-15 21:48:46 +02:00
|
|
|
m_state.cursor.x = (win_x / win_width * 2 - 1) * window_scale.x;
|
|
|
|
m_state.cursor.y = (win_y / win_height * 2 - 1) * window_scale.y;
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
2023-05-24 22:58:30 +03:00
|
|
|
Core::DeviceRemoval KeyboardMouse::UpdateInput()
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
|
|
|
XFlush(m_display);
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// for the axis controls
|
2022-12-22 20:21:17 +00:00
|
|
|
float delta_x = 0.0f, delta_y = 0.0f, delta_z = 0.0f;
|
2013-07-09 22:49:58 -08:00
|
|
|
double delta_delta;
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
bool update_mouse = false, update_keyboard = false;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
// Iterate through the event queue, processing raw pointer motion events and
|
|
|
|
// noting whether the button or key state has changed.
|
2013-07-09 22:49:58 -08:00
|
|
|
XEvent event;
|
|
|
|
while (XPending(m_display))
|
|
|
|
{
|
|
|
|
XNextEvent(m_display, &event);
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
if (event.xcookie.type != GenericEvent)
|
|
|
|
continue;
|
|
|
|
if (event.xcookie.extension != xi_opcode)
|
|
|
|
continue;
|
|
|
|
if (!XGetEventData(m_display, &event.xcookie))
|
|
|
|
continue;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
switch (event.xcookie.evtype)
|
|
|
|
{
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
case XI_RawButtonPress:
|
|
|
|
case XI_RawButtonRelease:
|
|
|
|
update_mouse = true;
|
2013-07-09 22:49:58 -08:00
|
|
|
break;
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
case XI_RawKeyPress:
|
|
|
|
case XI_RawKeyRelease:
|
|
|
|
update_keyboard = true;
|
2013-07-09 22:49:58 -08:00
|
|
|
break;
|
|
|
|
case XI_RawMotion:
|
2022-12-26 17:27:48 +00:00
|
|
|
{
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
update_mouse = true;
|
2016-09-03 15:03:18 -07:00
|
|
|
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
XIRawEvent* raw_event = (XIRawEvent*)event.xcookie.data;
|
2022-12-26 17:27:48 +00:00
|
|
|
float values[4] = {};
|
|
|
|
size_t value_idx = 0;
|
|
|
|
|
|
|
|
// We only care about the first 4 axes, which should always be available at minimum
|
|
|
|
for (int i = 0; i < 4; ++i)
|
2022-12-22 20:21:17 +00:00
|
|
|
{
|
2022-12-26 17:27:48 +00:00
|
|
|
if (XIMaskIsSet(raw_event->valuators.mask, i))
|
|
|
|
{
|
|
|
|
values[i] = raw_event->raw_values[value_idx++];
|
|
|
|
}
|
2022-12-22 20:21:17 +00:00
|
|
|
}
|
2022-12-26 17:27:48 +00:00
|
|
|
|
|
|
|
delta_delta = values[0];
|
|
|
|
// test for inf and nan
|
|
|
|
if (delta_delta == delta_delta && 1 + delta_delta != delta_delta)
|
|
|
|
delta_x += delta_delta;
|
|
|
|
|
|
|
|
delta_delta = values[1];
|
|
|
|
// test for inf and nan
|
|
|
|
if (delta_delta == delta_delta && 1 + delta_delta != delta_delta)
|
|
|
|
delta_y += delta_delta;
|
|
|
|
|
|
|
|
// Scroll wheel input gets scaled to be similar to the mouse axes
|
|
|
|
delta_delta = values[3] * 8.0 / scroll_increment;
|
|
|
|
// test for inf and nan
|
|
|
|
if (delta_delta == delta_delta && 1 + delta_delta != delta_delta)
|
|
|
|
delta_z += delta_delta;
|
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
break;
|
2022-12-26 17:27:48 +00:00
|
|
|
}
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
XFreeEventData(m_display, &event.xcookie);
|
|
|
|
}
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2020-04-20 23:16:07 -05:00
|
|
|
m_state.relative_mouse.x = delta_x;
|
|
|
|
m_state.relative_mouse.y = delta_y;
|
2022-12-22 20:21:17 +00:00
|
|
|
m_state.relative_mouse.z = delta_z;
|
2020-04-20 23:16:07 -05:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// apply axis smoothing
|
|
|
|
m_state.axis.x *= MOUSE_AXIS_SMOOTHING;
|
|
|
|
m_state.axis.x += delta_x;
|
|
|
|
m_state.axis.x /= MOUSE_AXIS_SMOOTHING + 1.0f;
|
|
|
|
m_state.axis.y *= MOUSE_AXIS_SMOOTHING;
|
|
|
|
m_state.axis.y += delta_y;
|
|
|
|
m_state.axis.y /= MOUSE_AXIS_SMOOTHING + 1.0f;
|
2022-12-22 20:21:17 +00:00
|
|
|
m_state.axis.z += delta_z;
|
|
|
|
m_state.axis.z /= SCROLL_AXIS_DECAY;
|
2016-09-03 15:03:18 -07:00
|
|
|
|
2024-05-26 16:50:12 -07:00
|
|
|
const bool should_center_mouse = g_controller_interface.IsMouseCenteringRequested() &&
|
|
|
|
(Host_RendererHasFocus() || Host_TASInputHasFocus());
|
|
|
|
|
|
|
|
// When a TAS Input window has focus and "Enable Controller Input" is checked most types of
|
|
|
|
// input should be read normally as if the render window had focus instead. The cursor is an
|
|
|
|
// exception, as otherwise using the mouse to set any control in the TAS Input window will also
|
|
|
|
// update the Wii IR value (or any other input controlled by the cursor).
|
|
|
|
const bool should_update_mouse = update_mouse && !Host_TASInputHasFocus();
|
|
|
|
|
|
|
|
if (should_update_mouse || should_center_mouse)
|
2022-07-15 21:48:46 +02:00
|
|
|
UpdateCursor(should_center_mouse);
|
2020-10-19 10:21:28 -05:00
|
|
|
|
XInput2: Use raw events and queries for buttons and keys
In X, the ButtonPress events generated when a mouse button is pressed
have a special property: if they don't activate an existing passive
grab, the X server automatically activates the "implicit passive grab"
on behalf of the client the event is delivered to. This ensures the
ButtonRelease event is delivered to the same client even if the pointer
moves between windows, but it also causes all events from that pointer
to be delivered exclusively to that client. As a consequence of the
implicit passive grab, for each window, only one client can listen for
ButtonPress events; any further listeners would never receive the event.
XInput 1 made the implicit grab optional and explicit by allowing
clients to listen for DeviceButtonPress events without
DeviceButtonPressGrab events. XInput 2 does not have a separate grab
event class, but multiple clients can listen for XI_ButtonPress on the
same window. When a button is pressed, the X server first tries to
deliver an XI_ButtonPress event; if no clients want it, then the server
tries to deliver a DeviceButtonPress event; if no clients want it, then
the server tries to deliver a ButtonPress event. Once an event has been
delivered, event processing stops and earlier protocol levels are not
considered. The reason for this rule is not obviously documented, but
it is probably because of the implicit passive grab; a client receiving
a ButtonPress event assumes it is the only client receiving that event,
and later protocols maintain that property for backward compatibility.
Before this commit, Dolphin listened for XI_ButtonPress events on the
root window. This interferes with window managers that expect to
receive ButtonPress events on the root window, such as awesome and
Openbox. In Openbox, applications are often launched from a menu
activated by clicking on the root window, and desktops are switched by
scroll wheel input on the root window. This makes normal use of other
applications difficult when Dolphin is open (though Openbox keyboard
shortcuts still work). Conversely, Dolphin only receives XI_ButtonPress
events for clicks on the root window or window decorations (title bars),
not on Dolphin's windows' content or the render window. In window
managers that use a "virtual root window" covering the actual root
window, such as Mutter running in X, Dolphin and the window manager do
not conflict, but clicks delivered to other applications using XInput2
(for testing, try xinput --test-xi2) are not seen by Dolphin, which is
relevant when background input is enabled.
This commit changes Dolphin to listen for XI_RawButtonPress (and the raw
versions of other events); Dolphin was already listening to XI_RawMotion
for raw mouse movement. Raw events are always and exclusively delivered
to the root window and are delivered to every client listening for them,
so Dolphin will not interfere with (or be interfered with by) other
applications listening for events.
As part of being raw, button numbers and keycodes in raw events have not
had mapping applied. If a left-handed user swapped the left and right
buttons on their mouse, raw events do not reflect that. It is possible
to query the mappings for each device and apply them manually, but that
would require a fair amount of code, including listening for mapping
changes.
Instead, Dolphin now uses the events only to set a "changed" flag, then
queries the current button and key state after processing all events.
Dolphin was already querying the pointer to get its absolute position
and querying the keyboard to filter the key bitmap it created from
events; now Dolphin also uses the button state from the pointer query
and uses the keyboard query directly.
Queries have a performance cost because they are synchronous requests to
the X server (Dolphin waits for the result). Commit 2b640a4f made the
pointer query conditional on receiving a motion event to "cut down on
round trips", but commit bbb12a75 added an unconditional keyboard query,
and there have apparently been no performance complaints. This commit
queries the pointer slightly more often (on button events in addition to
motion), but only queries the keyboard after key events, so the total
rate of queries should be substantially reduced.
Fixes: https://bugs.dolphin-emu.org/issues/10668
2023-04-15 02:13:02 -07:00
|
|
|
if (update_keyboard)
|
|
|
|
XQueryKeymap(m_display, m_state.keyboard.data());
|
2023-05-24 22:58:30 +03:00
|
|
|
|
|
|
|
return Core::DeviceRemoval::Keep;
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::string KeyboardMouse::GetName() const
|
|
|
|
{
|
|
|
|
// This is the name string we got from the X server for this master
|
|
|
|
// pointer/keyboard pair.
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string KeyboardMouse::GetSource() const
|
|
|
|
{
|
2024-03-11 02:20:54 -05:00
|
|
|
return std::string(SOURCE_NAME);
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
2024-06-11 19:13:54 -05:00
|
|
|
int KeyboardMouse::GetSortPriority() const
|
|
|
|
{
|
|
|
|
return DEFAULT_DEVICE_SORT_PRIORITY;
|
|
|
|
}
|
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
KeyboardMouse::Key::Key(Display* const display, KeyCode keycode, const char* keyboard)
|
|
|
|
: m_display(display), m_keyboard(keyboard), m_keycode(keycode)
|
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
KeySym keysym = 0;
|
|
|
|
do
|
|
|
|
{
|
|
|
|
keysym = XkbKeycodeToKeysym(m_display, keycode, i, 0);
|
|
|
|
i++;
|
|
|
|
} while (keysym == NoSymbol && i < 8);
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// Convert to upper case for the keyname
|
|
|
|
if (keysym >= 97 && keysym <= 122)
|
|
|
|
keysym -= 32;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2013-07-09 22:49:58 -08:00
|
|
|
// 0x0110ffff is the top of the unicode character range according
|
|
|
|
// to keysymdef.h although it is probably more than we need.
|
|
|
|
if (keysym == NoSymbol || keysym > 0x0110ffff || XKeysymToString(keysym) == nullptr)
|
|
|
|
m_keyname = std::string();
|
|
|
|
else
|
|
|
|
m_keyname = std::string(XKeysymToString(keysym));
|
|
|
|
}
|
|
|
|
|
|
|
|
ControlState KeyboardMouse::Key::GetState() const
|
|
|
|
{
|
|
|
|
return (m_keyboard[m_keycode / 8] & (1 << (m_keycode % 8))) != 0;
|
|
|
|
}
|
|
|
|
|
2023-04-15 02:13:00 -07:00
|
|
|
KeyboardMouse::Button::Button(unsigned int index, u32* buttons) : m_buttons(buttons), m_index(index)
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2019-11-22 14:10:28 -05:00
|
|
|
name = fmt::format("Click {}", m_index + 1);
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
2013-07-20 13:39:28 -08:00
|
|
|
ControlState KeyboardMouse::Button::GetState() const
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2014-10-02 02:20:46 -04:00
|
|
|
return ((*m_buttons & (1 << m_index)) != 0);
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
2014-10-02 02:20:46 -04:00
|
|
|
KeyboardMouse::Cursor::Cursor(u8 index, bool positive, const float* cursor)
|
2013-07-20 13:39:28 -08:00
|
|
|
: m_cursor(cursor), m_index(index), m_positive(positive)
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2019-11-22 14:10:28 -05:00
|
|
|
name = fmt::format("Cursor {}{}", static_cast<char>('X' + m_index), (m_positive ? '+' : '-'));
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
2013-07-20 13:39:28 -08:00
|
|
|
ControlState KeyboardMouse::Cursor::GetState() const
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2014-10-02 02:20:46 -04:00
|
|
|
return std::max(0.0f, *m_cursor / (m_positive ? 1.0f : -1.0f));
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
2014-10-02 02:20:46 -04:00
|
|
|
KeyboardMouse::Axis::Axis(u8 index, bool positive, const float* axis)
|
2013-07-20 13:39:28 -08:00
|
|
|
: m_axis(axis), m_index(index), m_positive(positive)
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2019-11-22 14:10:28 -05:00
|
|
|
name = fmt::format("Axis {}{}", static_cast<char>('X' + m_index), (m_positive ? '+' : '-'));
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
|
|
|
|
2020-04-20 23:16:07 -05:00
|
|
|
KeyboardMouse::RelativeMouse::RelativeMouse(u8 index, bool positive, const float* axis)
|
|
|
|
: m_axis(axis), m_index(index), m_positive(positive)
|
|
|
|
{
|
|
|
|
name =
|
|
|
|
fmt::format("RelativeMouse {}{}", static_cast<char>('X' + m_index), (m_positive ? '+' : '-'));
|
|
|
|
}
|
|
|
|
|
2013-07-20 13:39:28 -08:00
|
|
|
ControlState KeyboardMouse::Axis::GetState() const
|
2013-07-09 22:49:58 -08:00
|
|
|
{
|
2014-10-02 02:20:46 -04:00
|
|
|
return std::max(0.0f, *m_axis / (m_positive ? MOUSE_AXIS_SENSITIVITY : -MOUSE_AXIS_SENSITIVITY));
|
2013-07-09 22:49:58 -08:00
|
|
|
}
|
2020-04-20 23:16:07 -05:00
|
|
|
|
|
|
|
ControlState KeyboardMouse::RelativeMouse::GetState() const
|
|
|
|
{
|
|
|
|
return std::max(0.0f, *m_axis / (m_positive ? MOUSE_AXIS_SENSITIVITY : -MOUSE_AXIS_SENSITIVITY));
|
|
|
|
}
|
2019-06-17 16:39:24 -04:00
|
|
|
} // namespace ciface::XInput2
|