sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/backends/meta-input-settings.c

1867 lines
64 KiB
C
Raw Normal View History

backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/*
* Copyright 2014 Red Hat, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.
*
* Author: Carlos Garnacho <carlosg@gnome.org>
*/
/**
* SECTION:input-settings
* @title: MetaInputSettings
* @short_description: Mutter input device configuration
*/
#include "config.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include <glib/gi18n-lib.h>
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
#include <string.h>
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "backends/meta-backend-private.h"
backends: Drop internal WacomDevice in MetaInputSettings Use the one from MetaInputDevice instead. Since we no longer try to ask for WacomDevices that weren't first retrieved: Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1086 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
2020-03-06 13:53:45 +00:00
#include "backends/meta-input-device-private.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "backends/meta-input-settings-private.h"
backends: Delegate on MetaInputMapper for unmapped display devices If a display device (touchscreen, tablet with libwacom integration flags) does not receive a monitor through settings. Delegate on the MetaInputMapper so it receives a mapping through heuristics.
2018-04-20 14:49:54 +00:00
#include "backends/meta-input-mapper-private.h"
input-settings: Use logical monitors instead of outputs A MetaOutput is a connector, not exactly a monitor or a region on the stage; for example tiled monitors are split up into multiple outputs, and for what is used in input settings, that makes no sense. Change this to use logical monitors instead of outputs. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:20:14 +00:00
#include "backends/meta-logical-monitor.h"
#include "backends/meta-monitor.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "core/display-private.h"
#include "meta/util.h"
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
backends: Add function to retrieve the action mapped to an stylus button This function will be useful for the wayland implementation, because buttons are mapped at the time of sending those through the wire. As x11/wayland implementations differ here, this function will be useful for the wayland implementation, as the action is handled lat
2016-06-22 13:48:07 +00:00
static GQuark quark_tool_settings = 0;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
typedef struct _MetaInputSettingsPrivate MetaInputSettingsPrivate;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
typedef struct _DeviceMappingInfo DeviceMappingInfo;
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
typedef struct _CurrentToolInfo CurrentToolInfo;
struct _CurrentToolInfo
{
MetaInputSettings *input_settings;
ClutterInputDevice *device;
ClutterInputDeviceTool *tool;
GSettings *settings;
cleanup: Use g_clear_signal_handler() where possible This is inspired by 98892391d764d1cf where the usage of `g_signal_handler_disconnect()` without resetting the corresponding handler id later resulted in a bug. Using `g_clear_signal_handler()` makes sure we avoid similar bugs and is almost always the better alternative. We use it for new code, let's clean up the old code to also use it. A further benefit is that it can get called even if the passed id is 0, allowing us to remove a lot of now unnessecary checks, and the fact that `g_clear_signal_handler()` checks for the right type size, forcing us to clean up all places where we used `guint` instead of `gulong`. No functional changes intended here and all changes should be trivial, thus bundled in one big commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
2019-11-16 00:25:52 +00:00
gulong changed_id;
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
};
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
struct _DeviceMappingInfo
{
MetaInputSettings *input_settings;
ClutterInputDevice *device;
GSettings *settings;
cleanup: Use g_clear_signal_handler() where possible This is inspired by 98892391d764d1cf where the usage of `g_signal_handler_disconnect()` without resetting the corresponding handler id later resulted in a bug. Using `g_clear_signal_handler()` makes sure we avoid similar bugs and is almost always the better alternative. We use it for new code, let's clean up the old code to also use it. A further benefit is that it can get called even if the passed id is 0, allowing us to remove a lot of now unnessecary checks, and the fact that `g_clear_signal_handler()` checks for the right type size, forcing us to clean up all places where we used `guint` instead of `gulong`. No functional changes intended here and all changes should be trivial, thus bundled in one big commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
2019-11-16 00:25:52 +00:00
gulong changed_id;
backends: Extend pad action label checks to rings/strips This way the pad OSD can obtain the keycombos that are mapped to these for labeling purposes. https://bugzilla.gnome.org/show_bug.cgi?id=782033
2017-07-05 11:35:31 +00:00
guint *group_modes;
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
double aspect_ratio;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
};
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
struct _MetaInputSettingsPrivate
{
clutter: Move keyboard a11y from ClutterDeviceManager to ClutterSeat A11y in general may be considered a per-seat feature. https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
2019-10-01 16:45:43 +00:00
ClutterSeat *seat;
cleanup: Use g_clear_signal_handler() where possible This is inspired by 98892391d764d1cf where the usage of `g_signal_handler_disconnect()` without resetting the corresponding handler id later resulted in a bug. Using `g_clear_signal_handler()` makes sure we avoid similar bugs and is almost always the better alternative. We use it for new code, let's clean up the old code to also use it. A further benefit is that it can get called even if the passed id is 0, allowing us to remove a lot of now unnessecary checks, and the fact that `g_clear_signal_handler()` checks for the right type size, forcing us to clean up all places where we used `guint` instead of `gulong`. No functional changes intended here and all changes should be trivial, thus bundled in one big commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
2019-11-16 00:25:52 +00:00
gulong monitors_changed_id;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
GSettings *mouse_settings;
GSettings *touchpad_settings;
GSettings *trackball_settings;
GSettings *keyboard_settings;
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
GSettings *keyboard_a11y_settings;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
GList *devices;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
GHashTable *mappable_devices;
backends: Fetch libwacom information for tablets in MetaInputSettings Given that information defines largely how such devices are to be configured, it makes sense to have that information at hand. A getter has been also added for the places where it could be useful, although it will require HAVE_LIBWACOM checks in callers too.
2016-05-13 11:20:07 +00:00
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
GHashTable *current_tools;
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
GHashTable *two_finger_devices;
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
MetaKbdA11ySettings kbd_a11y_settings;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
};
backends: Add mapping function arg to settings_set_bool_setting() This will be useful to actually determine on a per-device basis the setting being applied, while still doing changes on a per-device-type basis. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-23 17:42:11 +00:00
typedef gboolean (* ConfigBoolMappingFunc) (MetaInputSettings *input_settings,
ClutterInputDevice *device,
gboolean value);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
typedef void (*ConfigBoolFunc) (MetaInputSettings *input_settings,
ClutterInputDevice *device,
gboolean setting);
typedef void (*ConfigDoubleFunc) (MetaInputSettings *input_settings,
ClutterInputDevice *device,
gdouble value);
typedef void (*ConfigUintFunc) (MetaInputSettings *input_settings,
ClutterInputDevice *device,
guint value);
G_DEFINE_TYPE_WITH_PRIVATE (MetaInputSettings, meta_input_settings, G_TYPE_OBJECT)
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
enum
{
KBD_A11Y_CHANGED,
N_SIGNALS
};
static guint signals[N_SIGNALS] = { 0 };
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
static gboolean
device_matches_capabilities (ClutterInputDevice *device,
ClutterInputCapabilities require_capabilities,
ClutterInputCapabilities reject_capabilities)
{
ClutterInputCapabilities capabilities;
capabilities = clutter_input_device_get_capabilities (device);
if ((capabilities & require_capabilities) != require_capabilities)
return FALSE;
if ((capabilities & reject_capabilities) != 0)
return FALSE;
return TRUE;
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
static GSList *
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
meta_input_settings_get_devices (MetaInputSettings *settings,
ClutterInputCapabilities require_capabilities,
ClutterInputCapabilities reject_capabilities)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
MetaInputSettingsPrivate *priv;
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
GList *l;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
GSList *list = NULL;
priv = meta_input_settings_get_instance_private (settings);
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
for (l = priv->devices; l; l = l->next)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
backends: Replace ClutterDeviceManager usage in favor of ClutterSeat https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
2019-10-04 19:57:26 +00:00
ClutterInputDevice *device = l->data;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if (clutter_input_device_get_device_mode (device) == CLUTTER_INPUT_MODE_LOGICAL)
continue;
if (!device_matches_capabilities (device,
require_capabilities,
reject_capabilities))
continue;
list = g_slist_prepend (list, device);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
return list;
}
static void
meta_input_settings_dispose (GObject *object)
{
MetaInputSettings *settings = META_INPUT_SETTINGS (object);
MetaInputSettingsPrivate *priv = meta_input_settings_get_instance_private (settings);
g_clear_object (&priv->mouse_settings);
g_clear_object (&priv->touchpad_settings);
g_clear_object (&priv->trackball_settings);
g_clear_object (&priv->keyboard_settings);
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
g_clear_object (&priv->keyboard_a11y_settings);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
g_clear_pointer (&priv->mappable_devices, g_hash_table_unref);
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
g_clear_pointer (&priv->current_tools, g_hash_table_unref);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
g_clear_pointer (&priv->two_finger_devices, g_hash_table_destroy);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
G_OBJECT_CLASS (meta_input_settings_parent_class)->dispose (object);
}
static void
settings_device_set_bool_setting (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ConfigBoolFunc func,
gboolean enabled)
{
func (input_settings, device, enabled);
}
static void
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (MetaInputSettings *input_settings,
ClutterInputCapabilities capabilities,
ClutterInputCapabilities unset_capabilities,
ConfigBoolMappingFunc mapping_func,
ConfigBoolFunc func,
gboolean enabled)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
backends: Add mapping function arg to settings_set_bool_setting() This will be useful to actually determine on a per-device basis the setting being applied, while still doing changes on a per-device-type basis. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-23 17:42:11 +00:00
GSList *devices, *l;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
devices = meta_input_settings_get_devices (input_settings,
capabilities,
unset_capabilities);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
backends: Add mapping function arg to settings_set_bool_setting() This will be useful to actually determine on a per-device basis the setting being applied, while still doing changes on a per-device-type basis. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-23 17:42:11 +00:00
for (l = devices; l; l = l->next)
{
gboolean value = enabled;
if (mapping_func)
value = mapping_func (input_settings, l->data, value);
settings_device_set_bool_setting (input_settings, l->data, func, value);
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
g_slist_free (devices);
}
static void
settings_device_set_double_setting (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ConfigDoubleFunc func,
gdouble value)
{
func (input_settings, device, value);
}
static void
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_double_setting (MetaInputSettings *input_settings,
ClutterInputCapabilities capabilities,
ClutterInputCapabilities unset_capabilities,
ConfigDoubleFunc func,
gdouble value)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
GSList *devices, *d;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
devices = meta_input_settings_get_devices (input_settings,
capabilities,
unset_capabilities);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
for (d = devices; d; d = d->next)
settings_device_set_double_setting (input_settings, d->data, func, value);
g_slist_free (devices);
}
static void
settings_device_set_uint_setting (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ConfigUintFunc func,
guint value)
{
(func) (input_settings, device, value);
}
static void
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_uint_setting (MetaInputSettings *input_settings,
ClutterInputCapabilities capabilities,
ClutterInputCapabilities unset_capabilities,
ConfigUintFunc func,
guint value)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
GSList *devices, *d;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
devices = meta_input_settings_get_devices (input_settings,
capabilities,
unset_capabilities);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
for (d = devices; d; d = d->next)
settings_device_set_uint_setting (input_settings, d->data, func, value);
g_slist_free (devices);
}
static void
update_touchpad_left_handed (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
GDesktopTouchpadHandedness handedness;
MetaInputSettingsPrivate *priv;
gboolean enabled = FALSE;
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
return;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
handedness = g_settings_get_enum (priv->touchpad_settings, "left-handed");
switch (handedness)
{
case G_DESKTOP_TOUCHPAD_HANDEDNESS_RIGHT:
enabled = FALSE;
break;
case G_DESKTOP_TOUCHPAD_HANDEDNESS_LEFT:
enabled = TRUE;
break;
case G_DESKTOP_TOUCHPAD_HANDEDNESS_MOUSE:
enabled = g_settings_get_boolean (priv->mouse_settings, "left-handed");
break;
default:
g_assert_not_reached ();
}
if (device)
{
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_left_handed,
enabled);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
NULL,
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input_settings_class->set_left_handed,
enabled);
}
}
static void
update_mouse_left_handed (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
gboolean enabled;
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_POINTER,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD))
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
return;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
enabled = g_settings_get_boolean (priv->mouse_settings, "left-handed");
if (device)
{
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_left_handed,
enabled);
}
else
{
GDesktopTouchpadHandedness touchpad_handedness;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_POINTER,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
NULL,
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input_settings_class->set_left_handed,
enabled);
touchpad_handedness = g_settings_get_enum (priv->touchpad_settings,
"left-handed");
/* Also update touchpads if they're following mouse settings */
if (touchpad_handedness == G_DESKTOP_TOUCHPAD_HANDEDNESS_MOUSE)
update_touchpad_left_handed (input_settings, NULL);
}
}
settings: Support mouse and trackball accel profile Support changing the mouse and trackball acceleration profile. This makes it possible to for example disable pointer acceleration by choosing the 'flat' profile. This adds an optional dependency on gudev. Gudev is used by the X11 backend to detect whether a device is a mouse or not. Without gudev support, the accel profile settings has have effect for mouse devices. Trackball still uses the "strstr" approach, since udev doesn't support tagging devices as trackball devices yet. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-04-07 07:44:28 +00:00
static void
do_update_pointer_accel_profile (MetaInputSettings *input_settings,
GSettings *settings,
ClutterInputDevice *device,
GDesktopPointerAccelProfile profile)
{
MetaInputSettingsPrivate *priv =
meta_input_settings_get_instance_private (input_settings);
MetaInputSettingsClass *input_settings_class =
META_INPUT_SETTINGS_GET_CLASS (input_settings);
if (settings == priv->mouse_settings)
input_settings_class->set_mouse_accel_profile (input_settings,
device,
profile);
else if (settings == priv->trackball_settings)
input_settings_class->set_trackball_accel_profile (input_settings,
device,
profile);
}
static void
update_pointer_accel_profile (MetaInputSettings *input_settings,
GSettings *settings,
ClutterInputDevice *device)
{
GDesktopPointerAccelProfile profile;
profile = g_settings_get_enum (settings, "accel-profile");
if (device)
{
do_update_pointer_accel_profile (input_settings, settings,
device, profile);
}
else
{
MetaInputSettingsPrivate *priv =
meta_input_settings_get_instance_private (input_settings);
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
GList *l;
settings: Support mouse and trackball accel profile Support changing the mouse and trackball acceleration profile. This makes it possible to for example disable pointer acceleration by choosing the 'flat' profile. This adds an optional dependency on gudev. Gudev is used by the X11 backend to detect whether a device is a mouse or not. Without gudev support, the accel profile settings has have effect for mouse devices. Trackball still uses the "strstr" approach, since udev doesn't support tagging devices as trackball devices yet. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-04-07 07:44:28 +00:00
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
for (l = priv->devices; l; l = l->next)
settings: Support mouse and trackball accel profile Support changing the mouse and trackball acceleration profile. This makes it possible to for example disable pointer acceleration by choosing the 'flat' profile. This adds an optional dependency on gudev. Gudev is used by the X11 backend to detect whether a device is a mouse or not. Without gudev support, the accel profile settings has have effect for mouse devices. Trackball still uses the "strstr" approach, since udev doesn't support tagging devices as trackball devices yet. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-04-07 07:44:28 +00:00
{
device = l->data;
if (clutter_input_device_get_device_mode (device) ==
clutter/backends: Rename master and slave devices Just because X11/XI uses a particular terminology doesn't mean we have to use the same terms in our own API. The replacement terms are in line with gtk@1c856a208, which seems a better precedent for consistency. Follow-up to commit 17417a82a5. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
2020-08-31 16:47:23 +00:00
CLUTTER_INPUT_MODE_LOGICAL)
settings: Support mouse and trackball accel profile Support changing the mouse and trackball acceleration profile. This makes it possible to for example disable pointer acceleration by choosing the 'flat' profile. This adds an optional dependency on gudev. Gudev is used by the X11 backend to detect whether a device is a mouse or not. Without gudev support, the accel profile settings has have effect for mouse devices. Trackball still uses the "strstr" approach, since udev doesn't support tagging devices as trackball devices yet. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-04-07 07:44:28 +00:00
continue;
do_update_pointer_accel_profile (input_settings, settings,
device, profile);
}
}
}
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
static GSettings *
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
get_settings_for_capabilities (MetaInputSettings *input_settings,
ClutterInputCapabilities capabilities)
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
{
MetaInputSettingsPrivate *priv;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if (capabilities & CLUTTER_INPUT_CAPABILITY_TOUCHPAD)
return priv->touchpad_settings;
if (capabilities & CLUTTER_INPUT_CAPABILITY_POINTER)
return priv->mouse_settings;
return NULL;
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
}
input-settings: Wire up middle-emulation This allows emulating middle click via simultaneous left and right click. Fixes #238. https://gitlab.gnome.org/GNOME/mutter/merge_requests/256
2018-10-06 00:06:58 +00:00
static void
update_middle_click_emulation (MetaInputSettings *input_settings,
GSettings *settings,
ClutterInputDevice *device)
{
ConfigBoolFunc func;
input-settings: Specify middle-click-emulation key Which exists, unlike `emulate-middle`. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1124
2020-03-16 07:09:00 +00:00
const gchar *key = "middle-click-emulation";
input-settings: Wire up middle-emulation This allows emulating middle click via simultaneous left and right click. Fixes #238. https://gitlab.gnome.org/GNOME/mutter/merge_requests/256
2018-10-06 00:06:58 +00:00
MetaInputSettingsPrivate *priv = meta_input_settings_get_instance_private (input_settings);
if (!settings)
return;
if (settings == priv->mouse_settings)
func = META_INPUT_SETTINGS_GET_CLASS (input_settings)->set_mouse_middle_click_emulation;
else if (settings == priv->touchpad_settings)
func = META_INPUT_SETTINGS_GET_CLASS (input_settings)->set_touchpad_middle_click_emulation;
else if (settings == priv->trackball_settings)
func = META_INPUT_SETTINGS_GET_CLASS (input_settings)->set_trackball_middle_click_emulation;
else
return;
if (device)
{
settings_device_set_bool_setting (input_settings, device, func,
g_settings_get_boolean (settings, key));
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_POINTER,
CLUTTER_INPUT_CAPABILITY_NONE,
backends: Add mapping function arg to settings_set_bool_setting() This will be useful to actually determine on a per-device basis the setting being applied, while still doing changes on a per-device-type basis. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-23 17:42:11 +00:00
NULL, func,
input-settings: Wire up middle-emulation This allows emulating middle click via simultaneous left and right click. Fixes #238. https://gitlab.gnome.org/GNOME/mutter/merge_requests/256
2018-10-06 00:06:58 +00:00
g_settings_get_boolean (settings, key));
}
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
static void
update_device_speed (MetaInputSettings *input_settings,
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
ClutterInputDevice *device)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
GSettings *settings;
ConfigDoubleFunc func;
const gchar *key = "speed";
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
func = META_INPUT_SETTINGS_GET_CLASS (input_settings)->set_speed;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
if (device)
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings = get_settings_for_capabilities (input_settings,
clutter_input_device_get_capabilities (device));
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
if (!settings)
return;
settings_device_set_double_setting (input_settings, device, func,
g_settings_get_double (settings, key));
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
else
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings = get_settings_for_capabilities (input_settings,
CLUTTER_INPUT_CAPABILITY_POINTER);
settings_set_double_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_POINTER,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
func,
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
g_settings_get_double (settings, key));
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings = get_settings_for_capabilities (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD);
settings_set_double_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
func,
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
g_settings_get_double (settings, key));
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
static void
update_device_natural_scroll (MetaInputSettings *input_settings,
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
ClutterInputDevice *device)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
GSettings *settings;
ConfigBoolFunc func;
const gchar *key = "natural-scroll";
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
func = META_INPUT_SETTINGS_GET_CLASS (input_settings)->set_invert_scroll;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
if (device)
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings = get_settings_for_capabilities (input_settings,
clutter_input_device_get_capabilities (device));
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
if (!settings)
return;
settings_device_set_bool_setting (input_settings, device, func,
g_settings_get_boolean (settings, key));
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings = get_settings_for_capabilities (input_settings,
CLUTTER_INPUT_CAPABILITY_POINTER);
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_POINTER,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
backends: Add mapping function arg to settings_set_bool_setting() This will be useful to actually determine on a per-device basis the setting being applied, while still doing changes on a per-device-type basis. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-23 17:42:11 +00:00
NULL, func,
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
g_settings_get_boolean (settings, key));
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings = get_settings_for_capabilities (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD);
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
backends: Add mapping function arg to settings_set_bool_setting() This will be useful to actually determine on a per-device basis the setting being applied, while still doing changes on a per-device-type basis. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-23 17:42:11 +00:00
NULL, func,
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
g_settings_get_boolean (settings, key));
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
}
Implements disable-while-typing in mutter. Disable-while-typing disables the touchpad while the user is typing. This patch introduces the necessary backend code to implement the org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of gsettings-desktop-schemas which was implemented in commit 4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24. This is known as dwt in libinput. This patch has been tested on X11 and Wayland. https://bugzilla.gnome.org/show_bug.cgi?id=764852
2017-05-23 13:38:00 +00:00
static void
update_touchpad_disable_while_typing (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
GSettings *settings;
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
gboolean enabled;
const gchar *key = "disable-while-typing";
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
Implements disable-while-typing in mutter. Disable-while-typing disables the touchpad while the user is typing. This patch introduces the necessary backend code to implement the org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of gsettings-desktop-schemas which was implemented in commit 4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24. This is known as dwt in libinput. This patch has been tested on X11 and Wayland. https://bugzilla.gnome.org/show_bug.cgi?id=764852
2017-05-23 13:38:00 +00:00
return;
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
enabled = g_settings_get_boolean (priv->touchpad_settings, key);
if (device)
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings = get_settings_for_capabilities (input_settings,
clutter_input_device_get_capabilities (device));
Implements disable-while-typing in mutter. Disable-while-typing disables the touchpad while the user is typing. This patch introduces the necessary backend code to implement the org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of gsettings-desktop-schemas which was implemented in commit 4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24. This is known as dwt in libinput. This patch has been tested on X11 and Wayland. https://bugzilla.gnome.org/show_bug.cgi?id=764852
2017-05-23 13:38:00 +00:00
if (!settings)
return;
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_disable_while_typing,
enabled);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
NULL,
Implements disable-while-typing in mutter. Disable-while-typing disables the touchpad while the user is typing. This patch introduces the necessary backend code to implement the org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of gsettings-desktop-schemas which was implemented in commit 4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24. This is known as dwt in libinput. This patch has been tested on X11 and Wayland. https://bugzilla.gnome.org/show_bug.cgi?id=764852
2017-05-23 13:38:00 +00:00
input_settings_class->set_disable_while_typing,
enabled);
}
}
backends: Always enable tap-to-click/drag on opaque Wacom tablets Touch-wise, those are essentially giant touchpads, but have no buttons associated to the "touchpad" device (There may be pad buttons, but those are not mouse buttons). Without tap-to-click/drag, touch in those devices is somewhat useless out of the box. Have them always enable these features, despite the setting. https://gitlab.gnome.org/GNOME/mutter/merge_requests/968
2019-12-12 17:05:08 +00:00
static gboolean
device_is_tablet_touchpad (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
#ifdef HAVE_LIBWACOM
WacomIntegrationFlags flags = 0;
WacomDevice *wacom_device;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if (device &&
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
backends: Always enable tap-to-click/drag on opaque Wacom tablets Touch-wise, those are essentially giant touchpads, but have no buttons associated to the "touchpad" device (There may be pad buttons, but those are not mouse buttons). Without tap-to-click/drag, touch in those devices is somewhat useless out of the box. Have them always enable these features, despite the setting. https://gitlab.gnome.org/GNOME/mutter/merge_requests/968
2019-12-12 17:05:08 +00:00
return FALSE;
backends: Drop internal WacomDevice in MetaInputSettings Use the one from MetaInputDevice instead. Since we no longer try to ask for WacomDevices that weren't first retrieved: Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1086 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
2020-03-06 13:53:45 +00:00
wacom_device = meta_input_device_get_wacom_device (META_INPUT_DEVICE (device));
backends: Always enable tap-to-click/drag on opaque Wacom tablets Touch-wise, those are essentially giant touchpads, but have no buttons associated to the "touchpad" device (There may be pad buttons, but those are not mouse buttons). Without tap-to-click/drag, touch in those devices is somewhat useless out of the box. Have them always enable these features, despite the setting. https://gitlab.gnome.org/GNOME/mutter/merge_requests/968
2019-12-12 17:05:08 +00:00
if (wacom_device)
{
flags = libwacom_get_integration_flags (wacom_device);
if ((flags & (WACOM_DEVICE_INTEGRATED_SYSTEM |
WACOM_DEVICE_INTEGRATED_DISPLAY)) == 0)
return TRUE;
}
#endif
return FALSE;
}
backends: Fix configuration changes to tap[-and-drag] Most people just see a harmless warning when applying this setting to all touchpads (which this patch fixes). But tap[-and-drag] is supposed to remain enabled for display-less Wacom tablets, despite configuration changes. Fix this by using the mapping function, so the setting is forced on for wacom devices. This happens on a per-device basis, so the warning is gone too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-24 12:16:11 +00:00
static gboolean
force_enable_on_tablet (MetaInputSettings *input_settings,
ClutterInputDevice *device,
gboolean value)
{
return device_is_tablet_touchpad (input_settings, device) || value;
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
static void
update_touchpad_tap_enabled (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
gboolean enabled;
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
return;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
backends: Fix configuration changes to tap[-and-drag] Most people just see a harmless warning when applying this setting to all touchpads (which this patch fixes). But tap[-and-drag] is supposed to remain enabled for display-less Wacom tablets, despite configuration changes. Fix this by using the mapping function, so the setting is forced on for wacom devices. This happens on a per-device basis, so the warning is gone too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-24 12:16:11 +00:00
enabled = g_settings_get_boolean (priv->touchpad_settings, "tap-to-click");
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
if (device)
{
backends: Fix configuration changes to tap[-and-drag] Most people just see a harmless warning when applying this setting to all touchpads (which this patch fixes). But tap[-and-drag] is supposed to remain enabled for display-less Wacom tablets, despite configuration changes. Fix this by using the mapping function, so the setting is forced on for wacom devices. This happens on a per-device basis, so the warning is gone too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-24 12:16:11 +00:00
enabled = force_enable_on_tablet (input_settings, device, enabled);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_tap_enabled,
enabled);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
backends: Fix configuration changes to tap[-and-drag] Most people just see a harmless warning when applying this setting to all touchpads (which this patch fixes). But tap[-and-drag] is supposed to remain enabled for display-less Wacom tablets, despite configuration changes. Fix this by using the mapping function, so the setting is forced on for wacom devices. This happens on a per-device basis, so the warning is gone too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-24 12:16:11 +00:00
force_enable_on_tablet,
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input_settings_class->set_tap_enabled,
enabled);
}
}
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
static void
update_touchpad_tap_button_map (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
GDesktopTouchpadTapButtonMap method;
MetaInputSettingsPrivate *priv;
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
return;
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
method = g_settings_get_enum (priv->touchpad_settings, "tap-button-map");
if (device)
{
settings_device_set_uint_setting (input_settings, device,
input_settings_class->set_tap_button_map,
method);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_uint_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
(ConfigUintFunc) input_settings_class->set_tap_button_map,
method);
}
}
Add tag-and-drag setting from libinput into mutter The problem is that libinput offers the possibility to not enabled dragging when tap-to-click is enabled but mutter doesn't. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas. To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click in mutter. Because it's already a specification of libinput, it remains to add it to mutter. Implementation with X11 is added too. https://bugzilla.gnome.org/show_bug.cgi?id=775755
2017-08-17 23:00:10 +00:00
static void
update_touchpad_tap_and_drag_enabled (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
gboolean enabled;
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
Add tag-and-drag setting from libinput into mutter The problem is that libinput offers the possibility to not enabled dragging when tap-to-click is enabled but mutter doesn't. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas. To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click in mutter. Because it's already a specification of libinput, it remains to add it to mutter. Implementation with X11 is added too. https://bugzilla.gnome.org/show_bug.cgi?id=775755
2017-08-17 23:00:10 +00:00
return;
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
backends: Fix configuration changes to tap[-and-drag] Most people just see a harmless warning when applying this setting to all touchpads (which this patch fixes). But tap[-and-drag] is supposed to remain enabled for display-less Wacom tablets, despite configuration changes. Fix this by using the mapping function, so the setting is forced on for wacom devices. This happens on a per-device basis, so the warning is gone too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-24 12:16:11 +00:00
enabled = g_settings_get_boolean (priv->touchpad_settings, "tap-and-drag");
Add tag-and-drag setting from libinput into mutter The problem is that libinput offers the possibility to not enabled dragging when tap-to-click is enabled but mutter doesn't. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas. To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click in mutter. Because it's already a specification of libinput, it remains to add it to mutter. Implementation with X11 is added too. https://bugzilla.gnome.org/show_bug.cgi?id=775755
2017-08-17 23:00:10 +00:00
if (device)
{
backends: Fix configuration changes to tap[-and-drag] Most people just see a harmless warning when applying this setting to all touchpads (which this patch fixes). But tap[-and-drag] is supposed to remain enabled for display-less Wacom tablets, despite configuration changes. Fix this by using the mapping function, so the setting is forced on for wacom devices. This happens on a per-device basis, so the warning is gone too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-24 12:16:11 +00:00
enabled = force_enable_on_tablet (input_settings, device, enabled);
Add tag-and-drag setting from libinput into mutter The problem is that libinput offers the possibility to not enabled dragging when tap-to-click is enabled but mutter doesn't. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas. To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click in mutter. Because it's already a specification of libinput, it remains to add it to mutter. Implementation with X11 is added too. https://bugzilla.gnome.org/show_bug.cgi?id=775755
2017-08-17 23:00:10 +00:00
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_tap_and_drag_enabled,
enabled);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
backends: Fix configuration changes to tap[-and-drag] Most people just see a harmless warning when applying this setting to all touchpads (which this patch fixes). But tap[-and-drag] is supposed to remain enabled for display-less Wacom tablets, despite configuration changes. Fix this by using the mapping function, so the setting is forced on for wacom devices. This happens on a per-device basis, so the warning is gone too. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
2020-03-24 12:16:11 +00:00
force_enable_on_tablet,
Add tag-and-drag setting from libinput into mutter The problem is that libinput offers the possibility to not enabled dragging when tap-to-click is enabled but mutter doesn't. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas. To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click in mutter. Because it's already a specification of libinput, it remains to add it to mutter. Implementation with X11 is added too. https://bugzilla.gnome.org/show_bug.cgi?id=775755
2017-08-17 23:00:10 +00:00
input_settings_class->set_tap_and_drag_enabled,
enabled);
}
}
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
static void
update_touchpad_tap_and_drag_lock_enabled (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
gboolean enabled;
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
return;
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
enabled = g_settings_get_boolean (priv->touchpad_settings, "tap-and-drag-lock");
if (device)
{
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_tap_and_drag_lock_enabled,
enabled);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
NULL,
input_settings_class->set_tap_and_drag_lock_enabled,
enabled);
}
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
static void
backends: Force 2-finger scroll by default if available When the touchpad is two-finger scrolling capable, always enable it. When the touchpad only supports edge scrolling (usually older devices, and usually smaller devices), allow disabling the edge scrolling. This requires a newer gsettings-desktop-schemas as the scroll-method key was removed, and the edge-scroll-enabled key added. https://bugzilla.gnome.org/show_bug.cgi?id=759304
2015-12-11 11:32:46 +00:00
update_touchpad_edge_scroll (MetaInputSettings *input_settings,
ClutterInputDevice *device)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
MetaInputSettingsClass *input_settings_class;
backends: Force 2-finger scroll by default if available When the touchpad is two-finger scrolling capable, always enable it. When the touchpad only supports edge scrolling (usually older devices, and usually smaller devices), allow disabling the edge scrolling. This requires a newer gsettings-desktop-schemas as the scroll-method key was removed, and the edge-scroll-enabled key added. https://bugzilla.gnome.org/show_bug.cgi?id=759304
2015-12-11 11:32:46 +00:00
gboolean edge_scroll_enabled;
MetaInputSettings: fix two finger preference over edge scrolling logic Enabling edge scrolling before disabling two finger would result in edge scrolling not actually being enabled because two finger is still enabled at the time and we bail out. This patch moves this logic to common code for both the native and X backends and fixes it by ensuring that both settings are never set at the same time and still re-checking if edge scrolling should be enabled after two finger scrolling gets disabled. We also simplify the code by not checking for supported/available settings since the underlying devices will just reject those values and there isn't anything we can do about it here. It's the UI's job to only show supported/available settings to users. https://bugzilla.gnome.org/show_bug.cgi?id=771744
2016-10-27 17:25:16 +00:00
gboolean two_finger_scroll_enabled;
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
gboolean two_finger_scroll_available;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
MetaInputSettingsPrivate *priv;
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
return;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
backends: Force 2-finger scroll by default if available When the touchpad is two-finger scrolling capable, always enable it. When the touchpad only supports edge scrolling (usually older devices, and usually smaller devices), allow disabling the edge scrolling. This requires a newer gsettings-desktop-schemas as the scroll-method key was removed, and the edge-scroll-enabled key added. https://bugzilla.gnome.org/show_bug.cgi?id=759304
2015-12-11 11:32:46 +00:00
edge_scroll_enabled = g_settings_get_boolean (priv->touchpad_settings, "edge-scrolling-enabled");
MetaInputSettings: fix two finger preference over edge scrolling logic Enabling edge scrolling before disabling two finger would result in edge scrolling not actually being enabled because two finger is still enabled at the time and we bail out. This patch moves this logic to common code for both the native and X backends and fixes it by ensuring that both settings are never set at the same time and still re-checking if edge scrolling should be enabled after two finger scrolling gets disabled. We also simplify the code by not checking for supported/available settings since the underlying devices will just reject those values and there isn't anything we can do about it here. It's the UI's job to only show supported/available settings to users. https://bugzilla.gnome.org/show_bug.cgi?id=771744
2016-10-27 17:25:16 +00:00
two_finger_scroll_enabled = g_settings_get_boolean (priv->touchpad_settings, "two-finger-scrolling-enabled");
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
two_finger_scroll_available = g_hash_table_size (priv->two_finger_devices) > 0;
MetaInputSettings: fix two finger preference over edge scrolling logic Enabling edge scrolling before disabling two finger would result in edge scrolling not actually being enabled because two finger is still enabled at the time and we bail out. This patch moves this logic to common code for both the native and X backends and fixes it by ensuring that both settings are never set at the same time and still re-checking if edge scrolling should be enabled after two finger scrolling gets disabled. We also simplify the code by not checking for supported/available settings since the underlying devices will just reject those values and there isn't anything we can do about it here. It's the UI's job to only show supported/available settings to users. https://bugzilla.gnome.org/show_bug.cgi?id=771744
2016-10-27 17:25:16 +00:00
/* If both are enabled we prefer two finger. */
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
if (edge_scroll_enabled && two_finger_scroll_enabled && two_finger_scroll_available)
MetaInputSettings: fix two finger preference over edge scrolling logic Enabling edge scrolling before disabling two finger would result in edge scrolling not actually being enabled because two finger is still enabled at the time and we bail out. This patch moves this logic to common code for both the native and X backends and fixes it by ensuring that both settings are never set at the same time and still re-checking if edge scrolling should be enabled after two finger scrolling gets disabled. We also simplify the code by not checking for supported/available settings since the underlying devices will just reject those values and there isn't anything we can do about it here. It's the UI's job to only show supported/available settings to users. https://bugzilla.gnome.org/show_bug.cgi?id=771744
2016-10-27 17:25:16 +00:00
edge_scroll_enabled = FALSE;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
if (device)
{
backends: Force 2-finger scroll by default if available When the touchpad is two-finger scrolling capable, always enable it. When the touchpad only supports edge scrolling (usually older devices, and usually smaller devices), allow disabling the edge scrolling. This requires a newer gsettings-desktop-schemas as the scroll-method key was removed, and the edge-scroll-enabled key added. https://bugzilla.gnome.org/show_bug.cgi?id=759304
2015-12-11 11:32:46 +00:00
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_edge_scroll,
edge_scroll_enabled);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
NULL,
backends: Force 2-finger scroll by default if available When the touchpad is two-finger scrolling capable, always enable it. When the touchpad only supports edge scrolling (usually older devices, and usually smaller devices), allow disabling the edge scrolling. This requires a newer gsettings-desktop-schemas as the scroll-method key was removed, and the edge-scroll-enabled key added. https://bugzilla.gnome.org/show_bug.cgi?id=759304
2015-12-11 11:32:46 +00:00
(ConfigBoolFunc) input_settings_class->set_edge_scroll,
edge_scroll_enabled);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
}
backends: Re-add support for edge scrolling with some touchpads Add support for setting edge-scrolling separately from two-finger scrolling. We now have 2 separate boolean settings for those, with the Mouse panel in gnome-control-center allowing to set only one of those at a time, but nothing precludes both being set in the configuration. We need to handle: - two-finger-scrolling-enabled and edge-scrolling-enabled settings both being set. - those 2 settings being change out-of-order - two-finger-scrolling being set on a device that doesn't support it - edge-scrolling-enabled on a device that doesn't support it And the combinations of one touchpad supporting just one of edge scrolling and two-finger scrolling and another vice-versa. https://bugzilla.gnome.org/show_bug.cgi?id=768245
2016-06-30 12:27:23 +00:00
static void
update_touchpad_two_finger_scroll (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
gboolean two_finger_scroll_enabled;
MetaInputSettingsPrivate *priv;
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
backends: Re-add support for edge scrolling with some touchpads Add support for setting edge-scrolling separately from two-finger scrolling. We now have 2 separate boolean settings for those, with the Mouse panel in gnome-control-center allowing to set only one of those at a time, but nothing precludes both being set in the configuration. We need to handle: - two-finger-scrolling-enabled and edge-scrolling-enabled settings both being set. - those 2 settings being change out-of-order - two-finger-scrolling being set on a device that doesn't support it - edge-scrolling-enabled on a device that doesn't support it And the combinations of one touchpad supporting just one of edge scrolling and two-finger scrolling and another vice-versa. https://bugzilla.gnome.org/show_bug.cgi?id=768245
2016-06-30 12:27:23 +00:00
return;
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
two_finger_scroll_enabled = g_settings_get_boolean (priv->touchpad_settings, "two-finger-scrolling-enabled");
MetaInputSettings: fix two finger preference over edge scrolling logic Enabling edge scrolling before disabling two finger would result in edge scrolling not actually being enabled because two finger is still enabled at the time and we bail out. This patch moves this logic to common code for both the native and X backends and fixes it by ensuring that both settings are never set at the same time and still re-checking if edge scrolling should be enabled after two finger scrolling gets disabled. We also simplify the code by not checking for supported/available settings since the underlying devices will just reject those values and there isn't anything we can do about it here. It's the UI's job to only show supported/available settings to users. https://bugzilla.gnome.org/show_bug.cgi?id=771744
2016-10-27 17:25:16 +00:00
/* Disable edge since they can't both be set. */
if (two_finger_scroll_enabled)
update_touchpad_edge_scroll (input_settings, device);
backends: Re-add support for edge scrolling with some touchpads Add support for setting edge-scrolling separately from two-finger scrolling. We now have 2 separate boolean settings for those, with the Mouse panel in gnome-control-center allowing to set only one of those at a time, but nothing precludes both being set in the configuration. We need to handle: - two-finger-scrolling-enabled and edge-scrolling-enabled settings both being set. - those 2 settings being change out-of-order - two-finger-scrolling being set on a device that doesn't support it - edge-scrolling-enabled on a device that doesn't support it And the combinations of one touchpad supporting just one of edge scrolling and two-finger scrolling and another vice-versa. https://bugzilla.gnome.org/show_bug.cgi?id=768245
2016-06-30 12:27:23 +00:00
if (device)
{
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_two_finger_scroll,
two_finger_scroll_enabled);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_bool_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
NULL,
backends: Re-add support for edge scrolling with some touchpads Add support for setting edge-scrolling separately from two-finger scrolling. We now have 2 separate boolean settings for those, with the Mouse panel in gnome-control-center allowing to set only one of those at a time, but nothing precludes both being set in the configuration. We need to handle: - two-finger-scrolling-enabled and edge-scrolling-enabled settings both being set. - those 2 settings being change out-of-order - two-finger-scrolling being set on a device that doesn't support it - edge-scrolling-enabled on a device that doesn't support it And the combinations of one touchpad supporting just one of edge scrolling and two-finger scrolling and another vice-versa. https://bugzilla.gnome.org/show_bug.cgi?id=768245
2016-06-30 12:27:23 +00:00
(ConfigBoolFunc) input_settings_class->set_two_finger_scroll,
two_finger_scroll_enabled);
}
MetaInputSettings: fix two finger preference over edge scrolling logic Enabling edge scrolling before disabling two finger would result in edge scrolling not actually being enabled because two finger is still enabled at the time and we bail out. This patch moves this logic to common code for both the native and X backends and fixes it by ensuring that both settings are never set at the same time and still re-checking if edge scrolling should be enabled after two finger scrolling gets disabled. We also simplify the code by not checking for supported/available settings since the underlying devices will just reject those values and there isn't anything we can do about it here. It's the UI's job to only show supported/available settings to users. https://bugzilla.gnome.org/show_bug.cgi?id=771744
2016-10-27 17:25:16 +00:00
/* Edge might have been disabled because two finger was on. */
if (!two_finger_scroll_enabled)
update_touchpad_edge_scroll (input_settings, device);
backends: Re-add support for edge scrolling with some touchpads Add support for setting edge-scrolling separately from two-finger scrolling. We now have 2 separate boolean settings for those, with the Mouse panel in gnome-control-center allowing to set only one of those at a time, but nothing precludes both being set in the configuration. We need to handle: - two-finger-scrolling-enabled and edge-scrolling-enabled settings both being set. - those 2 settings being change out-of-order - two-finger-scrolling being set on a device that doesn't support it - edge-scrolling-enabled on a device that doesn't support it And the combinations of one touchpad supporting just one of edge scrolling and two-finger scrolling and another vice-versa. https://bugzilla.gnome.org/show_bug.cgi?id=768245
2016-06-30 12:27:23 +00:00
}
backend: Add set_click_method MetaInputSettings vfunc This will configure the libinput_config_click_method for touchpads. https://bugzilla.gnome.org/show_bug.cgi?id=746290
2015-03-16 14:25:59 +00:00
static void
update_touchpad_click_method (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
backends: Fix cut'n'paste error in click method setting GDesktopTouchpadScrollMethod was used instead of GDesktopTouchpadClickMethod which became visible now that the former has been removed from gsettings-desktop-schemas. https://bugzilla.gnome.org/show_bug.cgi?id=759304
2015-12-15 13:40:29 +00:00
GDesktopTouchpadClickMethod method;
backend: Add set_click_method MetaInputSettings vfunc This will configure the libinput_config_click_method for touchpads. https://bugzilla.gnome.org/show_bug.cgi?id=746290
2015-03-16 14:25:59 +00:00
MetaInputSettingsPrivate *priv;
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
return;
backend: Add set_click_method MetaInputSettings vfunc This will configure the libinput_config_click_method for touchpads. https://bugzilla.gnome.org/show_bug.cgi?id=746290
2015-03-16 14:25:59 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
method = g_settings_get_enum (priv->touchpad_settings, "click-method");
if (device)
{
settings_device_set_uint_setting (input_settings, device,
input_settings_class->set_click_method,
method);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_uint_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
backend: Add set_click_method MetaInputSettings vfunc This will configure the libinput_config_click_method for touchpads. https://bugzilla.gnome.org/show_bug.cgi?id=746290
2015-03-16 14:25:59 +00:00
(ConfigUintFunc) input_settings_class->set_click_method,
method);
}
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
static void
update_touchpad_send_events (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
GDesktopDeviceSendEvents mode;
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
if (device &&
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
!device_matches_capabilities (device,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE))
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
return;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
mode = g_settings_get_enum (priv->touchpad_settings, "send-events");
if (device)
{
settings_device_set_uint_setting (input_settings, device,
input_settings_class->set_send_events,
mode);
}
else
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
settings_set_uint_setting (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE,
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input_settings_class->set_send_events,
mode);
}
}
static void
update_trackball_scroll_button (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
guint button;
backends: add support for scroll button locking Where enabled, the first click of the scroll button sets the button logically down, the second click sets the button logically up. This is an accessibility feature, it doesn't require users to keep holding the button down while scrolling which is hard or impossible for some users. gsettings-desktop-schemas merge request: https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/39 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1432
2020-09-08 01:08:05 +00:00
gboolean button_lock;
backends: Use capabilities to figure out trackballs in MetaInputSettings Port these configuration methods to use capabilities, instead of using the internal vfunc. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2617>
2022-09-06 08:20:21 +00:00
ClutterInputCapabilities caps;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
input-settings: detect trackball using udev ID_INPUT_TRACKBALL Previously, trackballs were detected based on the presence of the substring "trackball" in the device name. This had the downside of missing devices, such as the Kensington Expert Mouse, which don't have "trackball" in their names. Rather than depending on the device name, use the ID_INPUT_TRACKBALL property from udev to determine whether or not to treat a device as a trackball. This adds a new function, `is_trackball_device`, to MetaInputEvents, and eliminates the `meta_input_device_is_trackball` function. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/258
2018-09-17 19:31:16 +00:00
backends: Use capabilities to figure out trackballs in MetaInputSettings Port these configuration methods to use capabilities, instead of using the internal vfunc. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2617>
2022-09-06 08:20:21 +00:00
if (device)
{
caps = clutter_input_device_get_capabilities (device);
if ((caps & CLUTTER_INPUT_CAPABILITY_TRACKBALL) == 0)
return;
}
input-settings: detect trackball using udev ID_INPUT_TRACKBALL Previously, trackballs were detected based on the presence of the substring "trackball" in the device name. This had the downside of missing devices, such as the Kensington Expert Mouse, which don't have "trackball" in their names. Rather than depending on the device name, use the ID_INPUT_TRACKBALL property from udev to determine whether or not to treat a device as a trackball. This adds a new function, `is_trackball_device`, to MetaInputEvents, and eliminates the `meta_input_device_is_trackball` function. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/258
2018-09-17 19:31:16 +00:00
input-settings: Silence a glib critical The scroll-wheel-emulation-button key is 'i' in the schema but it also specifies a minimum range of 0 so using get_int() and casting is safe.
2015-04-14 16:27:52 +00:00
/* This key is 'i' in the schema but it also specifies a minimum
* range of 0 so the cast here is safe. */
button = (guint) g_settings_get_int (priv->trackball_settings, "scroll-wheel-emulation-button");
backends: add support for scroll button locking Where enabled, the first click of the scroll button sets the button logically down, the second click sets the button logically up. This is an accessibility feature, it doesn't require users to keep holding the button down while scrolling which is hard or impossible for some users. gsettings-desktop-schemas merge request: https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/39 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1432
2020-09-08 01:08:05 +00:00
button_lock = g_settings_get_boolean (priv->trackball_settings, "scroll-wheel-emulation-button-lock");
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
backend: Apply the right settings to the right input devices Since 8769b3d55, the checks performed on which update_* function was called for each device got quite more lax, leading to failed asserts on code that assumed the previous behavior. Change update_[mouse|touchpad|trackball]_* to bail out early if the device received has not the right type, and remove the asserts. https://bugzilla.gnome.org/show_bug.cgi?id=747886
2015-04-15 11:05:53 +00:00
if (device)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
backends: add support for scroll button locking Where enabled, the first click of the scroll button sets the button logically down, the second click sets the button logically up. This is an accessibility feature, it doesn't require users to keep holding the button down while scrolling which is hard or impossible for some users. gsettings-desktop-schemas merge request: https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/39 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1432
2020-09-08 01:08:05 +00:00
input_settings_class->set_scroll_button (input_settings, device, button, button_lock);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
else if (!device)
{
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
GList *l;
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
for (l = priv->devices; l; l = l->next)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
input-settings: fix device list iteration Dereference the loop variable rather than the original list head. This fixes a regression introduced in 4413b86a3 ("backends: Replace ClutterDeviceManager usage in favor of ClutterSeat", 2019-10-04) which broke button scrolling with trackballs. Closes:https://gitlab.gnome.org/GNOME/mutter/-/issues/1120
2020-04-11 15:08:18 +00:00
device = l->data;
backends: Use capabilities to figure out trackballs in MetaInputSettings Port these configuration methods to use capabilities, instead of using the internal vfunc. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2617>
2022-09-06 08:20:21 +00:00
caps = clutter_input_device_get_capabilities (device);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
backends: Use capabilities to figure out trackballs in MetaInputSettings Port these configuration methods to use capabilities, instead of using the internal vfunc. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2617>
2022-09-06 08:20:21 +00:00
if ((caps & CLUTTER_INPUT_CAPABILITY_TRACKBALL) != 0)
backends: add support for scroll button locking Where enabled, the first click of the scroll button sets the button logically down, the second click sets the button logically up. This is an accessibility feature, it doesn't require users to keep holding the button down while scrolling which is hard or impossible for some users. gsettings-desktop-schemas merge request: https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/39 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1432
2020-09-08 01:08:05 +00:00
input_settings_class->set_scroll_button (input_settings, device, button, button_lock);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
}
}
static void
update_keyboard_repeat (MetaInputSettings *input_settings)
{
MetaInputSettingsClass *input_settings_class;
MetaInputSettingsPrivate *priv;
guint delay, interval;
gboolean repeat;
priv = meta_input_settings_get_instance_private (input_settings);
repeat = g_settings_get_boolean (priv->keyboard_settings, "repeat");
delay = g_settings_get_uint (priv->keyboard_settings, "delay");
interval = g_settings_get_uint (priv->keyboard_settings, "repeat-interval");
meta-input-settings: Avoid setting key repeat delay or interval to 0 Since doing so causes either errors or misbehavior. https://bugzilla.gnome.org/show_bug.cgi?id=776919
2017-01-09 18:55:38 +00:00
delay = MAX (1, delay);
interval = MAX (1, interval);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
input_settings_class->set_keyboard_repeat (input_settings,
repeat, delay, interval);
}
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
static void
update_tablet_keep_aspect (MetaInputSettings *input_settings,
GSettings *settings,
ClutterInputDevice *device)
{
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
MetaInputSettingsPrivate *priv;
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
MetaInputSettingsClass *input_settings_class;
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
DeviceMappingInfo *info;
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
gboolean keep_aspect;
backends: Simplify MetaInputSettings vfunc Rename the set_tablet_keep_aspect() vfunc into a set_tablet_aspect_ratio() one that takes an aspect ratio double, instead of leaking monitor info into subclasses to let them all figure out this number themselves. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-03 16:31:19 +00:00
double aspect_ratio;
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((clutter_input_device_get_capabilities (device) &
CLUTTER_INPUT_CAPABILITY_TABLET_TOOL) == 0)
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
return;
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
info = g_hash_table_lookup (priv->mappable_devices, device);
if (!info)
return;
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
#ifdef HAVE_LIBWACOM
{
WacomDevice *wacom_device;
backends: Drop internal WacomDevice in MetaInputSettings Use the one from MetaInputDevice instead. Since we no longer try to ask for WacomDevices that weren't first retrieved: Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1086 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
2020-03-06 13:53:45 +00:00
wacom_device = meta_input_device_get_wacom_device (META_INPUT_DEVICE (device));
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
/* Keep aspect only makes sense in external tablets */
if (wacom_device &&
libwacom_get_integration_flags (wacom_device) != WACOM_DEVICE_INTEGRATED_NONE)
return;
}
#endif
backends: Fold device mapping check into backend Make the upper part agnostic about the device being relative in order to avoid applying keep-aspect. The X11 bits already are, so make it sure it's also the case for the native backend. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
2020-05-06 18:20:49 +00:00
keep_aspect = g_settings_get_boolean (settings, "keep-aspect");
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
backends: Simplify MetaInputSettings vfunc Rename the set_tablet_keep_aspect() vfunc into a set_tablet_aspect_ratio() one that takes an aspect ratio double, instead of leaking monitor info into subclasses to let them all figure out this number themselves. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-03 16:31:19 +00:00
if (keep_aspect)
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
aspect_ratio = info->aspect_ratio;
backends: Simplify MetaInputSettings vfunc Rename the set_tablet_keep_aspect() vfunc into a set_tablet_aspect_ratio() one that takes an aspect ratio double, instead of leaking monitor info into subclasses to let them all figure out this number themselves. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-03 16:31:19 +00:00
else
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
aspect_ratio = 0;
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
input_settings_class->set_tablet_aspect_ratio (input_settings, device, aspect_ratio);
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
}
static void
update_tablet_mapping (MetaInputSettings *input_settings,
GSettings *settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
GDesktopTabletMapping mapping;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((clutter_input_device_get_capabilities (device) &
CLUTTER_INPUT_CAPABILITY_TABLET_TOOL) == 0)
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
return;
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
#ifdef HAVE_LIBWACOM
{
WacomDevice *wacom_device;
backends: Drop internal WacomDevice in MetaInputSettings Use the one from MetaInputDevice instead. Since we no longer try to ask for WacomDevices that weren't first retrieved: Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1086 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
2020-03-06 13:53:45 +00:00
wacom_device = meta_input_device_get_wacom_device (META_INPUT_DEVICE (device));
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
/* Tablet mapping only makes sense on external tablets */
if (wacom_device &&
(libwacom_get_integration_flags (wacom_device) != WACOM_DEVICE_INTEGRATED_NONE))
return;
}
#endif
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
mapping = g_settings_get_enum (settings, "mapping");
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
settings_device_set_uint_setting (input_settings, device,
input_settings_class->set_tablet_mapping,
mapping);
}
static void
update_tablet_area (MetaInputSettings *input_settings,
GSettings *settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
GVariant *variant;
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
const gdouble *area;
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
gsize n_elems;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((clutter_input_device_get_capabilities (device) &
CLUTTER_INPUT_CAPABILITY_TABLET_TOOL) == 0)
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
return;
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
#ifdef HAVE_LIBWACOM
{
WacomDevice *wacom_device;
backends: Drop internal WacomDevice in MetaInputSettings Use the one from MetaInputDevice instead. Since we no longer try to ask for WacomDevices that weren't first retrieved: Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1086 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
2020-03-06 13:53:45 +00:00
wacom_device = meta_input_device_get_wacom_device (META_INPUT_DEVICE (device));
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
/* Tablet area only makes sense on system/display integrated tablets */
if (wacom_device &&
(libwacom_get_integration_flags (wacom_device) &
(WACOM_DEVICE_INTEGRATED_SYSTEM | WACOM_DEVICE_INTEGRATED_DISPLAY)) == 0)
return;
}
#endif
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
variant = g_settings_get_value (settings, "area");
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
area = g_variant_get_fixed_array (variant, &n_elems, sizeof (gdouble));
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
if (n_elems == 4)
{
input_settings_class->set_tablet_area (input_settings, device,
area[0], area[1],
area[2], area[3]);
}
g_variant_unref (variant);
}
static void
update_tablet_left_handed (MetaInputSettings *input_settings,
GSettings *settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *input_settings_class;
gboolean enabled;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((clutter_input_device_get_capabilities (device) &
(CLUTTER_INPUT_CAPABILITY_TABLET_TOOL |
CLUTTER_INPUT_CAPABILITY_TABLET_PAD)) == 0)
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
return;
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
#ifdef HAVE_LIBWACOM
{
WacomDevice *wacom_device;
backends: Drop internal WacomDevice in MetaInputSettings Use the one from MetaInputDevice instead. Since we no longer try to ask for WacomDevices that weren't first retrieved: Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1086 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
2020-03-06 13:53:45 +00:00
wacom_device = meta_input_device_get_wacom_device (META_INPUT_DEVICE (device));
backends: Perform libwacom checks before applying settings Some settings make no sense on external tablets, and others make no sense in display/system-integrated tablets. Perform those checks so we don't end up with possibly broken configuration.
2016-06-22 13:44:14 +00:00
/* Left handed mode only makes sense on external tablets */
if (wacom_device &&
(libwacom_get_integration_flags (wacom_device) != WACOM_DEVICE_INTEGRATED_NONE))
return;
}
#endif
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
enabled = g_settings_get_boolean (settings, "left-handed");
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
settings_device_set_bool_setting (input_settings, device,
input_settings_class->set_left_handed,
enabled);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
static void
meta_input_settings_changed_cb (GSettings *settings,
const char *key,
gpointer user_data)
{
MetaInputSettings *input_settings = META_INPUT_SETTINGS (user_data);
MetaInputSettingsPrivate *priv = meta_input_settings_get_instance_private (input_settings);
if (settings == priv->mouse_settings)
{
if (strcmp (key, "left-handed") == 0)
update_mouse_left_handed (input_settings, NULL);
else if (strcmp (key, "speed") == 0)
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_device_speed (input_settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
else if (strcmp (key, "natural-scroll") == 0)
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_device_natural_scroll (input_settings, NULL);
settings: Support mouse and trackball accel profile Support changing the mouse and trackball acceleration profile. This makes it possible to for example disable pointer acceleration by choosing the 'flat' profile. This adds an optional dependency on gudev. Gudev is used by the X11 backend to detect whether a device is a mouse or not. Without gudev support, the accel profile settings has have effect for mouse devices. Trackball still uses the "strstr" approach, since udev doesn't support tagging devices as trackball devices yet. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-04-07 07:44:28 +00:00
else if (strcmp (key, "accel-profile") == 0)
update_pointer_accel_profile (input_settings, settings, NULL);
input-settings: Wire up middle-emulation This allows emulating middle click via simultaneous left and right click. Fixes #238. https://gitlab.gnome.org/GNOME/mutter/merge_requests/256
2018-10-06 00:06:58 +00:00
else if (strcmp (key, "middle-click-emulation") == 0)
update_middle_click_emulation (input_settings, settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
else if (settings == priv->touchpad_settings)
{
if (strcmp (key, "left-handed") == 0)
update_touchpad_left_handed (input_settings, NULL);
else if (strcmp (key, "speed") == 0)
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_device_speed (input_settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
else if (strcmp (key, "natural-scroll") == 0)
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_device_natural_scroll (input_settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
else if (strcmp (key, "tap-to-click") == 0)
update_touchpad_tap_enabled (input_settings, NULL);
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
else if (strcmp (key, "tap-button-map") == 0)
update_touchpad_tap_button_map (input_settings, NULL);
input-settings: Fix a typo in tap-and-drag setting
2018-03-25 13:34:56 +00:00
else if (strcmp (key, "tap-and-drag") == 0)
Add tag-and-drag setting from libinput into mutter The problem is that libinput offers the possibility to not enabled dragging when tap-to-click is enabled but mutter doesn't. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas. To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click in mutter. Because it's already a specification of libinput, it remains to add it to mutter. Implementation with X11 is added too. https://bugzilla.gnome.org/show_bug.cgi?id=775755
2017-08-17 23:00:10 +00:00
update_touchpad_tap_and_drag_enabled (input_settings, NULL);
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
else if (strcmp (key, "tap-and-drag-lock") == 0)
update_touchpad_tap_and_drag_lock_enabled (input_settings, NULL);
Implements disable-while-typing in mutter. Disable-while-typing disables the touchpad while the user is typing. This patch introduces the necessary backend code to implement the org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of gsettings-desktop-schemas which was implemented in commit 4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24. This is known as dwt in libinput. This patch has been tested on X11 and Wayland. https://bugzilla.gnome.org/show_bug.cgi?id=764852
2017-05-23 13:38:00 +00:00
else if (strcmp(key, "disable-while-typing") == 0)
update_touchpad_disable_while_typing (input_settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
else if (strcmp (key, "send-events") == 0)
update_touchpad_send_events (input_settings, NULL);
backends: Force 2-finger scroll by default if available When the touchpad is two-finger scrolling capable, always enable it. When the touchpad only supports edge scrolling (usually older devices, and usually smaller devices), allow disabling the edge scrolling. This requires a newer gsettings-desktop-schemas as the scroll-method key was removed, and the edge-scroll-enabled key added. https://bugzilla.gnome.org/show_bug.cgi?id=759304
2015-12-11 11:32:46 +00:00
else if (strcmp (key, "edge-scrolling-enabled") == 0)
update_touchpad_edge_scroll (input_settings, NULL);
backends: Re-add support for edge scrolling with some touchpads Add support for setting edge-scrolling separately from two-finger scrolling. We now have 2 separate boolean settings for those, with the Mouse panel in gnome-control-center allowing to set only one of those at a time, but nothing precludes both being set in the configuration. We need to handle: - two-finger-scrolling-enabled and edge-scrolling-enabled settings both being set. - those 2 settings being change out-of-order - two-finger-scrolling being set on a device that doesn't support it - edge-scrolling-enabled on a device that doesn't support it And the combinations of one touchpad supporting just one of edge scrolling and two-finger scrolling and another vice-versa. https://bugzilla.gnome.org/show_bug.cgi?id=768245
2016-06-30 12:27:23 +00:00
else if (strcmp (key, "two-finger-scrolling-enabled") == 0)
update_touchpad_two_finger_scroll (input_settings, NULL);
backend: Add set_click_method MetaInputSettings vfunc This will configure the libinput_config_click_method for touchpads. https://bugzilla.gnome.org/show_bug.cgi?id=746290
2015-03-16 14:25:59 +00:00
else if (strcmp (key, "click-method") == 0)
update_touchpad_click_method (input_settings, NULL);
input-settings: Wire up middle-emulation This allows emulating middle click via simultaneous left and right click. Fixes #238. https://gitlab.gnome.org/GNOME/mutter/merge_requests/256
2018-10-06 00:06:58 +00:00
else if (strcmp (key, "middle-click-emulation") == 0)
update_middle_click_emulation (input_settings, settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
else if (settings == priv->trackball_settings)
{
backends: add support for scroll button locking Where enabled, the first click of the scroll button sets the button logically down, the second click sets the button logically up. This is an accessibility feature, it doesn't require users to keep holding the button down while scrolling which is hard or impossible for some users. gsettings-desktop-schemas merge request: https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/39 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1432
2020-09-08 01:08:05 +00:00
if (strcmp (key, "scroll-wheel-emulation-button") == 0 ||
strcmp (key, "scroll-wheel-emulation-button-lock") == 0)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
update_trackball_scroll_button (input_settings, NULL);
settings: Support mouse and trackball accel profile Support changing the mouse and trackball acceleration profile. This makes it possible to for example disable pointer acceleration by choosing the 'flat' profile. This adds an optional dependency on gudev. Gudev is used by the X11 backend to detect whether a device is a mouse or not. Without gudev support, the accel profile settings has have effect for mouse devices. Trackball still uses the "strstr" approach, since udev doesn't support tagging devices as trackball devices yet. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-04-07 07:44:28 +00:00
else if (strcmp (key, "accel-profile") == 0)
update_pointer_accel_profile (input_settings, settings, NULL);
input-settings: Wire up middle-emulation This allows emulating middle click via simultaneous left and right click. Fixes #238. https://gitlab.gnome.org/GNOME/mutter/merge_requests/256
2018-10-06 00:06:58 +00:00
else if (strcmp (key, "middle-click-emulation") == 0)
update_middle_click_emulation (input_settings, settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
else if (settings == priv->keyboard_settings)
{
if (strcmp (key, "repeat") == 0 ||
strcmp (key, "repeat-interval") == 0 ||
strcmp (key, "delay") == 0)
update_keyboard_repeat (input_settings);
}
}
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
static void
mapped_device_changed_cb (GSettings *settings,
const gchar *key,
DeviceMappingInfo *info)
{
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
if (strcmp (key, "mapping") == 0)
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
update_tablet_mapping (info->input_settings, settings, info->device);
else if (strcmp (key, "area") == 0)
update_tablet_area (info->input_settings, settings, info->device);
else if (strcmp (key, "keep-aspect") == 0)
update_tablet_keep_aspect (info->input_settings, settings, info->device);
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
else if (strcmp (key, "left-handed") == 0)
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
update_tablet_left_handed (info->input_settings, settings, info->device);
}
static void
apply_mappable_device_settings (MetaInputSettings *input_settings,
DeviceMappingInfo *info)
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
ClutterInputCapabilities capabilities;
backends: Apply tablet settings on all tablet device types during startup This skipped the device types that are in use on X11. https://bugzilla.gnome.org/show_bug.cgi?id=782027
2017-06-30 09:45:48 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
capabilities = clutter_input_device_get_capabilities (info->device);
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if (capabilities &
(CLUTTER_INPUT_CAPABILITY_TABLET_TOOL |
CLUTTER_INPUT_CAPABILITY_TABLET_PAD))
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
{
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
update_tablet_mapping (input_settings, info->settings, info->device);
update_tablet_area (input_settings, info->settings, info->device);
update_tablet_keep_aspect (input_settings, info->settings, info->device);
update_tablet_left_handed (input_settings, info->settings, info->device);
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
}
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
}
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
struct _keyboard_a11y_settings_flags_pair {
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
const char *name;
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
MetaKeyboardA11yFlags flag;
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
} keyboard_a11y_settings_flags_pair[] = {
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
{ "enable", META_A11Y_KEYBOARD_ENABLED },
{ "timeout-enable", META_A11Y_TIMEOUT_ENABLED },
{ "mousekeys-enable", META_A11Y_MOUSE_KEYS_ENABLED },
{ "slowkeys-enable", META_A11Y_SLOW_KEYS_ENABLED },
{ "slowkeys-beep-press", META_A11Y_SLOW_KEYS_BEEP_PRESS },
{ "slowkeys-beep-accept", META_A11Y_SLOW_KEYS_BEEP_ACCEPT },
{ "slowkeys-beep-reject", META_A11Y_SLOW_KEYS_BEEP_REJECT },
{ "bouncekeys-enable", META_A11Y_BOUNCE_KEYS_ENABLED },
{ "bouncekeys-beep-reject", META_A11Y_BOUNCE_KEYS_BEEP_REJECT },
{ "togglekeys-enable", META_A11Y_TOGGLE_KEYS_ENABLED },
{ "stickykeys-enable", META_A11Y_STICKY_KEYS_ENABLED },
{ "stickykeys-modifier-beep", META_A11Y_STICKY_KEYS_BEEP },
{ "stickykeys-two-key-off", META_A11Y_STICKY_KEYS_TWO_KEY_OFF },
{ "feature-state-change-beep", META_A11Y_FEATURE_STATE_CHANGE_BEEP },
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
};
static void
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
load_keyboard_a11y_settings (MetaInputSettings *input_settings)
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
{
MetaInputSettingsPrivate *priv = meta_input_settings_get_instance_private (input_settings);
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
MetaKbdA11ySettings kbd_a11y_settings = { 0 };
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
guint i;
kbd_a11y_settings.controls = 0;
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
for (i = 0; i < G_N_ELEMENTS (keyboard_a11y_settings_flags_pair); i++)
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
{
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
if (g_settings_get_boolean (priv->keyboard_a11y_settings, keyboard_a11y_settings_flags_pair[i].name))
kbd_a11y_settings.controls |= keyboard_a11y_settings_flags_pair[i].flag;
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
}
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
kbd_a11y_settings.timeout_delay = g_settings_get_int (priv->keyboard_a11y_settings,
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
"disable-timeout");
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
kbd_a11y_settings.slowkeys_delay = g_settings_get_int (priv->keyboard_a11y_settings,
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
"slowkeys-delay");
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
kbd_a11y_settings.debounce_delay = g_settings_get_int (priv->keyboard_a11y_settings,
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
"bouncekeys-delay");
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
kbd_a11y_settings.mousekeys_init_delay = g_settings_get_int (priv->keyboard_a11y_settings,
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
"mousekeys-init-delay");
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
kbd_a11y_settings.mousekeys_max_speed = g_settings_get_int (priv->keyboard_a11y_settings,
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
"mousekeys-max-speed");
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
kbd_a11y_settings.mousekeys_accel_time = g_settings_get_int (priv->keyboard_a11y_settings,
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
"mousekeys-accel-time");
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
priv->kbd_a11y_settings = kbd_a11y_settings;
g_signal_emit (input_settings, signals[KBD_A11Y_CHANGED], 0, &priv->kbd_a11y_settings);
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
}
backends: Make device tracking at MetaInputSettings ad-hoc API Depending on the backend, we want to integrate this object at different levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but it will be put deep down with MetaSeatImpl in the native backend, in a separate thread. Since we can't depend on a single object type, nor are able to track ClutterSeat signals neatly, make this API something to be called explicitly by backends. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 14:27:35 +00:00
void
meta_input_settings_notify_kbd_a11y_change (MetaInputSettings *input_settings,
MetaKeyboardA11yFlags new_flags,
MetaKeyboardA11yFlags what_changed)
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
{
MetaInputSettingsPrivate *priv = meta_input_settings_get_instance_private (input_settings);
guint i;
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
for (i = 0; i < G_N_ELEMENTS (keyboard_a11y_settings_flags_pair); i++)
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
{
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
if (keyboard_a11y_settings_flags_pair[i].flag & what_changed)
g_settings_set_boolean (priv->keyboard_a11y_settings,
keyboard_a11y_settings_flags_pair[i].name,
(new_flags & keyboard_a11y_settings_flags_pair[i].flag) ? TRUE : FALSE);
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
}
}
static void
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
meta_input_keyboard_a11y_settings_changed (GSettings *settings,
const char *key,
gpointer user_data)
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
{
MetaInputSettings *input_settings = META_INPUT_SETTINGS (user_data);
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
load_keyboard_a11y_settings (input_settings);
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
}
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
static GSettings *
lookup_device_settings (ClutterInputDevice *device)
{
const gchar *group, *schema, *vendor, *product;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
ClutterInputCapabilities capabilities;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
GSettings *settings;
gchar *path;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
capabilities = clutter_input_device_get_capabilities (device);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((capabilities &
(CLUTTER_INPUT_CAPABILITY_TABLET_TOOL |
CLUTTER_INPUT_CAPABILITY_TABLET_PAD)) != 0)
{
group = "tablets";
schema = "org.gnome.desktop.peripherals.tablet";
}
else if ((capabilities & CLUTTER_INPUT_CAPABILITY_TOUCH) != 0)
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
{
group = "touchscreens";
schema = "org.gnome.desktop.peripherals.touchscreen";
}
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
else
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
{
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
return NULL;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
}
vendor = clutter_input_device_get_vendor_id (device);
product = clutter_input_device_get_product_id (device);
path = g_strdup_printf ("/org/gnome/desktop/peripherals/%s/%s:%s/",
group, vendor, product);
settings = g_settings_new_with_path (schema, path);
g_free (path);
return settings;
}
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
static GSettings *
backends: Add function to retrieve the action mapped to an stylus button This function will be useful for the wayland implementation, because buttons are mapped at the time of sending those through the wire. As x11/wayland implementations differ here, this function will be useful for the wayland implementation, as the action is handled lat
2016-06-22 13:48:07 +00:00
lookup_tool_settings (ClutterInputDeviceTool *tool,
ClutterInputDevice *device)
{
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
GSettings *tool_settings;
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
guint64 serial;
gchar *path;
backends: Add function to retrieve the action mapped to an stylus button This function will be useful for the wayland implementation, because buttons are mapped at the time of sending those through the wire. As x11/wayland implementations differ here, this function will be useful for the wayland implementation, as the action is handled lat
2016-06-22 13:48:07 +00:00
tool_settings = g_object_get_qdata (G_OBJECT (tool), quark_tool_settings);
if (tool_settings)
return tool_settings;
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
serial = clutter_input_device_tool_get_serial (tool);
input-settings: treat a serial of 1 as serial of 0 The Wacom Xorg driver assigns a serial number of 1 for any pad that doesn't have a serial. libinput assigns 0. Just treat 1 as 0 here, there are no pens with a real serial 1 anyway. Fixes https://gitlab.gnome.org/GNOME/mutter/issues/414
2018-12-17 05:22:44 +00:00
/* The Wacom driver uses serial 1 for serial-less devices but 1 is not a
* real serial, so let's custom-case this */
if (serial == 0 || serial == 1)
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
{
path = g_strdup_printf ("/org/gnome/desktop/peripherals/stylus/default-%s:%s/",
clutter_input_device_get_vendor_id (device),
clutter_input_device_get_product_id (device));
}
else
{
input-settings: Use portable formatting for 64-bit integers On 64-bit systems int64_t is %lx but on 32-bit systems it is %llx. https://gitlab.gnome.org/GNOME/mutter/merge_requests/778
2019-09-06 09:47:13 +00:00
path = g_strdup_printf ("/org/gnome/desktop/peripherals/stylus/%" G_GINT64_MODIFIER "x/",
serial);
Revert "backends: Use g-s-d settings for tablet configuration" This reverts commit b52f304f9db590220555cb3a04a3c31f32ee7f19. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-11 16:58:48 +00:00
}
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
tool_settings =
g_settings_new_with_path ("org.gnome.desktop.peripherals.tablet.stylus",
path);
backends: Add function to retrieve the action mapped to an stylus button This function will be useful for the wayland implementation, because buttons are mapped at the time of sending those through the wire. As x11/wayland implementations differ here, this function will be useful for the wayland implementation, as the action is handled lat
2016-06-22 13:48:07 +00:00
g_object_set_qdata_full (G_OBJECT (tool), quark_tool_settings, tool_settings,
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
(GDestroyNotify) g_object_unref);
backends: Add function to retrieve the action mapped to an stylus button This function will be useful for the wayland implementation, because buttons are mapped at the time of sending those through the wire. As x11/wayland implementations differ here, this function will be useful for the wayland implementation, as the action is handled lat
2016-06-22 13:48:07 +00:00
g_free (path);
return tool_settings;
}
backends: Store mappable devices' info in the hashtable Instead of as closure data. We will need to store (and query) more per-device info, so access to this struct is necessary.
2016-05-13 12:28:52 +00:00
static void
device_mapping_info_free (DeviceMappingInfo *info)
{
cleanup: Use g_clear_signal_handler() where possible This is inspired by 98892391d764d1cf where the usage of `g_signal_handler_disconnect()` without resetting the corresponding handler id later resulted in a bug. Using `g_clear_signal_handler()` makes sure we avoid similar bugs and is almost always the better alternative. We use it for new code, let's clean up the old code to also use it. A further benefit is that it can get called even if the passed id is 0, allowing us to remove a lot of now unnessecary checks, and the fact that `g_clear_signal_handler()` checks for the right type size, forcing us to clean up all places where we used `guint` instead of `gulong`. No functional changes intended here and all changes should be trivial, thus bundled in one big commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
2019-11-16 00:25:52 +00:00
g_clear_signal_handler (&info->changed_id, info->settings);
backends: Store mappable devices' info in the hashtable Instead of as closure data. We will need to store (and query) more per-device info, so access to this struct is necessary.
2016-05-13 12:28:52 +00:00
g_object_unref (info->settings);
backends: Extend pad action label checks to rings/strips This way the pad OSD can obtain the keycombos that are mapped to these for labeling purposes. https://bugzilla.gnome.org/show_bug.cgi?id=782033
2017-07-05 11:35:31 +00:00
g_free (info->group_modes);
src: Stop using GSlice It has been inofficially deprecated for years, is known to cause issues with valgrind and potentially hides memory corruption. Lets stop using it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
2020-10-19 17:57:57 +00:00
g_free (info);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
}
static gboolean
check_add_mappable_device (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsPrivate *priv;
DeviceMappingInfo *info;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
ClutterInputCapabilities capabilities;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
GSettings *settings;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
capabilities = clutter_input_device_get_capabilities (device);
backends: Add envvar to disable wacom configuration People that relied on xsetwacom to configure their tablets used to get away with this by disabling the wacom g-s-d plugin prior to running their scripts. This is not possible anymore with mutter managing device configuration. Given that X11 shall not go away soon and there's a core of stubbornly accustomed users, provide a MUTTER_DISABLE_WACOM_CONFIGURATION envvar to provide *some* way to do this.
2017-10-03 22:42:39 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((capabilities &
(CLUTTER_INPUT_CAPABILITY_TABLET_TOOL |
CLUTTER_INPUT_CAPABILITY_TABLET_PAD)) != 0 &&
backends: Add envvar to disable wacom configuration People that relied on xsetwacom to configure their tablets used to get away with this by disabling the wacom g-s-d plugin prior to running their scripts. This is not possible anymore with mutter managing device configuration. Given that X11 shall not go away soon and there's a core of stubbornly accustomed users, provide a MUTTER_DISABLE_WACOM_CONFIGURATION envvar to provide *some* way to do this.
2017-10-03 22:42:39 +00:00
g_getenv ("MUTTER_DISABLE_WACOM_CONFIGURATION") != NULL)
return FALSE;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
settings = lookup_device_settings (device);
if (!settings)
return FALSE;
priv = meta_input_settings_get_instance_private (input_settings);
src: Stop using GSlice It has been inofficially deprecated for years, is known to cause issues with valgrind and potentially hides memory corruption. Lets stop using it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
2020-10-19 17:57:57 +00:00
info = g_new0 (DeviceMappingInfo, 1);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
info->input_settings = input_settings;
info->device = device;
info->settings = settings;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((capabilities & CLUTTER_INPUT_CAPABILITY_TABLET_PAD) != 0)
backends: Extend pad action label checks to rings/strips This way the pad OSD can obtain the keycombos that are mapped to these for labeling purposes. https://bugzilla.gnome.org/show_bug.cgi?id=782033
2017-07-05 11:35:31 +00:00
{
info->group_modes =
g_new0 (guint, clutter_input_device_get_n_mode_groups (device));
}
backends: Fix dangling callback not being disconnected This fixes possible crashes if configuration is changed on a device that was added and then removed. https://bugzilla.gnome.org/show_bug.cgi?id=784881
2017-07-12 10:24:16 +00:00
info->changed_id = g_signal_connect (settings, "changed",
G_CALLBACK (mapped_device_changed_cb),
info);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
backends: Store mappable devices' info in the hashtable Instead of as closure data. We will need to store (and query) more per-device info, so access to this struct is necessary.
2016-05-13 12:28:52 +00:00
g_hash_table_insert (priv->mappable_devices, device, info);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
backends: Map tablets/pads, and wire to configuration vfuncs With this, the left-handed setting works. The other configuration vfuncs remain empty stubs, but will be correctly applied when those are handled.
2016-05-13 10:17:00 +00:00
apply_mappable_device_settings (input_settings, info);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
return TRUE;
}
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
static void
apply_device_settings (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettings: Initialize the accel-profile setting Shouldn't just update them when they change; they also need to be set when initializing. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-07-29 01:28:18 +00:00
MetaInputSettingsPrivate *priv =
meta_input_settings_get_instance_private (input_settings);
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_device_speed (input_settings, device);
update_device_natural_scroll (input_settings, device);
MetaInputSettings: Don't initialize the same setting twice Two settings were set twice on the same device. Now instead group the generic update functions together, removing the redundant calls. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-07-29 01:26:55 +00:00
update_mouse_left_handed (input_settings, device);
MetaInputSettings: Initialize the accel-profile setting Shouldn't just update them when they change; they also need to be set when initializing. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-07-29 01:28:18 +00:00
update_pointer_accel_profile (input_settings,
priv->mouse_settings,
device);
MetaInputSettings: Don't initialize the same setting twice Two settings were set twice on the same device. Now instead group the generic update functions together, removing the redundant calls. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-07-29 01:26:55 +00:00
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_touchpad_left_handed (input_settings, device);
update_touchpad_tap_enabled (input_settings, device);
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
update_touchpad_tap_button_map (input_settings, device);
Add tag-and-drag setting from libinput into mutter The problem is that libinput offers the possibility to not enabled dragging when tap-to-click is enabled but mutter doesn't. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas. To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click in mutter. Because it's already a specification of libinput, it remains to add it to mutter. Implementation with X11 is added too. https://bugzilla.gnome.org/show_bug.cgi?id=775755
2017-08-17 23:00:10 +00:00
update_touchpad_tap_and_drag_enabled (input_settings, device);
Add tap-button-map and tap-and-drag-lock support to X11 and Wayland https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1319
2020-06-16 14:53:48 +00:00
update_touchpad_tap_and_drag_lock_enabled (input_settings, device);
Implements disable-while-typing in mutter. Disable-while-typing disables the touchpad while the user is typing. This patch introduces the necessary backend code to implement the org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of gsettings-desktop-schemas which was implemented in commit 4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24. This is known as dwt in libinput. This patch has been tested on X11 and Wayland. https://bugzilla.gnome.org/show_bug.cgi?id=764852
2017-05-23 13:38:00 +00:00
update_touchpad_disable_while_typing (input_settings, device);
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_touchpad_send_events (input_settings, device);
backends: Re-add support for edge scrolling with some touchpads Add support for setting edge-scrolling separately from two-finger scrolling. We now have 2 separate boolean settings for those, with the Mouse panel in gnome-control-center allowing to set only one of those at a time, but nothing precludes both being set in the configuration. We need to handle: - two-finger-scrolling-enabled and edge-scrolling-enabled settings both being set. - those 2 settings being change out-of-order - two-finger-scrolling being set on a device that doesn't support it - edge-scrolling-enabled on a device that doesn't support it And the combinations of one touchpad supporting just one of edge scrolling and two-finger scrolling and another vice-versa. https://bugzilla.gnome.org/show_bug.cgi?id=768245
2016-06-30 12:27:23 +00:00
update_touchpad_two_finger_scroll (input_settings, device);
backends: Update two-finger scrolling before edge scrolling As whether edge scrolling is enabled depends on whether two-finger scrolling is disabled, make sure to update two-finger scrolling first. Note that this only fixes the problem on startup. Changing the settings in GSettings directly might cause an inconsistent state, but the main UI for this setting, gnome-control-center, makes sure to update two-finger scrolling before edge scrolling. https://bugzilla.gnome.org/show_bug.cgi?id=769276
2016-08-05 09:58:24 +00:00
update_touchpad_edge_scroll (input_settings, device);
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
update_touchpad_click_method (input_settings, device);
update_trackball_scroll_button (input_settings, device);
MetaInputSettings: Initialize the accel-profile setting Shouldn't just update them when they change; they also need to be set when initializing. https://bugzilla.gnome.org/show_bug.cgi?id=769179
2016-07-29 01:28:18 +00:00
update_pointer_accel_profile (input_settings,
priv->trackball_settings,
device);
input-settings: Wire up middle-emulation This allows emulating middle click via simultaneous left and right click. Fixes #238. https://gitlab.gnome.org/GNOME/mutter/merge_requests/256
2018-10-06 00:06:58 +00:00
update_middle_click_emulation (input_settings, priv->mouse_settings, device);
update_middle_click_emulation (input_settings, priv->touchpad_settings, device);
update_middle_click_emulation (input_settings, priv->trackball_settings, device);
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
}
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
static void
update_stylus_pressure (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ClutterInputDeviceTool *tool)
{
MetaInputSettingsClass *input_settings_class;
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
GSettings *tool_settings;
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
const gint32 *curve;
GVariant *variant;
gsize n_elems;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((clutter_input_device_get_capabilities (device) &
CLUTTER_INPUT_CAPABILITY_TABLET_TOOL) == 0)
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
return;
if (!tool)
return;
tool_settings = lookup_tool_settings (tool, device);
if (clutter_input_device_tool_get_tool_type (tool) ==
CLUTTER_INPUT_DEVICE_TOOL_ERASER)
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
variant = g_settings_get_value (tool_settings, "eraser-pressure-curve");
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
else
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
variant = g_settings_get_value (tool_settings, "pressure-curve");
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
curve = g_variant_get_fixed_array (variant, &n_elems, sizeof (gint32));
if (n_elems != 4)
return;
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
input_settings_class->set_stylus_pressure (input_settings, device, tool, curve);
}
static void
update_stylus_buttonmap (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ClutterInputDeviceTool *tool)
{
MetaInputSettingsClass *input_settings_class;
backends: Add support for Wacom stylus tertiary-button-action The tertiary-button-action (see bug 790028) is a place for g-c-c to store the action which should be performed when a stylus' third button is pressed. Pressing this button is signaled as a BTN_STYLUS3 event from the kernel or X11 button 8. https://bugzilla.gnome.org/show_bug.cgi?id=790033
2017-10-10 15:55:41 +00:00
GDesktopStylusButtonAction primary, secondary, tertiary;
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
GSettings *tool_settings;
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((clutter_input_device_get_capabilities (device) &
CLUTTER_INPUT_CAPABILITY_TABLET_TOOL) == 0)
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
return;
if (!tool)
return;
tool_settings = lookup_tool_settings (tool, device);
backends: Remove ToolSettings struct Its only purpose was caching settings applying to an stylus/tool, this is now handled through ClutterInputDeviceTool evdev specific API, or X device properties, so is not needed anymore. https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-11-01 16:19:13 +00:00
primary = g_settings_get_enum (tool_settings, "button-action");
secondary = g_settings_get_enum (tool_settings, "secondary-button-action");
backends: Add support for Wacom stylus tertiary-button-action The tertiary-button-action (see bug 790028) is a place for g-c-c to store the action which should be performed when a stylus' third button is pressed. Pressing this button is signaled as a BTN_STYLUS3 event from the kernel or X11 button 8. https://bugzilla.gnome.org/show_bug.cgi?id=790033
2017-10-10 15:55:41 +00:00
tertiary = g_settings_get_enum (tool_settings, "tertiary-button-action");
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
input_settings_class = META_INPUT_SETTINGS_GET_CLASS (input_settings);
input_settings_class->set_stylus_button_map (input_settings, device, tool,
backends: Add support for Wacom stylus tertiary-button-action The tertiary-button-action (see bug 790028) is a place for g-c-c to store the action which should be performed when a stylus' third button is pressed. Pressing this button is signaled as a BTN_STYLUS3 event from the kernel or X11 button 8. https://bugzilla.gnome.org/show_bug.cgi?id=790033
2017-10-10 15:55:41 +00:00
primary, secondary, tertiary);
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
}
static void
apply_stylus_settings (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ClutterInputDeviceTool *tool)
{
update_stylus_pressure (input_settings, device, tool);
update_stylus_buttonmap (input_settings, device, tool);
}
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
static void
evaluate_two_finger_scrolling (MetaInputSettings *input_settings,
ClutterInputDevice *device)
{
MetaInputSettingsClass *klass;
MetaInputSettingsPrivate *priv;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
if ((clutter_input_device_get_capabilities (device) &
CLUTTER_INPUT_CAPABILITY_TOUCHPAD) == 0)
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
return;
klass = META_INPUT_SETTINGS_GET_CLASS (input_settings);
priv = meta_input_settings_get_instance_private (input_settings);
if (klass->has_two_finger_scroll (input_settings, device))
g_hash_table_add (priv->two_finger_devices, device);
}
backends: Make device tracking at MetaInputSettings ad-hoc API Depending on the backend, we want to integrate this object at different levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but it will be put deep down with MetaSeatImpl in the native backend, in a separate thread. Since we can't depend on a single object type, nor are able to track ClutterSeat signals neatly, make this API something to be called explicitly by backends. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 14:27:35 +00:00
void
meta_input_settings_add_device (MetaInputSettings *input_settings,
ClutterInputDevice *device)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
MetaInputSettingsPrivate *priv =
meta_input_settings_get_instance_private (input_settings);
clutter/backends: Rename master and slave devices Just because X11/XI uses a particular terminology doesn't mean we have to use the same terms in our own API. The replacement terms are in line with gtk@1c856a208, which seems a better precedent for consistency. Follow-up to commit 17417a82a5. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
2020-08-31 16:47:23 +00:00
if (clutter_input_device_get_device_mode (device) == CLUTTER_INPUT_MODE_LOGICAL)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
return;
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
priv->devices = g_list_prepend (priv->devices, device);
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
evaluate_two_finger_scrolling (input_settings, device);
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
apply_device_settings (input_settings, device);
check_add_mappable_device (input_settings, device);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
backends: Make device tracking at MetaInputSettings ad-hoc API Depending on the backend, we want to integrate this object at different levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but it will be put deep down with MetaSeatImpl in the native backend, in a separate thread. Since we can't depend on a single object type, nor are able to track ClutterSeat signals neatly, make this API something to be called explicitly by backends. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 14:27:35 +00:00
void
meta_input_settings_remove_device (MetaInputSettings *input_settings,
ClutterInputDevice *device)
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
{
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
MetaInputSettingsPrivate *priv;
priv = meta_input_settings_get_instance_private (input_settings);
g_hash_table_remove (priv->mappable_devices, device);
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
g_hash_table_remove (priv->current_tools, device);
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
if (g_hash_table_remove (priv->two_finger_devices, device) &&
g_hash_table_size (priv->two_finger_devices) == 0)
apply_device_settings (input_settings, NULL);
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
priv->devices = g_list_remove (priv->devices, device);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
}
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
static void
current_tool_changed_cb (GSettings *settings,
const char *key,
gpointer user_data)
{
CurrentToolInfo *info = user_data;
apply_stylus_settings (info->input_settings, info->device, info->tool);
}
static CurrentToolInfo *
current_tool_info_new (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ClutterInputDeviceTool *tool)
{
CurrentToolInfo *info;
info = g_new0 (CurrentToolInfo, 1);
info->input_settings = input_settings;
info->device = device;
info->tool = tool;
info->settings = lookup_tool_settings (tool, device);
info->changed_id =
g_signal_connect (info->settings, "changed",
G_CALLBACK (current_tool_changed_cb),
info);
return info;
}
static void
current_tool_info_free (CurrentToolInfo *info)
{
cleanup: Use g_clear_signal_handler() where possible This is inspired by 98892391d764d1cf where the usage of `g_signal_handler_disconnect()` without resetting the corresponding handler id later resulted in a bug. Using `g_clear_signal_handler()` makes sure we avoid similar bugs and is almost always the better alternative. We use it for new code, let's clean up the old code to also use it. A further benefit is that it can get called even if the passed id is 0, allowing us to remove a lot of now unnessecary checks, and the fact that `g_clear_signal_handler()` checks for the right type size, forcing us to clean up all places where we used `guint` instead of `gulong`. No functional changes intended here and all changes should be trivial, thus bundled in one big commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
2019-11-16 00:25:52 +00:00
g_clear_signal_handler (&info->changed_id, info->settings);
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
g_free (info);
}
backends: Make device tracking at MetaInputSettings ad-hoc API Depending on the backend, we want to integrate this object at different levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but it will be put deep down with MetaSeatImpl in the native backend, in a separate thread. Since we can't depend on a single object type, nor are able to track ClutterSeat signals neatly, make this API something to be called explicitly by backends. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 14:27:35 +00:00
void
meta_input_settings_notify_tool_change (MetaInputSettings *input_settings,
ClutterInputDevice *device,
ClutterInputDeviceTool *tool)
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
{
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
MetaInputSettingsPrivate *priv;
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
if (tool)
{
CurrentToolInfo *current_tool;
current_tool = current_tool_info_new (input_settings, device, tool);
g_hash_table_insert (priv->current_tools, device, current_tool);
apply_stylus_settings (input_settings, device, tool);
}
else
{
g_hash_table_remove (priv->current_tools, device);
}
clutter/evdev: Take over stylus configuration Stylus configuration (stylus buttons, pressure) was handled at the very high level, doing the button and pressure translations right before sending these to wayland clients. However, it makes more sense to store these settings into the ClutterInputDeviceTool itself, and have clutter apply the config at the lower level so 1) the settings actually apply desktop-wide, not just in clients and 2) X11 and wayland may share similar configuration paths. The settings are now just applied whenever the tool enters proximity, in reaction to ClutterDeviceManager::tool-changed. This commit moves all handling of these two settings to the clutter level, and removes the wayland-specific paths https://bugzilla.gnome.org/show_bug.cgi?id=773779
2016-10-31 16:43:38 +00:00
}
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
static void
check_mappable_devices (MetaInputSettings *input_settings)
{
MetaInputSettingsPrivate *priv;
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
GList *l;
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
backends: Do not use clutter_seat_list_devices() in MetaInputSettings Make it keep its own list of devices, it's not that far off. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:10:28 +00:00
for (l = priv->devices; l; l = l->next)
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
{
ClutterInputDevice *device = l->data;
clutter/backends: Rename master and slave devices Just because X11/XI uses a particular terminology doesn't mean we have to use the same terms in our own API. The replacement terms are in line with gtk@1c856a208, which seems a better precedent for consistency. Follow-up to commit 17417a82a5. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
2020-08-31 16:47:23 +00:00
if (clutter_input_device_get_device_mode (device) == CLUTTER_INPUT_MODE_LOGICAL)
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
continue;
check_add_mappable_device (input_settings, device);
}
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
static void
meta_input_settings_constructed (GObject *object)
{
MetaInputSettings *input_settings = META_INPUT_SETTINGS (object);
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
GSList *devices, *d;
backends: Update MetaInputSettings to apply settings based on capabilities Since devices may be multiple things now, check all capabilities in order to ensure all aspects of the device are correctly configured. This change does the following observations: - Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad' settings path. The regular pointer settings path is left for all non-touchpads. - Devices that are both a tablet and a touchscreen prefer the tablet relocatable schema. This works for both aspects as the touchscreen schema is a subset of the tablet one. Other than that it's a rather boring, even if verbose search and replace. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
2022-03-08 16:51:40 +00:00
devices = meta_input_settings_get_devices (input_settings,
CLUTTER_INPUT_CAPABILITY_TOUCHPAD,
CLUTTER_INPUT_CAPABILITY_NONE);
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
for (d = devices; d; d = d->next)
evaluate_two_finger_scrolling (input_settings, d->data);
g_slist_free (devices);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
input-settings: Ensure that we always apply the same set of settings This makes the hotplug and coldplug paths the same so that we don't miss out on any setting. https://bugzilla.gnome.org/show_bug.cgi?id=747434
2015-04-14 13:27:47 +00:00
apply_device_settings (input_settings, NULL);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
update_keyboard_repeat (input_settings);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
check_mappable_devices (input_settings);
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
load_keyboard_a11y_settings (input_settings);
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
static void
meta_input_settings_class_init (MetaInputSettingsClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->dispose = meta_input_settings_dispose;
object_class->constructed = meta_input_settings_constructed;
backends: Add function to retrieve the action mapped to an stylus button This function will be useful for the wayland implementation, because buttons are mapped at the time of sending those through the wire. As x11/wayland implementations differ here, this function will be useful for the wayland implementation, as the action is handled lat
2016-06-22 13:48:07 +00:00
quark_tool_settings =
g_quark_from_static_string ("meta-input-settings-tool-settings");
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
signals[KBD_A11Y_CHANGED] =
g_signal_new ("kbd-a11y-changed",
G_TYPE_FROM_CLASS (object_class),
G_SIGNAL_RUN_LAST,
0, NULL, NULL, NULL,
G_TYPE_NONE, 1,
G_TYPE_POINTER);
backends/native: Move MetaInputSettings ownership to MetaSeatImpl Together with keymaps and devices, MetaInputSettings will live in the ninth circle of hell with MetaSeatImpl, forever tied to it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-11 16:33:07 +00:00
backends: Add MetaInputSettings This object internally keeps track of the relevant input configuration, and goes through its vmethods in order to apply the configuration on the backend-specific devices. So far, only mouse/touchpad settings are actually attached to GSettings changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked yet. One caveat is that meta_input_settings_create() may return NULL if the backend does not own the windowing system (wayland nested on X11 being the one case), and thus device settings can't be changed freely. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-10-29 14:30:52 +00:00
}
static void
meta_input_settings_init (MetaInputSettings *settings)
{
MetaInputSettingsPrivate *priv;
priv = meta_input_settings_get_instance_private (settings);
priv->mouse_settings = g_settings_new ("org.gnome.desktop.peripherals.mouse");
g_signal_connect (priv->mouse_settings, "changed",
G_CALLBACK (meta_input_settings_changed_cb), settings);
priv->touchpad_settings = g_settings_new ("org.gnome.desktop.peripherals.touchpad");
g_signal_connect (priv->touchpad_settings, "changed",
G_CALLBACK (meta_input_settings_changed_cb), settings);
priv->trackball_settings = g_settings_new ("org.gnome.desktop.peripherals.trackball");
g_signal_connect (priv->trackball_settings, "changed",
G_CALLBACK (meta_input_settings_changed_cb), settings);
priv->keyboard_settings = g_settings_new ("org.gnome.desktop.peripherals.keyboard");
g_signal_connect (priv->keyboard_settings, "changed",
G_CALLBACK (meta_input_settings_changed_cb), settings);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
backends: Rename keyboard accessibility settings Naming the keyboard accessibility settings `a11y_settings` wrongly assumes there will never be any other type of accessibility settings. Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future confusion. https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
2019-03-05 13:06:59 +00:00
priv->keyboard_a11y_settings = g_settings_new ("org.gnome.desktop.a11y.keyboard");
g_signal_connect (priv->keyboard_a11y_settings, "changed",
G_CALLBACK (meta_input_keyboard_a11y_settings_changed), settings);
backends: configure keyboard accessibility Set the relevant flags and values for keyboard accessibility from gsettings. https://bugzilla.gnome.org/show_bug.cgi?id=788564
2017-10-12 15:49:54 +00:00
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
priv->mappable_devices =
backends: Store mappable devices' info in the hashtable Instead of as closure data. We will need to store (and query) more per-device info, so access to this struct is necessary.
2016-05-13 12:28:52 +00:00
g_hash_table_new_full (NULL, NULL, NULL, (GDestroyNotify) device_mapping_info_free);
input-settings: Handle device-to-output mapping For each device that can be mapped (touchscreens, tablets), the output will be fetched from settings and matched with the currently connected ones. If a match is found, the device matrix will be found out from the output configuration and set on the device. This is also updated both individually for newly connected devices, and collectively on output configuration changes. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:08 +00:00
backends: Monitor changes in active tools' settings So the changes can be instantly applied while the tool is in proximity. Before we would just do it on proximity-in, which doesn't provide a good look&feel while modifying the tool settings in g-c-c. https://gitlab.gnome.org/GNOME/mutter/issues/38 Closes: #38
2018-02-19 15:50:52 +00:00
priv->current_tools =
g_hash_table_new_full (NULL, NULL, NULL, (GDestroyNotify) current_tool_info_free);
MetaInputSettings: allow edge scrolling without 2fg capable devices We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
2017-02-13 13:06:35 +00:00
priv->two_finger_devices = g_hash_table_new (NULL, NULL);
backends: Export function to query the mapped MetaMonitorInfo of a tablet Or NULL if the tablet is mapped to the full desktop size.
2016-06-29 11:50:20 +00:00
}
backends: Move numlock persistence handling here We used to have wayland-specific paths for this in src/wayland, now we have ClutterKeymap that we can rely on in order to do state tracking, and can do this all on src/backend domain. This accomodates the feature in common code, so will work on both Wayland and X11. https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
2019-05-23 15:55:20 +00:00
void
backends: Handle numlock saving/restoring directly in backends Simplify the handling of numlock state, so it can be entirely handled within the input thread. Since the saving/restoring is triggered inside each backend code, there's no need anymore for meta_backend_set_numlock(). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-11-26 22:10:25 +00:00
meta_input_settings_maybe_save_numlock_state (MetaInputSettings *input_settings,
gboolean numlock_state)
backends: Move numlock persistence handling here We used to have wayland-specific paths for this in src/wayland, now we have ClutterKeymap that we can rely on in order to do state tracking, and can do this all on src/backend domain. This accomodates the feature in common code, so will work on both Wayland and X11. https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
2019-05-23 15:55:20 +00:00
{
MetaInputSettingsPrivate *priv;
priv = meta_input_settings_get_instance_private (input_settings);
if (!g_settings_get_boolean (priv->keyboard_settings, "remember-numlock-state"))
return;
if (numlock_state == g_settings_get_boolean (priv->keyboard_settings, "numlock-state"))
return;
g_settings_set_boolean (priv->keyboard_settings, "numlock-state", numlock_state);
}
backends: Handle numlock saving/restoring directly in backends Simplify the handling of numlock state, so it can be entirely handled within the input thread. Since the saving/restoring is triggered inside each backend code, there's no need anymore for meta_backend_set_numlock(). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-11-26 22:10:25 +00:00
gboolean
backends: Move numlock persistence handling here We used to have wayland-specific paths for this in src/wayland, now we have ClutterKeymap that we can rely on in order to do state tracking, and can do this all on src/backend domain. This accomodates the feature in common code, so will work on both Wayland and X11. https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
2019-05-23 15:55:20 +00:00
meta_input_settings_maybe_restore_numlock_state (MetaInputSettings *input_settings)
{
MetaInputSettingsPrivate *priv;
backends: Handle numlock saving/restoring directly in backends Simplify the handling of numlock state, so it can be entirely handled within the input thread. Since the saving/restoring is triggered inside each backend code, there's no need anymore for meta_backend_set_numlock(). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-11-26 22:10:25 +00:00
gboolean numlock_state = FALSE;
backends: Move numlock persistence handling here We used to have wayland-specific paths for this in src/wayland, now we have ClutterKeymap that we can rely on in order to do state tracking, and can do this all on src/backend domain. This accomodates the feature in common code, so will work on both Wayland and X11. https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
2019-05-23 15:55:20 +00:00
priv = meta_input_settings_get_instance_private (input_settings);
backends: Handle numlock saving/restoring directly in backends Simplify the handling of numlock state, so it can be entirely handled within the input thread. Since the saving/restoring is triggered inside each backend code, there's no need anymore for meta_backend_set_numlock(). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-11-26 22:10:25 +00:00
if (g_settings_get_boolean (priv->keyboard_settings, "remember-numlock-state"))
numlock_state = g_settings_get_boolean (priv->keyboard_settings, "numlock-state");
backends: Move numlock persistence handling here We used to have wayland-specific paths for this in src/wayland, now we have ClutterKeymap that we can rely on in order to do state tracking, and can do this all on src/backend domain. This accomodates the feature in common code, so will work on both Wayland and X11. https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
2019-05-23 15:55:20 +00:00
backends: Handle numlock saving/restoring directly in backends Simplify the handling of numlock state, so it can be entirely handled within the input thread. Since the saving/restoring is triggered inside each backend code, there's no need anymore for meta_backend_set_numlock(). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-11-26 22:10:25 +00:00
return numlock_state;
backends: Move numlock persistence handling here We used to have wayland-specific paths for this in src/wayland, now we have ClutterKeymap that we can rely on in order to do state tracking, and can do this all on src/backend domain. This accomodates the feature in common code, so will work on both Wayland and X11. https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
2019-05-23 15:55:20 +00:00
}
backends: Move all output management to MetaInputMapper Delegate on the MetaInputMapper all matching of inputs and outputs, including configuration. Other secondary aspects, like output aspect ratio for tablet letterbox mode, or toggling attached devices with power saving changes, are also moved here. This makes MetaInputSettings independent of MetaMonitorManager, all interaction with it happens indirectly via public API entrypoints. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-04 11:33:37 +00:00
void
meta_input_settings_set_device_matrix (MetaInputSettings *input_settings,
ClutterInputDevice *device,
float matrix[6])
{
g_return_if_fail (META_IS_INPUT_SETTINGS (input_settings));
g_return_if_fail (CLUTTER_IS_INPUT_DEVICE (device));
META_INPUT_SETTINGS_GET_CLASS (input_settings)->set_matrix (input_settings,
device,
matrix);
}
void
meta_input_settings_set_device_enabled (MetaInputSettings *input_settings,
ClutterInputDevice *device,
gboolean enabled)
{
GDesktopDeviceSendEvents mode;
g_return_if_fail (META_IS_INPUT_SETTINGS (input_settings));
g_return_if_fail (CLUTTER_IS_INPUT_DEVICE (device));
mode = enabled ?
G_DESKTOP_DEVICE_SEND_EVENTS_ENABLED :
G_DESKTOP_DEVICE_SEND_EVENTS_DISABLED;
META_INPUT_SETTINGS_GET_CLASS (input_settings)->set_send_events (input_settings,
device,
mode);
}
void
meta_input_settings_set_device_aspect_ratio (MetaInputSettings *input_settings,
ClutterInputDevice *device,
double aspect_ratio)
{
MetaInputSettingsPrivate *priv;
DeviceMappingInfo *info;
g_return_if_fail (META_IS_INPUT_SETTINGS (input_settings));
g_return_if_fail (CLUTTER_IS_INPUT_DEVICE (device));
priv = meta_input_settings_get_instance_private (input_settings);
info = g_hash_table_lookup (priv->mappable_devices, device);
if (!info)
return;
info->aspect_ratio = aspect_ratio;
update_tablet_keep_aspect (input_settings, info->settings, device);
}
backends: Move keyboard a11y into backends And out of Clutter API. This is mainly set via settings, or the windowing itself, so we don't need to leak these details up our own backend. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
2020-08-05 14:40:04 +00:00
void
meta_input_settings_get_kbd_a11y_settings (MetaInputSettings *input_settings,
MetaKbdA11ySettings *a11y_settings)
{
MetaInputSettingsPrivate *priv;
g_return_if_fail (META_IS_INPUT_SETTINGS (input_settings));
priv = meta_input_settings_get_instance_private (input_settings);
*a11y_settings = priv->kbd_a11y_settings;
}
Copy permalink