[v12] Touch freezing

[Martin12350]

Describe the bug

When touching buttons a few times or multiple of them at one time, one core of the CPU rises to 100%, and touch input no longer reacts. Sometimes it is even visible that the button stays visually like half touched. The application is still working, that means labels changing text, and all works, but the touch no longer reacts (on anything). Seems like a deadlock. Restarting the application fixes the issue, but it can freeze again. Also, during the freeze, checking evtest, the touchscreen is normally working, so it is not a kernel/driver issue.

I tried to use DRM and FbDev, I also tried to use EvDev instead of LibInput. All doing the same.
When changing to v11.3.13, all works without any issue. Updating to v12.0.0 introduces this issue.

I tried to compile v12 with LinuxFrameBuffer from v11, but the result is the same. I suspect some fundamental issue in Avalonia. But maybe I did something wrong during this test.

To Reproduce

Create a simple Avalonia template.
Change the views based on the Running Avalonia on a Raspberry Pi tutorial to support LinuxFrameBuffer.
Add 2 buttons on the view.
Press the first button fast, and it will freeze.
If you try to press both buttons at the same time fast, it will freeze even faster.
Notice the app itself is alive, just the touch no longer reacts.

Expected behavior

Same as in v11.3.13 - no freezing.

Avalonia version

12.0.0

OS

Linux

Additional context

No response

[lui62233]

Hey — ran through this with the recent commit history and I think I can narrow it down.

What the commit history tells us

v11 → v12 saw a significant set of touch improvements land in #20848. The changes touched pointer event routing, button press detection, and PointerPressed/PointerReleased handling across several controls. One of the things that changed is how TextBox and Button handle concurrent pointer events — the touch path got a more aggressive debounce/gesture recognition pass.

The fact that you can trigger it faster with two buttons pressed simultaneously screams re-entrancy or duplicate event dispatch rather than a deadlock in the traditional sense. The app is alive (labels still update), so the UI thread is not fully frozen — it's spinning on something.

Most likely culprit

When two PointerPressed events arrive in quick succession (which is normal on rapid touch), the button's internal state machine can end up with two "pressed" references that don't properly cancel each other. This leaves the visual in a mid-pressed state and causes the input layer to block further PointerPressed events on that control because it thinks the button is already being held.

The reason evtest still shows events is that the kernel input layer and the evdev/LibInput side are fine — the stall is in Avalonia's managed input queue after the events have already been consumed.

Reproducing cleanly

You can isolate this without a full Raspberry Pi setup: any embedded Linux target (or even a Linux VM with a touch simulator) that exercises the LinuxFrameBuffer path will hit this. The DRM/FbDev vs EvDev/LibInput choice shouldn't matter since both go through the same Pointer event pipeline.

A few things worth checking

1. Does it also reproduce with mouse clicks (rapid double-click on a button)? If so, it's definitely the pointer event routing and not the touch driver.
2. If you add logging and watch for PointerPressed vs PointerReleased counts on the affected button, you should see an imbalance — Pressed firing twice before the first Released ever fires.
3. The v12 touch improvements also added touch-specific text selection handling. If you disable text selection entirely (IsHitTestVisible="False" on TextBox children), does the freeze still happen?

The likely fix

Look at Button (or the Select control that's handling the button) in the v12 changes from #20848. The fix is usually to guard the press handler with a "already processing this pointer" flag that clears on PointerReleased or a timeout. Something like:

private int _processingPointerId = -1;
private void OnPointerPressed(object sender, PointerPressedEventArgs e)
{
    if (_processingPointerId != -1) return; // already handling a press
    _processingPointerId = e.Pointer.Id;
    // ... normal handling
}
private void OnPointerReleased(object sender, PointerReleasedEventArgs e)
{
    if (e.Pointer.Id == _processingPointerId)
        _processingPointerId = -1;
}

If you confirm the double-fire with logging, I'd be happy to dig into the specific Button-related changes from that PR and find the exact race condition.

[lui62233]

Hey — looked at this more carefully and I think I can narrow it down to a specific area.

Likely culprit: gesture recognition / pointer routing changes in the v12 touch path

v11 → v12 saw significant changes to pointer event routing and button press detection, especially around the gesture recognition introduced in #20848. The touch freeze you're describing (app alive, touch events blocked on input layer but not other interactions) strongly suggests a deadlock in the input dispatch thread rather than a crash in the main loop.

Things I'd check:

1. Gesture recognizer state machine — if rapid button presses are triggering a state transition that the recognizer can't exit (e.g., waiting for a pointer-up that never arrives because the touch input thread is blocked), that would explain why the app continues running but touch is deadlocked. The fact that evtest still shows kernel-level events means the freeze is above the input driver layer.

2. Thread affinity for touch events — if the v12 changes moved touch event handling onto a different dispatch queue (e.g., a UI thread vs the main thread), and there's a lock order inversion between that queue and whatever the button click handler uses, that would reproduce your exact symptoms.

3. FbDev/LibInput interaction — you mentioned trying both. The regression appearing in v12 but not v11 suggests the issue isn't in the low-level input driver layer but in how the mid-layer routes events. If you can, try running with AVALONIA_INPUT_DEBUG=1 or whatever the equivalent flag is — if one exists — to see which queue the touch events are landing on when the freeze occurs.

Would you like me to dig into the #20848 changes specifically to trace the gesture state machine logic?

[timunie]

Could you try current nightly build or current master? Issue may be resolved with a recent PR

[Martin12350]

I did not expect such a fast response and possible fix. I definitely will take a look at it tomorrow and let you know.
If there will be issues, I will try all your suggestions.
Before I get hands on the HW, here are some other notes I found (trying to debug it further before).

I tried to check the behavior on Windows with mouse clicking and did not manage to freeze it.

I added in App the InputElement.PointerPressedEvent.AddClassHandler, PointerReleasedEvent and PointerCaptureLostEvent with simple Console.WriteLine log.
You are right that in v11 we can match pressed and release events, but in the case of v12, when it freezes, there are missing release events, and new ones are not coming (not even pressed or lost).

IsHitTestVisible property I did not try, but I can.

What also froze was when I tried to "move" with touch over the image.
I also managed to freeze it with the slider.
I think that each move also fires a lot of events, potentially doing the same as spamming a button.

Will definitely try the debug argument.
I forced the different input by manually adding IInputBackend.
Until I found there is already an argument for it, AVALONIA_USE_EVDEV=1.
FbDev/DRM I change simply by argument flag that changes the branch and use either StartLinuxFbDev or StartLinuxDrm.

[Martin12350]

Awesome. 12.1.999-cibuild0064730-alpha solved the issue. For the test, I tried the version before to eliminate some other changes, but 64728 still freezing. Closing as solved, thanks a lot.

Out of curiosity, when to expect an official/stable release with this fix? :)
V12.0.1 is already out and working. One more time, thanks guys.