Single finger tap clicks do not move click position

[sarayourfriend]

Single-finger tap clicks do not move the cursor position when registering the click event. Two and three finger tap clicks work perfectly and do move the cursor/click position.

By "move the cursor" or "click position" I mean that when I middle click (three finger tap), ecode correctly pastes at the position of my pointer. When I right click (two finger tap), ecode opens the context menu at the location of my pointer.

However, for tapped left clicks (single finger tap), ecode appears to register the taps but does not move the cursor position. I know that ecode is registering the taps because if I tap twice quickly (i.e., a double click), ecode will highlight the symbol under the cursor. If I triple tap quickly, it will highlight the whole line under the cursor. The cursor stays put though, ignoring my pointer position.

I'll get a screen capture of this up after submitting the issue first.

Physically clicked left clicks (i.e., I pushed my touchpad down rather than just tapping it) work perfectly.

This affects the entire UI, as far as I can tell, so it might be an eepp GUI issue rather than ecode?

My environment:

• Wayland (wlroots, sway)
• ecode running in xwayland
• Sway input configuration (in case it's relevant):

  input "2362:628:PIXA3854:00_093A:0274_Touchpad" {
      natural_scroll enabled
      tap enabled
      tap_button_map lrm
      click_method clickfinger
      drag disabled
  }
  

libinput debug-events output might reveal the underlying issue, as taps are gesture events unaccompanied by pointer button events, whereas physical clicks have both the gesture and pointer button events:

# Physical single finger click
 event6   GESTURE_HOLD_BEGIN      +5.371s	1
 event6   GESTURE_HOLD_END        +5.444s	1
 event6   POINTER_BUTTON          +5.444s	BTN_LEFT (272) pressed, seat count: 1
 event6   POINTER_BUTTON          +5.639s	BTN_LEFT (272) released, seat count: 0

# Single finger tap
 event6   GESTURE_HOLD_BEGIN      +6.252s	1
 event6   GESTURE_HOLD_END        +6.278s	1

# Physical single finger click
 event6   GESTURE_HOLD_BEGIN      +6.821s	1
 event6   GESTURE_HOLD_END        +6.917s	1
 event6   POINTER_BUTTON          +6.917s	BTN_LEFT (272) pressed, seat count: 1
 event6   POINTER_BUTTON          +7.084s	BTN_LEFT (272) released, seat count: 0

# Physical two finger click
 event6   GESTURE_HOLD_BEGIN      +8.374s	2
 event6   GESTURE_HOLD_END        +8.424s	2
 event6   POINTER_BUTTON          +8.424s	BTN_LEFT (272) pressed, seat count: 1
 event6   POINTER_BUTTON          +8.556s	BTN_LEFT (272) released, seat count: 0

# Two finger tap
 event6   GESTURE_HOLD_BEGIN      +9.170s	2
 event6   GESTURE_HOLD_END        +9.363s	2

# Physical single filter click
 event6   GESTURE_HOLD_BEGIN      +10.337s	1
 event6   GESTURE_HOLD_END        +10.398s	1
 event6   POINTER_BUTTON          +10.398s	BTN_LEFT (272) pressed, seat count: 1
 event6   POINTER_BUTTON          +10.579s	BTN_LEFT (272) released, seat count: 0

wev doesn't see any difference, though and shows that the single finger tap is correctly translated to a button press:

[13:      wl_pointer] button: serial: 20543; time: 5663562; button: 272 (left), state: 1 (pressed)
[13:      wl_pointer] frame
[13:      wl_pointer] button: serial: 20544; time: 5663620; button: 272 (left), state: 0 (released)
[13:      wl_pointer] frame
[13:      wl_pointer] button: serial: 20545; time: 5664419; button: 272 (left), state: 1 (pressed)
[13:      wl_pointer] frame
[13:      wl_pointer] button: serial: 20546; time: 5664530; button: 272 (left), state: 0 (released)
[13:      wl_pointer] frame

It might be an issue with ecode under xwayland. I don't have x11 installed to test this theory, but happy to try it out if you'd like. To avoid doubt, all other applications regardless of wayland or xwayland etc function perfectly with single finger tap as a left click.

[sarayourfriend]

2024-03-29.09-33-52.mp4

I've used only tap-clicks in this recording. You'll see that the context menu opens at the pointer and pastes happen at the pointer, but when I highlight a symbol or line, it happens at the cursor without moving the cursor to the pointer.

[SpartanJ]

Thank you very much for taking the time to explain the issue with such detail. This is the first time I see or get reported something similar and it looks that the problem relies on exactly what you mentioned here:

libinput debug-events output might reveal the underlying issue, as taps are gesture events unaccompanied by pointer button events, whereas physical clicks have both the gesture and pointer button events.

This seems to be the key to the issue, but I'll have to wait a few days to at least try to test it because I won't have the required hardware until next week. I do use ecode with touchpad but mostly on macOS and it works fine, also I have an Linux + X11 installation on other notebook but I've never tried it with Wayland (touchpad on X11 works fine for me too), so I expect this to be related to the Wayland + touchpad combination, since I never used ecode with wayland and touchpad. I'm surprised that it does not generate a click event, IMO this should generate a click, but if that's not the case I guess I can generate the event by detecting the gesture. I'll investigate ASAP. Thank you again.

[sarayourfriend]

Thank you! ecode looks very cool and from the small poking around I did, I'm looking very much forward to trying it out more once my touchpad works 😀 If you need any help testing once you've got changes staged, let me know, happy to help.

[SpartanJ]

I just remembered that eepp GUI already had a patch for this exact same issue, but the fix is only being applied to macOS builds because I didn't have any hardware and software to test it on other operating systems, so I think this confirms that the patch it's also needed at least in Linux too. I'll try to create a build in a few days for you so you can test it and confirm if it works.

[SpartanJ]

@sarayourfriend could you test the following build, please?
ecode-linux-0.5.2-preview-x86_64.zip

[sarayourfriend]

Works perfectly 🚀

[SpartanJ]

Awesome!!