[BUG] Stylus Use Disables Touch Functionality (+Workaround)

[Jonny999999]

Issue

When initially opening Weylus on my tablet, touch functionality works fine. However, after using the stylus once, touch input stops responding, only the stylus continues to work.

• When testing for received events on the laptop using xev, i no longer see any events when touching the screen after entering that bugged state.
• Toggling uinput off and on temporarily restores touch functionality until the stylus is used again.
• Also see workaround below

Background

I frequently switch between using touch for navigating and the stylus/pen for writing and drawing within Xournal++.

Environment

• Laptop:
  • Model: Lenovo ThinkPad L480
  • OS: Arch Linux 6.6.22-lts
  • Network: Tablet connected to laptop's WiFi hotspot
  • Window Manager: i3 (Xorg)
    Note: Got same Issue when using Desktop-PC with same configuration
• Tablet:
  • Model: Samsung Tab S6 Lite
  • OS: Android 14, Kernel 4.14.190
  • Browser: "Samsung Internet" Version 23.0.1.1 (Default)
    Note: Switched to default browser, because Firefox did not differentiate between stylus and touch.
• Weylus:
  • Version 0.11.4-1 from the AUR
  • In the Web interface i have Mouse, Stylus, Touch and uinput all enabled.

Current Workaround

Opening a second web interface instance seems to resolve the issue temporarily.

Method 1 - Second Tab:

1. On PC:
   • Start Weylus
2. On Tablet:
   • Start the browser
   • Open the Weylus URL (first tab)
   • Open a new tab
   • Open the Weylus URL again (second tab)
   • Close the first tab
   • Now I can freely switch between touch and stylus as I like, and both continue to work.
     Note: This workaround needs to be repeated after restarting Weylus or the browser.

EDIT: Method 2 - Open on Host first:

1. On PC:
   • Start Weylus
   • Start the browser
   • Open the Weylus URL
2. On Tablet:
   • Start the browser
   • Open the Weylus URL
3. On PC:
   • Close browser
4. On Tablet:
   • Now I can freely switch between touch and stylus as I like, and both continue to work.

Bottom line: I stumbled upon a workaround that's doing the job for now, although it's a bit strange.
If anyone knows why this is happening, let me know. Otherwise, maybe the workaround helps someone with a similar problem.

This issue might be related: GitHub Issue #243.

[mzen17]

I also have this bug. The workaround solves the problem well (Samsung S8+ with Arch Linux (i3wm)).

[H-M-H]

Thanks for the report! I believe this has been caused by browsers sending hovering events but no event when the pen is leaving hovering range. Like this weylus believes the pen is still in range and just not moving around, resulting in touch rejection. I have added a workaround, please try if it works for you with the latest build: https://github.com/H-M-H/Weylus/actions/runs/11402145420#artifacts

[Jonny999999]

Thank you so much for looking into this and for continuing the Weylus project!

Version

I just tested the build you linked:
Weylus - 0.11.4 d2cdd2c
https://github.com/H-M-H/Weylus/actions/runs/11402145420#artifacts

Results:

• The issue seems mostly fixed: I can now use touch again after using the pen.
• However, I noticed a minor issue with touch functionality after using the pen:

Issue:

• After hovering or writing with the pen, touch does not work immediately.
• I need to touch and release the screen once.
  On the first touch, I can't move around no matter how long i wait after removing the pen.
• Only after touching a second time touch does work as expected, and I can move around.

I’ve recorded a video demonstrating the issue:
normal-state_additional-tap-necessary_540p.mp4
https://github.com/user-attachments/assets/0cd77ded-6051-48f3-a058-c49249b9fa70

Comparison:

• This behavior does not occur in the "workaround state" I mentioned in my initial post (when opening Weylus in a second tab first).
• In that state, touch works as expected without the need for a second touch.

workaround-state_intended-behaviour_540p.mp4
https://github.com/user-attachments/assets/e46430b3-f34d-497c-a97a-008edbc96f44

Hope this feedback helps!
The issue is much more usable now, and the workaround with the second tab is no longer necessary.
It would be great if this minor issue could be resolved as well, since the second tap with finger is a little unintuitive.
If not, I’m happy to close the issue as is.