This makes sense because libinput provides (non-negative) int32 ids/slots.

Qt uses qint32

Why and where is this relevant?

Someone "fixed" these warnings a while ago, but you reverted the fix.

This makes sense because libinput provides (non-negative) int32 ids/slots.

Even if it makes sense, the warnings have to be fixed. Comparing signed and unsigned numbers without taking extra measures is bad.

In D23086#510314, @zzag wrote:

Someone "fixed" these warnings a while ago, but you reverted the fix.

I know. I reverted because it broke functionality. So there was no fix.

This makes sense because libinput provides (non-negative) int32 ids/slots.

Even if it makes sense, the warnings have to be fixed. Comparing signed and unsigned numbers without taking extra measures is bad.

"This makes sense" as in this fix here. If libinput would provide uint32 ids it would not make sense.

In D23086#510317, @romangg wrote:

In D23086#510314, @zzag wrote:

Someone "fixed" these warnings a while ago, but you reverted the fix.

I know. I reverted because it broke functionality. So there was no fix.

This makes sense because libinput provides (non-negative) int32 ids/slots.

Even if it makes sense, the warnings have to be fixed. Comparing signed and unsigned numbers without taking extra measures is bad.

"This makes sense" as in this fix here. If libinput would provide uint32 ids it would not make sense.

I though these were Qt touch points, interesting. In any case, I hope this is more complete than just casting in 16e904592ae4fe0a04ef61d42c9a114c62997c8e.
What is the best way to test these? I'll run my desktop with the change. I don't use the touch screen that often though.

In D23086#510331, @gladhorn wrote:

...
I though these were Qt touch points, interesting. In any case, I hope this is more complete than just casting in 16e904592ae4fe0a04ef61d42c9a114c62997c8e.
What is the best way to test these? I'll run my desktop with the change. I don't use the touch screen that often though.

Yea, they come from libinput and should only be relevant in Wayland session. Not sure about the effects stuff though. To test simply try touch input in Wayland session on client content and window decorations (tapping, dragging windows). If everything works as expected there should be no problem. I mean on the other side you can spot pretty easily in the reverted patch what the issue was there: m_touchId is sometimes -1 but gets casted to uint in the comparison.

I played with this after spending some time to get a working wayland session. I could not see any problems, decorations work, the touch point visualization also works.