Marc-André Lureau <marcandre.lur...@gmail.com> writes: > Hi > > On Mon, Jul 22, 2024 at 3:58 PM Sergio Lopez Pascual <s...@redhat.com> wrote: > >> Marc-André Lureau <marcandre.lur...@gmail.com> writes: >> >> > Hi >> > >> > Adding Sergio in CC, who wrote that code. I don't have means to test it, >> > which also limits my understanding and ability to check this. >> > >> > On Sat, Jul 20, 2024 at 11:58 PM ~katharine_chui < >> katharine_c...@git.sr.ht> >> > wrote: >> > >> >> From: Katharine Chui <kwchu...@connect.ust.hk> >> >> >> >> There seems to be no guarantee as to how GdkEventTouch.sequence >> >> would progress https://docs.gtk.org/gdk3/struct.EventTouch.html >> >> >> >> >> > True, we also abuse the internal implementation which stores low integers >> > in the sequence pointer. >> > >> > In the case of steam gamescope session, touch input would >> >> increment the number every touch, resulting in all touch inputs >> >> after the 10th touch to get dropped >> >> >> >> ... >> >> qemu: warning: Unexpected touch slot number: 10 >= 10 >> >> qemu: warning: Unexpected touch slot number: 11 >= 10 >> >> qemu: warning: Unexpected touch slot number: 12 >= 10 >> >> qemu: warning: Unexpected touch slot number: 13 >= 10 >> >> qemu: warning: Unexpected touch slot number: 14 >= 10 >> >> ... >> >> >> >> Reuse the slots on gtk to avoid that >> >> >> > >> > But doing modulo like this, there is a chance of conflict with already >> used >> > slots. >> > >> > Maybe it's time for a better gtk implementation which would handle a >> proper >> > sequence pointer to slot mapping. >> >> The problem with slots vs. sequences is that, from what I can see, >> there's not way to obtain the slot number from EventTouch, which makes >> me thing we're a little to high in the abstraction layer to emulate >> multi-touch properly. And with GTK4 it seems to be even worse, because >> it tries harder to process gestures on its own (we need them to be >> processed by the guest instead). >> >> Under some compositors, we were lucky enough that indeed slots == >> sequences, so we could actually pass those events as that and have the >> guest process and recognize simple gestures (i.e. pinching) properly. >> >> The "right" solution would be finding a way to operate at a lower level >> than what EventTouch provides us today, but I don't know how feasible is >> that from within the limits of the ui/gtk3.c. >> >> In case that's not possible, the modulo workaround is probably as good >> as we can get. >> > > Can't we map the sequence pointer to a (reusable) counter? So up to > max-slots sequences could be mapped uniquely and we would reject events > that do not fit within max-slots.
A slot is a "contact" in the screen (usually a finger), and should remain the same for the events generated from that contact until it's raised from the screen. That is, for a two-fingers pinch gesture, all the events coming from one finger should have slot == X, and the ones coming from the other finger should slot == Y, where X and Y never change during the gesture. In compositors where slot == sequence, we get exactly this behavior. On compositors where sequence is always increasing, assuming it's kept the same for the duration of a contact, the modulo option can do the trick just fine, as long we don't need to support more than 10 contact points (which seems unlikely to me). Sergio.
