On Wed, Jul 15, 2026 at 06:07:56PM +0200, Hari Mishal wrote:

On Wed, Jul 15, 2026 at 5:50 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

On Wed, Jul 15, 2026 at 04:22:41PM +0200, Hari Mishal wrote:

quoted

nslots is derived from the ABS_MT_SLOT maximum reported by the
virtio device. A device could report a bogus maximum (e.g. -1)
making nslots = 0, which input_mt_init_slots() does not reject;
it returns success without allocating any slot storage, silently
leaving the device registered as multitouch capable with no
backing state.

So let's disable multitouch instead?

So rather than failing the whole probe, just warn and clear
ABS_MT_SLOT from absbit in that case, so the rest of the device
still registers? I took my lead from input_mt_init_slots(), which
has its own internal cap and returns -EINVAL when the device
reports more than 1024 slots.
Shall I modify that case to get the same "warn and disable
multitouch" for consistency, or is a hard failure better there since
it's a different type of bad device data?

I don't really know enough for sure but generally if the device can
kinda work it's better than not working, and adding
a capability to a device that driver can't use should
generally just ignore the capability, not fail probe.

Happy to fix it either way! Just want to confirm before sending V2.

Cheers,
Hari