[PATCH libinput 1/2] tools: add --disable-sendevents option to the debug-events/debug-gui tools
Makes it possible to debug issues with sendevents.
Signed-off-by: Peter Hutterer
---
tools/libinput-debug-events.man | 3 +++
tools/shared.c | 19 +++
tools/shared.h | 3 +++
3 files changed, 25 insertions(+)
diff --git a/tools/libinput-debug-events.man b/tools/libinput-debug-events.man
index 473e064c..abccfa66 100644
--- a/tools/libinput-debug-events.man
+++ b/tools/libinput-debug-events.man
@@ -44,6 +44,9 @@ The default behavior is equivalent to \-\-udev "seat0".
Use verbose output
.SS libinput configuration options
.TP 8
+.B \-\-disable-sendevents="pattern"
+Set the send-events option to disabled for the devices matching patterns.
+.TP 8
.B \-\-enable\-tap|\-\-disable\-tap
Enable or disable tap-to-click
.TP 8
diff --git a/tools/shared.c b/tools/shared.c
index 8039de9b..ae3287ba 100644
--- a/tools/shared.c
+++ b/tools/shared.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
#include
@@ -208,6 +209,15 @@ tools_parse_option(int option,
else
return 1;
break;
+ case OPT_DISABLE_SENDEVENTS:
+ if (!optarg)
+ return 1;
+
+ snprintf(options->disable_pattern,
+sizeof(options->disable_pattern),
+"%s",
+optarg);
+ break;
}
return 0;
@@ -367,6 +377,15 @@ tools_device_apply_config(struct libinput_device *device,
libinput_device_config_accel_set_profile(device,
options->profile);
}
+
+ if (libinput_device_config_send_events_get_modes(device) &
+ LIBINPUT_CONFIG_SEND_EVENTS_DISABLED &&
+ fnmatch(options->disable_pattern,
+ libinput_device_get_name(device),
+ 0) != FNM_NOMATCH) {
+ libinput_device_config_send_events_set_mode(device,
+
LIBINPUT_CONFIG_SEND_EVENTS_DISABLED);
+ }
}
static char*
diff --git a/tools/shared.h b/tools/shared.h
index ceaa08a9..55e15409 100644
--- a/tools/shared.h
+++ b/tools/shared.h
@@ -49,9 +49,11 @@ enum configuration_options {
OPT_SCROLL_BUTTON,
OPT_SPEED,
OPT_PROFILE,
+ OPT_DISABLE_SENDEVENTS,
};
#define CONFIGURATION_OPTIONS \
+ { "disable-sendevents",required_argument, 0,
OPT_DISABLE_SENDEVENTS }, \
{ "enable-tap",no_argument, 0, OPT_TAP_ENABLE }, \
{ "disable-tap", no_argument, 0, OPT_TAP_DISABLE },
\
{ "enable-drag", no_argument, 0, OPT_DRAG_ENABLE },
\
@@ -92,6 +94,7 @@ struct tools_options {
double speed;
int dwt;
enum libinput_config_accel_profile profile;
+ char disable_pattern[64];
};
void tools_init_options(struct tools_options *options);
--
2.13.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/2] touchpad: don't resume a disabled touchpad
A toucphad that was disabled by toggling the sendevents option would come back
normally after a lid resume, despite still being nominally disabled.
https://bugzilla.redhat.com/show_bug.cgi?id=1448962
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad.c | 44 -
test/test-switch.c | 85 +
2 files changed, 114 insertions(+), 15 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index eb3dde3c..ad034429 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1635,6 +1635,31 @@ tp_resume(struct tp_dispatch *tp, struct evdev_device
*device)
tp_sync_slots(tp, device);
}
+#define NO_EXCLUDED_DEVICE NULL
+static void
+tp_resume_conditional(struct tp_dispatch *tp,
+ struct evdev_device *device,
+ struct evdev_device *excluded_device)
+{
+ if (tp->sendevents.current_mode == LIBINPUT_CONFIG_SEND_EVENTS_DISABLED)
+ return;
+
+ if (tp->sendevents.current_mode ==
+ LIBINPUT_CONFIG_SEND_EVENTS_DISABLED_ON_EXTERNAL_MOUSE) {
+ struct libinput_device *dev;
+
+ list_for_each(dev, &device->base.seat->devices_list, link) {
+ struct evdev_device *d = evdev_device(dev);
+ if (d != excluded_device &&
+ (d->tags & EVDEV_TAG_EXTERNAL_MOUSE)) {
+ return;
+ }
+ }
+ }
+
+ tp_resume(tp, device);
+}
+
static void
tp_trackpoint_timeout(uint64_t now, void *data)
{
@@ -1887,7 +1912,7 @@ tp_switch_event(uint64_t time, struct libinput_event
*event, void *data)
switch (libinput_event_switch_get_switch_state(swev)) {
case LIBINPUT_SWITCH_STATE_OFF:
- tp_resume(tp, tp->device);
+ tp_resume_conditional(tp, tp->device, NO_EXCLUDED_DEVICE);
evdev_log_debug(tp->device, "%s: resume touchpad\n", which);
break;
case LIBINPUT_SWITCH_STATE_ON:
@@ -1971,7 +1996,6 @@ tp_interface_device_removed(struct evdev_device *device,
struct evdev_device *removed_device)
{
struct tp_dispatch *tp = (struct tp_dispatch*)device->dispatch;
- struct libinput_device *dev;
if (removed_device == tp->buttons.trackpoint) {
/* Clear any pending releases for the trackpoint */
@@ -2004,19 +2028,9 @@ tp_interface_device_removed(struct evdev_device *device,
tp->tablet_mode_switch.tablet_mode_switch = NULL;
}
- if (tp->sendevents.current_mode !=
- LIBINPUT_CONFIG_SEND_EVENTS_DISABLED_ON_EXTERNAL_MOUSE)
- return;
-
- list_for_each(dev, &device->base.seat->devices_list, link) {
- struct evdev_device *d = evdev_device(dev);
- if (d != removed_device &&
- (d->tags & EVDEV_TAG_EXTERNAL_MOUSE)) {
- return;
- }
- }
-
- tp_resume(tp, device);
+ /* removed_device is still in the device list at this point, so we
+* need to exclude it from the tp_resume_conditional */
+ tp_resume_conditional(tp, device, removed_device);
}
static inline void
diff --git a/test/test-switch.c b/test/test-switch.c
index 77ba5593..c2b72914 100644
--- a/test/test-switch.c
+++ b/test/test-switch.c
@@ -418,6 +418,89 @@ START_TEST(switch_disable_touchpad_already_open)
}
END_TEST
+START_TEST(switch_dont_resume_disabled_touchpad)
+{
+ struct litest_device *sw = litest_current_device();
+ struct litest_device *touchpad;
+ struct libinput *li = sw->libinput;
+ enum libinput_switch which = _i; /* ranged test */
+
+ if (!libinput_device_switch_has_switch(sw->libinput_device, which))
+ return;
+
+ touchpad = switch_init_paired_touchpad(li);
+ litest_disable_tap(touchpad->libinput_device);
+ libinput_device_config_send_events_set_mode(touchpad->libinput_device,
+
LIBINPUT_CONFIG_SEND_EVENTS_DISABLED);
+ litest_drain_events(li);
+
+ /* switch is on - no events */
+ litest_switch_action(sw, which, LIBINPUT_SWITCH_STATE_ON);
+ litest_assert_only_typed_events(li, LIBINPUT_EVENT_SWITCH_TOGGLE);
+
+ litest_touch_down(touchpad, 0, 50, 50);
+ litest_touch_move_to(touchpad, 0, 50, 50, 70, 50, 10, 1);
+ litest_touch_up(touchpad, 0);
+ litest_assert_empty_queue(li);
+
+ /* switch is off but but tp is still disabled */
+ litest_switch_action(sw, which, LIBINPUT_SWITCH_STATE_OFF);
+ litest_assert_only_typed_events(li, LIBINPUT_EVENT_SWITCH_TOGGLE);
+
+ litest_touch_down(touchpad, 0, 50, 50);
+ litest_touch_move_to(touchpad, 0, 50, 50, 70, 50, 10, 1);
+ litest_touch_up(touchpad, 0);
+ litest_assert_empty_queue(li);
Re: wayland-build-tools build fail for libinput "./wl_build: line 19: ./autogen.sh: No such file or directory"
On Sat, Sep 09, 2017 at 09:10:46AM -0500, michael-wayland-u...@michaelzfreeman.org wrote: > Hi, > > My first post here. I'm in the process of slowly replacing Xorg with > Wayland. I've always been interested in the possibilities of 3D operating > systems and Wayland is a very exciting time for Linux. > > I have tried building Wayland using the "wayland-build-tools" on Github - > https://github.com/wayland-project/wayland-build-tools ... did you pull the latest repo? master branch suggests this has been fixed already https://github.com/wayland-project/wayland-build-tools/commit/6b41d472ddc74867619fe1f0bcf23889ae65af20 Cheers, Peter > > However the build fails when it gets to "libinput" because the project has > changed from using "autogen" to meson and ninja - > https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html > > I am endeavouring to make a fix for this but I'm not familiar with Wayland > and my scripting skills are a bit rusty. I suspect I may be able to build > libinput manually and the script might pick up that its installed at the > dependencies stage. If anyone is familiar with these scripts then any help > would be greatly appreciated. > > Michael Z Freeman > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to support mixed DPI in Xwayland?
On Sun, Sep 10, 2017 at 5:01 PM, Joseph Burt wrote: > Hi Olivier, > > On Thu, Sep 7, 2017 at 6:17 PM, Olivier Fourdan wrote: >> >> The other solution would be to have the same screen, but have Xwayland to >> give different scaling conversions for root window size, screen size, events >> coordinates, etc. depending on the client, if it's HiDPI aware or not, >> some sort of a "hidden" screen. > > I'm not aware of a facility for X clients to advertise DPI awareness > to the X server. What would the heuristic be? Or just user-specified > scaling for a specific X client? > > On scaling: DPI awareness isn't really possible in Wayland at the > moment. The client needs to be told what DPI the compositor would like > it to render, and must be able to acknowledge that. Pretty close to > the current spec would be to have wl_output::scale and buffer_scale > non-integers with an explicitly defined pixel size corresponding with > 1 (96, 72 or 75 DPI, 0.25mm/pixel, whatever), but there are so many > possibilities. Even just the client attaching a differently-sized > buffer than it's surface "size" in such normed pixels would be > acknowledgment enough. > > What's the current state of that conversation? I'm now up to date on the relevant bug reports. Sorry for the spam. What about always running the X server at hardware resolution, limiting the size of lodpi clients on the XWM side, and letting the compositor scale them? Cheers, Joseph ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How to support mixed DPI in Xwayland?
Hi Olivier, On Thu, Sep 7, 2017 at 6:17 PM, Olivier Fourdan wrote: > > The other solution would be to have the same screen, but have Xwayland to > give different scaling conversions for root window size, screen size, events > coordinates, etc. depending on the client, if it's HiDPI aware or not, > some sort of a "hidden" screen. I'm not aware of a facility for X clients to advertise DPI awareness to the X server. What would the heuristic be? Or just user-specified scaling for a specific X client? On scaling: DPI awareness isn't really possible in Wayland at the moment. The client needs to be told what DPI the compositor would like it to render, and must be able to acknowledge that. Pretty close to the current spec would be to have wl_output::scale and buffer_scale non-integers with an explicitly defined pixel size corresponding with 1 (96, 72 or 75 DPI, 0.25mm/pixel, whatever), but there are so many possibilities. Even just the client attaching a differently-sized buffer than it's surface "size" in such normed pixels would be acknowledgment enough. What's the current state of that conversation? Cheers, Joseph ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
