[Wayland-bugs] [Bug 793062] [Wayland] Crash under gdk_wayland_window_attach_image()
https://bugzilla.gnome.org/show_bug.cgi?id=793062 --- Comment #16 from Martin Stransky --- With the latest patch applied I still see a crash: #6 0x7fcd1de3aaf0 in () at /lib64/libpthread.so.0 #7 0x7fcd1671ee79 in wl_proxy_marshal (proxy=0x0, opcode=2) at src/wayland-client.c:692 #8 0x7fcd1a3f4b79 in wl_surface_damage (wl_surface=0x0, x=0, y=0, width=1185, height=113) at /usr/include/wayland-client-protocol.h:3478 #9 0x7fcd1a3f71b7 in gdk_window_impl_wayland_end_paint (window=0x7fcce96f7950 [GdkWaylandWindow]) at gdkwindow-wayland.c:952 #10 0x7fcd1a3814e5 in gdk_window_end_paint_internal (window=0x7fcce96f7950 [GdkWaylandWindow]) at gdkwindow.c:3021 #11 0x7fcd1a381ca8 in gdk_window_end_draw_frame (window=0x7fcce96f7950 [GdkWaylandWindow], context=0x7fcce00eab80 [GdkDrawingContext]) at gdkwindow.c:3289 #12 0x7fcd1ab20f61 in gtk_widget_render (widget=0x7fcce896fe60 [GtkWindow], window=0x7fcce96f7950 [GdkWaylandWindow], region=0x7fccf5417260) at gtkwidget.c:17522 #13 0x7fcd1a92fbc0 in gtk_main_do_event (event=0x7ffcac200800) at gtkmain.c:1834 #14 0x7fcd1a3678d2 in _gdk_event_emit (event=0x7ffcac200800) at gdkevents.c:73 #15 0x7fcd1a382b78 in _gdk_window_process_updates_recurse_helper (window=0x7fcce96f7950 [GdkWaylandWindow], expose_region=0x7fccf54034e0) at gdkwindow.c:3853 #16 0x7fcd1a382e38 in _gdk_window_process_updates_recurse (window=0x7fcce96f7950 [GdkWaylandWindow], expose_region=0x7fccf54034e0) at gdkwindow.c:3910 #17 0x7fcd1a390bc4 in gdk_window_impl_process_updates_recurse (window=0x7fcce96f7950 [GdkWaylandWindow], region=0x7fccf54034e0) at gdkwindowimpl.c:333 #18 0x7fcd1a3830cc in gdk_window_process_updates_internal (window=0x7fcce96f7950 [GdkWaylandWindow]) at gdkwindow.c:3999 #19 0x7fcd1a38358d in gdk_window_process_updates_with_mode (window=0x7fcce96f7950 [GdkWaylandWindow], recurse_mode=2) at gdkwindow.c:4193 #20 0x7fcd1a38f78d in gdk_window_paint_on_clock (clock=0x7fccc7d2d860 [GdkFrameClockIdle], data=0x7fcce96f7950) at gdkwindow.c:11700 #24 0x7fcd17cd066f in (instance=, signal_id=, detail=) at gsignal.c:3447 #21 0x7fcd17cb473d in g_closure_invoke (closure=0x7fcce0126850, return_value=0x0, n_param_values=1, param_values=0x7ffcac200b60, invocation_hint=0x7ffcac200ae0) at gclosure.c:804 #22 0x7fcd17cc74de in signal_emit_unlocked_R (node=node@entry=0x7fccfd006220, detail=detail@entry=0, instance=instance@entry=0x7fccc7d2d860, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffcac200b60) at gsignal.c:3635 #23 0x7fcd17ccfd05 in g_signal_emit_valist (instance=0x7fccc7d2d860, signal_id=, detail=0, var_args=var_args@entry=0x7ffcac200d30) at gsignal.c:3391 #25 0x7fcd1a3745c8 in _gdk_frame_clock_emit_paint (frame_clock=0x7fccc7d2d860 [GdkFrameClockIdle]) at gdkframeclock.c:640 #26 0x7fcd1a3750ac in gdk_frame_clock_paint_idle (data=0x7fccc7d2d860) at gdkframeclockidle.c:430 it comes from expose event. (gdb) p* window $3 = { parent_instance = { g_type_instance = { g_class = 0x7fcd1cd616b0 }, ref_count = 11, qdata = 0x7fcce02d9780 }, impl = 0x7fcce91d9000 [GdkWindowImplWayland], parent = 0x7fcd1cdbe050 [GdkWaylandWindow], transient_for = 0x7fcce977c5d0 [GdkWaylandWindow], visual = 0x7fcd1cdb6440 [GdkWaylandVisual], user_data = 0x7fcce896fe60, x = 23, y = 88, event_mask = 6553366, window_type = 3 '\003', depth = 32 ' ', resize_count = 0 '\000', toplevel_window_type = -1 '\377', filters = 0x0, children = 0x7fcce96f7b40 = {0x7fcce96f7ae0}, children_list_node = {data=0x7fcce96f7950, next=0x7fcce96f7500, prev=0x0}, native_children = 0x0, background = 0x7fccc8743d40, current_paint = { surface = 0x7fccc7d51980, region = 0x7fccf54172a0, flushed_region = 0x7fccf54172e0, need_blend_region = 0x7fccf54173e0, surface_needs_composite = 0, use_gl = 0 }, gl_paint_context = 0x0, update_area = 0x0, update_freeze_count = 0, active_update_area = 0x7fccea6fcb40, old_updated_area = {0x0, 0x0}, old_state = GDK_WINDOW_STATE_FOCUSED, state = (GDK_WINDOW_STATE_WITHDRAWN | GDK_WINDOW_STATE_FOCUSED), alpha = 255 '\377', fullscreen_mode = 0 '\000', input_only = 0, pass_through = 0, modal_hint = 0, composited = 0, has_alpha_background = 0, destroyed = 0, accept_focus = 1, focus_on_map = 1, shaped = 0, support_multidevice = 0, synthesize_crossing_event_queued = 1, effective_visibility = 3, visibility = 2, native_visibility = 0, viewable = 0, applied_shape = 0, in_update = 1, geometry_dirty = 1, event_compression = 1, frame_clock_events_paused = 0, impl_window = 0x7fcce96f7950 [GdkWaylandWindow], update_and_descendants_freeze_count = 0, abs_x = 0, abs_y = 0, width = 1185, height = 113, shadow_top = 0, shadow_left = 0, shadow_right = 0, shadow_botto
[Wayland-bugs] [Bug 793062] [Wayland] Crash under gdk_wayland_window_attach_image()
https://bugzilla.gnome.org/show_bug.cgi?id=793062 --- Comment #17 from Martin Stransky --- I can 100% reproducible with the firefox-59 build I provide. Navigate to url bar and type "about:addons" there. When awesomebar disappears FF crashes. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 793062] [Wayland] Crash under gdk_wayland_window_attach_image()
https://bugzilla.gnome.org/show_bug.cgi?id=793062 --- Comment #18 from Olivier Fourdan --- (In reply to Martin Stransky from comment #16) > With the latest patch applied I still see a crash: Weird. Can you double-check the version you use is the one with the patch? Reason I ask is because the backtrace in comment #16 shows: #15 _gdk_window_process_updates_recurse_helper at gdkwindow.c line 3853 with: state = (GDK_WINDOW_STATE_WITHDRAWN | GDK_WINDOW_STATE_FOCUSED) However the patch calls the _gdk_event_emit() only if GDK_WINDOW_IS_MAPPED(window). GDK_WINDOW_IS_MAPPED() is defined as: #define GDK_WINDOW_IS_MAPPED(window) (((window)->state & GDK_WINDOW_STATE_WITHDRAWN) == 0) So with the patch applied you cannot get to frame #15 with “state = (GDK_WINDOW_STATE_WITHDRAWN | GDK_WINDOW_STATE_FOCUSED)” (In reply to Martin Stransky from comment #17) > I can 100% reproducible with the firefox-59 build I provide. Navigate to url > bar and type "about:addons" there. When awesomebar disappears FF crashes. Not here, with the patch applied, it works. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 793062] [Wayland] Crash under gdk_wayland_window_attach_image()
https://bugzilla.gnome.org/show_bug.cgi?id=793062 --- Comment #19 from Martin Stransky --- (In reply to Olivier Fourdan from comment #18) > (In reply to Martin Stransky from comment #16) > > With the latest patch applied I still see a crash: > > Weird. Can you double-check the version you use is the one with the patch? Yes, I checked it again. I use my own custom build with the patch, I checked package build log and the patch is applied. It also contains the first patch. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 793062] [Wayland] Crash under gdk_wayland_window_attach_image()
https://bugzilla.gnome.org/show_bug.cgi?id=793062 --- Comment #20 from Olivier Fourdan --- (In reply to Martin Stransky from comment #19) > Yes, I checked it again. I use my own custom build with the patch, I checked > package build log and the patch is applied. It also contains the first patch. First patch should not be needed, only attachment 367922 But if you get to comment 16 with attachment 367922, then this sounds like a multi-thread issue, /something/ changes the Gdkindow state between the test GDK_WINDOW_IS_MAPPED() and the _gdk_event_emit() in frame 15, otherwise I don't see how that's possible. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 793062] [Wayland] Crash under gdk_wayland_window_attach_image()
https://bugzilla.gnome.org/show_bug.cgi?id=793062 --- Comment #21 from Olivier Fourdan --- FWIW, the code in gdk/gdkwindow.c with the patch applied should read as: 3802 static void 3803 _gdk_window_process_updates_recurse_helper (GdkWindow *window, 3804 cairo_region_t *expose_region) 3805 { ... 3835 /* While gtk+ no longer handles exposes on anything but native 3836 window we still have to send them to all windows that have the 3837 event mask set for backwards compat. We also need to send 3838 it to all native windows, even if they don't specify the 3839 expose mask, because they may have non-native children that do. */ 3840 if (GDK_WINDOW_IS_MAPPED(window) && 3841 (gdk_window_has_impl (window) || 3842window->event_mask & GDK_EXPOSURE_MASK)) 3843 { 3844 GdkEvent event; 3845 3846 event.expose.type = GDK_EXPOSE; 3847 event.expose.window = window; /* we already hold a ref */ 3848 event.expose.send_event = FALSE; 3849 event.expose.count = 0; 3850 event.expose.region = clipped_expose_region; 3851 cairo_region_get_extents (clipped_expose_region, &event.expose.area); 3852 3853 _gdk_event_emit (&event); 3854 } 3855 So we should not get to _gdk_event_emit() line 3853 with “state = (GDK_WINDOW_STATE_WITHDRAWN | GDK_WINDOW_STATE_FOCUSED)” because we're within “if (GDK_WINDOW_IS_MAPPED(window) && ...) { }” line 3840 -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105094] Two finger scroll stuck/not happening
https://bugs.freedesktop.org/show_bug.cgi?id=105094 Bug ID: 105094 Summary: Two finger scroll stuck/not happening Product: Wayland Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: libinput Assignee: wayland-bugs@lists.freedesktop.org Reporter: eyen...@gmail.com Created attachment 137358 --> https://bugs.freedesktop.org/attachment.cgi?id=137358&action=edit evemu recording I noticed today that there is a issue with two finger scrolling. "Sometimes" I start to scroll with two fingers and nothing happens. If I then use only one finger (either by lifting one or lifting both and then touching only with one again) I will scroll. The only way to 'unstuck' the scrolling is to click. I am not sure which version introduced this behavior and I wasn't able to playback the recording. Further I'm not sure if this is indeed a bug in libinput or was introduced by the kernel but since the debug output showed what I was experiencing I filed the bug here. debug-events: ... event17 POINTER_MOTION +70.55s -30.54/ 0.00 event17 POINTER_MOTION +70.56s -19.44/ 0.00 event17 POINTER_MOTION +70.58s -6.94/ 0.00 event17 GESTURE_SWIPE_BEGIN +71.06s 3 event17 GESTURE_SWIPE_UPDATE +71.06s 3 0.00/ 1.18 ( 0.00/ 3.58 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.08s 3 -0.21/ 0.80 (-1.41/ 5.37 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.10s 3 0.00/ 2.02 ( 0.00/10.74 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.12s 3 -1.29/11.70 (-3.75/34.00 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.14s 3 0.00/17.89 ( 0.00/48.32 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.16s 3 -1.39/15.90 (-3.75/42.95 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.18s 3 -2.08/11.26 (-5.62/30.42 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.20s 3 -1.39/ 5.96 (-3.75/16.11 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.22s 3 -1.39/ 1.99 (-3.75/ 5.37 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.26s 3 -0.63/ 0.00 (-1.87/ 0.00 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.28s 3 0.00/-22.13 ( 0.00/-66.21 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.30s 3 0.00/-14.58 ( 0.00/-39.37 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.32s 3 0.00/-6.63 ( 0.00/-17.90 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.34s 3 0.00/-2.65 ( 0.00/-7.16 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.36s 3 0.00/-1.33 ( 0.00/-3.58 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.38s 3 0.00/-1.33 ( 0.00/-3.58 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.40s 3 0.00/-0.66 ( 0.00/-1.79 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.42s 3 0.00/-0.66 ( 0.00/-1.79 unaccelerated) event17 GESTURE_SWIPE_END +71.62s 3 cancelled event17 POINTER_AXIS +71.83s vert -20.54* horiz 3.82* (finger) event17 POINTER_AXIS +71.85s vert -27.17* horiz 10.41* (finger) event17 POINTER_AXIS +71.87s vert -24.52* horiz 11.11* (finger) event17 POINTER_AXIS +71.89s vert -15.90* horiz 6.94* (finger) event17 POINTER_AXIS +71.91s vert -5.96* horiz 2.78* (finger) event17 POINTER_AXIS +71.93s vert -1.33* horiz 1.39* (finger) ... -event17 POINTER_BUTTON +75.24s BTN_LEFT (272) pressed, seat count: 1 event17 POINTER_BUTTON +75.34s BTN_LEFT (272) released, seat count: 0 event17 POINTER_MOTION +76.07s0.00/ -1.81 event17 POINTER_MOTION +76.09s0.00/-20.53 event17 POINTER_MOTION +76.11s0.00/-26.51 The POINTER_AXIS motions result in the unwanted scrolling effect and stay until the POINTER_MOTION click happens. I'm on arch linux; libinput 1.9.4-1 libinput-git 1.10.0.r9.g582e3c00 linux 4.15.3-1 linux-ck-haswell 4.14.18-1 linux-ck-haswell 4.14.19-1 udevadm P: /devices/platform/i8042/serio1/input/input14/event17 N: input/event17 S: input/by-path/platform-i8042-serio-1-event-mouse E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse E: DEVNAME=/dev/input/event17 E: DEVPATH=/devices/platform/i8042/serio1/input/input14/event17 E: ID_BUS=i8042 E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=77 E: ID_INPUT_TOUCHPAD=1 E: ID_INPUT_TOUCHPAD_INTEGRATION=internal E: ID_INPUT_WIDTH_MM=101 E: ID_PATH=platform-i8042-serio-1 E: ID_PATH_TAG=platform-i8042-serio-1 E: ID_SERIAL=noserial E: LIBINPUT_DEVICE_GROUP=11/2/7:isa0060/serio1 E: LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1 E: LIBINPUT_MODEL_TOUCHPAD_VISIBLE_MARKER=1 E: MAJOR=13 E: MINOR=81 E: SUBSYSTEM=input E: USEC_INITIALIZED=4970735 -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/ma
[Wayland-bugs] [Bug 105043] 3-fingers touch occasionally fails to get detected
https://bugs.freedesktop.org/show_bug.cgi?id=105043 --- Comment #10 from Hi-Angel --- (In reply to Peter Hutterer from comment #9) > run libinput debug-events --verbose at the same time, that give you more > debugging output and you can tell what tap state a touch is in and what palm > state it is in. if a finger is detected as palm it'll be reflected as such, > and if there's too much movement to cancel the tap, it'll show up as well. Thanks, I managed to get it, though don't really know what to make of that info: Sample from evemu-record | grep BTN_TOOL: E: 29.585448 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 29.625140 0001 0145 # EV_KEY / BTN_TOOL_FINGER 0 E: 29.625140 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 29.769373 0001 014d # EV_KEY / BTN_TOOL_DOUBLETAP 0 Acc. output from libinput debug-events --verbose: event10 - palm: keyboard timeout event10 - pressure: begin touch event10 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event10 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event10 - gesture state: GESTURE_STATE_NONE → GESTURE_STATE_SCROLL event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL -event10 POINTER_AXIS +33.50s vert 2.73* horiz 0.00 (finger) event10 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event10 POINTER_AXIS +33.52s vert 1.46* horiz 0.00 (finger) event10 - pressure: end touch event10 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event10 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event10 POINTER_AXIS +33.57s vert 0.00* horiz 0.00* (finger) -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105043] 3-fingers touch occasionally fails to get detected
https://bugs.freedesktop.org/show_bug.cgi?id=105043 --- Comment #11 from Hi-Angel --- I shall say I noticed that 2-finger tap often sends the same tuple from 1-finger tap and 2-finger tap. It doesn't make any sense except that those who wrote the firmware are asses. Oh, well, at least the problem that events often get skipped by libinput whatsoever can be fixed. -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105103] Wayland master causes Mesa to fail to compile
https://bugs.freedesktop.org/show_bug.cgi?id=105103 Bug ID: 105103 Summary: Wayland master causes Mesa to fail to compile Product: Wayland Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: wayland Assignee: wayland-bugs@lists.freedesktop.org Reporter: bluescreen_aven...@verizon.net I think it might be due to the latest wayland-egl commits... ...but I'm not sure if this is something that Mesa would need to update first... ...or if it's unintentional I get this output: CC drivers/dri2/platform_x11_dri3.lo drivers/dri2/platform_wayland.c: In function ‘dri2_wl_create_window_surface’: drivers/dri2/platform_wayland.c:293:21: error: ‘struct wl_egl_window’ has no member named ‘private’ dri2_surf->wl_win->private = dri2_surf; ^~ drivers/dri2/platform_wayland.c: In function ‘dri2_wl_destroy_surface’: drivers/dri2/platform_wayland.c:379:24: error: ‘struct wl_egl_window’ has no member named ‘private’ dri2_surf->wl_win->private = NULL; ^~ Makefile:1153: recipe for target 'drivers/dri2/platform_wayland.lo' failed make[4]: *** [drivers/dri2/platform_wayland.lo] Error 1 make[4]: *** Waiting for unfinished jobs make[4]: Leaving directory '/srcbuild/mesa/src/egl' Makefile:960: recipe for target 'all' failed make[3]: *** [all] Error 2 make[3]: Leaving directory '/srcbuild/mesa/src/egl' Makefile:863: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/srcbuild/mesa/src' Makefile:654: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/srcbuild/mesa/src' Makefile:667: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 PackageCompileSource finished in 321 seconds -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105104] Cannot set tap button map with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=105104 Bug ID: 105104 Summary: Cannot set tap button map with wayland Product: Wayland Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: libinput Assignee: wayland-bugs@lists.freedesktop.org Reporter: ron.koerner+f...@gmail.com I'd like to change the Tapping Button Map to LMR when using Wayland. Since there is no way to set that via GUI or gsettings, I wrote a little script using python-libinput (https://pypi.python.org/pypi/python-libinput): from libinput import LibInput from libinput.constant import TapButtonMap li=LibInput() device=li.path_add_device('/dev/input/event7') print device.config_tap_get_button_map() print device.config_tap_set_button_map(TapButtonMap.LMR) print device.config_tap_get_button_map() li.path_remove_device(device) It returns this output (when run as root): TapButtonMap.LRM ConfigStatus.SUCCESS TapButtonMap.LMR Unfortunately tapping with two fingers still produces a right click and no middle click. After reading the FAQ multiple times, I have the suspicion that this is not supposed to work and only weston is actually allowed and able to change the configuration. Is that accurate or is something wrong with my approach, python-libinput or libinput itself? -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105104] Cannot set tap button map with wayland
https://bugs.freedesktop.org/show_bug.cgi?id=105104 --- Comment #1 from ron.koerner+f...@gmail.com --- Addition: I'm using libinput 1.8.2-1ubuntu2 on Ubuntu 17.10. -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105043] 3-fingers touch occasionally fails to get detected
https://bugs.freedesktop.org/show_bug.cgi?id=105043 --- Comment #12 from Peter Hutterer --- oops, sorry, I forgot: you need to --enable-tap, it's disabled by default on your device. Could be the fw, could be the HW, could be the protocol. You're on PS2 as well, try passing psmouse.synaptics_intertouch=1 on the kernel boot line in grub and see if that makes a difference (you should see a new device appear, named Synaptics ABCD or so) -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105043] 3-fingers touch occasionally fails to get detected
https://bugs.freedesktop.org/show_bug.cgi?id=105043 --- Comment #13 from Hi-Angel --- (In reply to Peter Hutterer from comment #12) > oops, sorry, I forgot: you need to --enable-tap, it's disabled by default on > your device. Could be the fw, could be the HW, could be the protocol. You're > on PS2 as well, try passing psmouse.synaptics_intertouch=1 on the kernel > boot line in grub and see if that makes a difference (you should see a new > device appear, named Synaptics ABCD or so) Np, I did the record with the option; will try the kernel boot option, but a bit later — I'm travelling, don't have ATM a live-usb/cd to boot from if I screw up something. FWIW these records are done with 2-finger touch, it seems to easier reproduce than the 3-finger touch that ends up looking the same in the evemu-record anyway. Sample from evemu-record | grep BTN_TOOL: E: 22.688289 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 22.717802 0001 0145 # EV_KEY / BTN_TOOL_FINGER 0 E: 22.717802 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 22.810558 0001 014d # EV_KEY / BTN_TOOL_DOUBLETAP 0 Acc. output from libinput debug-events --verbose --enable-tap: event7 - palm: keyboard timeout event7 - pressure: begin touch event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - gesture state: GESTURE_STATE_NONE → GESTURE_STATE_SCROLL -event7 POINTER_AXIS +26.00s vert 24.59* horiz 0.00 (finger) event7 - pressure: end touch event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_RELEASE → TAP_STATE_HOLD event7 - tap state: TAP_STATE_HOLD → TAP_EVENT_RELEASE → TAP_STATE_IDLE event7 POINTER_AXIS +26.03s vert 0.00* horiz 0.00* (finger) This one is interesting — I did a 2-finger tap, and it got correctly shown as such — however I didn't get a popup menu. Sample from evemu-record | grep BTN_TOOL: E: 525.924421 0001 014d 0001# EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 526.042849 0001 014d # EV_KEY / BTN_TOOL_DOUBLETAP 0 Acc. output from libinput debug-events --verbose --enable-tap: event7 - palm: keyboard timeout event7 - pressure: begin touch event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → TAP_STATE_TOUCH_2 event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → TAP_STATE_TOUCH_2_HOLD event7 - gesture state: GESTURE_STATE_NONE → GESTURE_STATE_SCROLL -event7 POINTER_AXIS +543.67s vert 0.00 horiz 6.98* (finger) event7 - pressure: end touch event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_RELEASE → TAP_STATE_HOLD event7 - tap state: TAP_STATE_HOLD → TAP_EVENT_RELEASE → TAP_STATE_IDLE event7 POINTER_AXIS +543.71s vert 0.00* horiz 0.00* (finger) -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 105043] 3-fingers touch occasionally fails to get detected
https://bugs.freedesktop.org/show_bug.cgi?id=105043 --- Comment #14 from Peter Hutterer --- (In reply to Hi-Angel from comment #13) > Np, I did the record with the option; will try the kernel boot option, but a > bit later — I'm travelling, don't have ATM a live-usb/cd to boot from if I > screw up something. add it manually on boot instead of writing into the grub.cfg and the worst thing that can happen is that you don't have a touchpad :) > event7 - tap state: TAP_STATE_IDLE → TAP_EVENT_TOUCH → TAP_STATE_TOUCH > event7 - tap state: TAP_STATE_TOUCH → TAP_EVENT_TOUCH → > TAP_STATE_TOUCH_2 > event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → > TAP_STATE_TOUCH_2_HOLD > event7 - tap state: TAP_STATE_TOUCH_2_HOLD → TAP_EVENT_MOTION → > TAP_STATE_TOUCH_2_HOLD translation: idle to 'one finger down' to 'two fingers down' to 'motion threshold exceeded'. if you have the git repo, there is a touchpad-tap-state-machine.svg that illustrates all this. try not to scream when you see it first ;) > event7 - tap state: TAP_STATE_TOUCH_2 → TAP_EVENT_MOTION → > TAP_STATE_TOUCH_2_HOLD same here - you're getting motion events when the second finger is down, exceeding the internal thresholds and we go from tap to just 'two fingers down'. note that the state machine is independent of everything else, so tapping is in the 'two fingers down' state when e.g. you're two-finger scrolling. The 'button state' debug events are for the software button state, unrelated again. -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs