[PATCH libinput] touchpad: use the "is internal keyboard" tag to enable dwt
Signed-off-by: Peter Hutterer
---
src/evdev-mt-touchpad.c | 41 +++
test/test-touchpad.c| 73 ++---
2 files changed, 13 insertions(+), 101 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index e5f2a5ce..eeb1a1b3 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1581,8 +1581,6 @@ static bool
tp_want_dwt(struct evdev_device *touchpad,
struct evdev_device *keyboard)
{
- unsigned int bus_tp = libevdev_get_id_bustype(touchpad->evdev),
-bus_kbd = libevdev_get_id_bustype(keyboard->evdev);
unsigned int vendor_tp = evdev_device_get_id_vendor(touchpad);
unsigned int vendor_kbd = evdev_device_get_id_vendor(keyboard);
unsigned int product_tp = evdev_device_get_id_product(touchpad);
@@ -1592,22 +1590,12 @@ tp_want_dwt(struct evdev_device *touchpad,
considered a happy couple */
if (touchpad->tags & EVDEV_TAG_EXTERNAL_TOUCHPAD)
return vendor_tp == vendor_kbd && product_tp == product_kbd;
+ else if (keyboard->tags & EVDEV_TAG_INTERNAL_KEYBOARD)
+ return true;
- /* If the touchpad is on serio, the keyboard is too, so ignore any
- other devices */
- if (bus_tp == BUS_I8042 && bus_kbd != bus_tp)
- return false;
-
- /* For Apple touchpads, always use its internal keyboard */
- if (vendor_tp == VENDOR_ID_APPLE) {
- return vendor_kbd == vendor_tp &&
- keyboard->tags & EVDEV_TAG_INTERNAL_KEYBOARD;
- }
-
- /* everything else we don't really know, so we have to assume
- they go together */
-
- return true;
+ /* keyboard is not tagged as internal keyboard and it's not part of
+* a combo */
+ return false;
}
static void
@@ -1615,7 +1603,9 @@ tp_dwt_pair_keyboard(struct evdev_device *touchpad,
struct evdev_device *keyboard)
{
struct tp_dispatch *tp = (struct tp_dispatch*)touchpad->dispatch;
- unsigned int bus_kbd = libevdev_get_id_bustype(keyboard->evdev);
+
+ if (tp->dwt.keyboard)
+ return;
if ((keyboard->tags & EVDEV_TAG_KEYBOARD) == 0)
return;
@@ -1623,20 +1613,9 @@ tp_dwt_pair_keyboard(struct evdev_device *touchpad,
if (!tp_want_dwt(touchpad, keyboard))
return;
- /* If we already have a keyboard paired, override it if the new one
-* is a serio device. Otherwise keep the current one */
- if (tp->dwt.keyboard) {
- if (bus_kbd != BUS_I8042)
- return;
-
- memset(tp->dwt.key_mask, 0, sizeof(tp->dwt.key_mask));
- memset(tp->dwt.mod_mask, 0, sizeof(tp->dwt.mod_mask));
-
libinput_device_remove_event_listener(&tp->dwt.keyboard_listener);
- }
-
libinput_device_add_event_listener(&keyboard->base,
- &tp->dwt.keyboard_listener,
- tp_keyboard_event, tp);
+ &tp->dwt.keyboard_listener,
+ tp_keyboard_event, tp);
tp->dwt.keyboard = keyboard;
tp->dwt.keyboard_active = false;
diff --git a/test/test-touchpad.c b/test/test-touchpad.c
index d91c2449..a380bcfd 100644
--- a/test/test-touchpad.c
+++ b/test/test-touchpad.c
@@ -2682,7 +2682,7 @@ START_TEST(touchpad_dwt)
}
END_TEST
-START_TEST(touchpad_dwt_update_keyboard)
+START_TEST(touchpad_dwt_ext_and_int_keyboard)
{
struct litest_device *touchpad = litest_current_device();
struct litest_device *keyboard, *yubikey;
@@ -2730,58 +2730,6 @@ START_TEST(touchpad_dwt_update_keyboard)
}
END_TEST
-START_TEST(touchpad_dwt_update_keyboard_with_state)
-{
- struct litest_device *touchpad = litest_current_device();
- struct litest_device *keyboard, *yubikey;
- struct libinput *li = touchpad->libinput;
-
- if (!has_disable_while_typing(touchpad))
- return;
-
- litest_disable_tap(touchpad->libinput_device);
-
- /* Yubikey is initialized first */
- yubikey = litest_add_device(li, LITEST_YUBIKEY);
- litest_drain_events(li);
-
- litest_keyboard_key(yubikey, KEY_A, true);
- litest_keyboard_key(yubikey, KEY_A, false);
- litest_keyboard_key(yubikey, KEY_A, true);
- litest_assert_only_typed_events(li, LIBINPUT_EVENT_KEYBOARD_KEY);
-
- 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);
-
- litest_keyboard_key(yubikey, KEY_A, false);
- litest_keyboard_key(yubikey, KEY_A, true);
- litest_drain_events(li);
-
- /* yubikey still has A down */
- keyboard = dwt_init_paired_keyboard(li, touchpad);
- litest_drai
Re: [PATCH] Switch graphviz files to use HTML-style labels
I should note that the edges are slightly disconnected in the new X version and more disconnected in the new Wayland version - I have no idea why this is or how to fix it - I have no prior experience with graphviz, but it seems like it's probably a bug of some sort. It would be possible to make the change *only* for the X version, which is the one that is erroring out, but I thought it was better to be consistent than to have two different ways of declaring nodes in the two files. - Owen - Original Message - > > The result is not exactly the same but is quite similar. > > Attaching the new and old results for comparison. Both generated with 2.40 - > the old version of x-architecture.gv gave an unsuccessful return code from > dot but went ahead and produced output with missing edges. > > - Owen > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Switch graphviz files to use HTML-style labels
From: "Owen W. Taylor"
With recent versions of graphviz, generation of the diagrams in the
documentation
fails with:
/usr/bin/dot -Tpng -oxml/x-architecture.png dot/x-architecture.gv
Warning: flat edge between adjacent nodes one of which has a record shape -
replace records with HTML-like labels
Edge xserver -> comp
Error: getsplinepoints: no spline points available for edge (xserver,comp)
Error: lost xserver comp edge
Error: lost xserver comp edge
Error: lost comp xserver edge
Error: lost comp xserver edge
http://www.graphviz.org/content/i-havent-been-able-render-these-files-graphviz-226
indicates
that the error message basically means that the authors of graphviz consider
record-style
labels to be deprecated and are no longer fixing errors with them. This patch
changes
the labels to be in the HTML style, which seems to require duplicating style
between all
the nodes, but it's not like these files are often edited.
The result is not exactly the same but is quite similar.
---
doc/doxygen/dot/wayland-architecture.gv | 13 +
doc/doxygen/dot/x-architecture.gv | 17 -
2 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/doc/doxygen/dot/wayland-architecture.gv
b/doc/doxygen/dot/wayland-architecture.gv
index 2d5db84..f2c3507 100644
--- a/doc/doxygen/dot/wayland-architecture.gv
+++ b/doc/doxygen/dot/wayland-architecture.gv
@@ -9,21 +9,18 @@ digraph arch_wayland {
]
node[
-shape="Mrecord",
color=none,
-fillcolor="#ffbc00",
-style="filled",
+margin=0,
fontname="DejaVu Sans",
fontsize="18",
]
-c1 [label="Wayland Client", URL="#c1"]
-c2 [label="Wayland Client", URL="#c2"]
+c1 [label=, URL="#c1"]
+c2 [label=, URL="#c2"]
-comp [tooltip="Wayland Compositor", label="|{|Wayland\nCompositor|}|",
URL="#comp"]
-
-impl [tooltip="KMS evdev Kernel", label="|{{KMS|evdev}|Kernel}|",
URL="#impl"]
+comp [tooltip="Wayland Compositor", label=,
URL="#comp"]
+impl [tooltip="KMS evdev Kernel", label=, URL="#impl"]
c1 -> comp [taillabel="③", labeldistance=2.5, URL="#step_3"];
c2 -> comp;
diff --git a/doc/doxygen/dot/x-architecture.gv
b/doc/doxygen/dot/x-architecture.gv
index 4ea49bf..b223d1d 100644
--- a/doc/doxygen/dot/x-architecture.gv
+++ b/doc/doxygen/dot/x-architecture.gv
@@ -9,28 +9,27 @@ digraph arch_x {
]
node[
-shape="Mrecord",
+shape="none",
color=none,
-fillcolor="#ffbc00",
-style="filled",
+margin=0,
fontname="DejaVu Sans",
fontsize="18",
]
{
rank=same;
-c1 [label="X Client", URL="#c1"]
-c3 [label="X Client", URL="#c3"]
+c1 [label=, URL="#c1"]
+c3 [label=, URL="#c3"]
}
-c2 [label="X Client", URL="#c2"]
+c2 [label=, URL="#c2"]
{
rank=same;
-xserver [tooltip="X Server", label="|{|X Server|}|", URL="#xserver"]
-comp [tooltip="Compositor", label="|{|Compositor|}|", URL="#comp"]
+xserver [tooltip="X Server", label=,
URL="#xserver"]
+comp [tooltip="Compositor", label=,
URL="#comp"]
}
-impl [tooltip="KMS evdev Kernel", label="|{{KMS|evdev}|Kernel}|",
URL="#impl"]
+impl [tooltip="KMS evdev Kernel", label=, URL="#impl"]
c1 -> xserver [taillabel="③", labeldistance=2, URL="#step_3"];
c2 -> xserver;
--
2.13.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Writing a basic compositor using libweston-desktop
On Fri, Jun 2, 2017 at 1:51 AM, adlo wrote: > How do I write a program that spawns a simple compositor instance on a > nested Wayland window using libweston-desktop and the Wayland-on-Wayland > backend? What are the absolute basics needed to get something on the screen > using libweston-desktop and the nested Wayland-on-Wayland backend? > What about this? Am I on the right lines? What would I need to do to make my compositor appear in a window? struct weston_desktop *desktop; struct wl_display *display; struct weston_compositor *compositor; const struct weston_desktop_api *api; struct weston_layer base; display = wl_display_create (); compositor = weston_compositor_create (display, NULL); weston_layer_init (&base, compositor); weston_layer_set_position (&base, WESTON_LAYER_POSITION_BACKGROUND); desktop = weston_desktop_create (compositor, api, NULL); Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Writing a basic compositor using libweston-desktop
How do I write a program that spawns a simple compositor instance on a nested Wayland window using libweston-desktop and the Wayland-on-Wayland backend? What are the absolute basics needed to get something on the screen using libweston-desktop and the nested Wayland-on-Wayland backend? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libweston versions and tutorials
> On 31 May 2017, at 13:54, Quentin Glidic > wrote: > > One advice I’d have to give is to use libweston-desktop, that abstract a lot > of protocol stuff and just let you manage toplevel surfaces without worrying > about shell protocols, popups and other boring things like that. :-) How do I initialise a simple compositor using libweston-desktop? Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
