Hi Benjamin,

quoted

quoted

Some multitouch screens do not like to be polled for input reports.
However, the Win8 spec says that all touches should be sent during
each report, making the initialization of reports unnecessary.
The Win7 spec is less precise, but we can safely assume that when
the module is loaded (at boot), no one is touching the screen.

Add the quirk HID_QUIRK_NO_INIT_REPORTS so that we do not have to
introduce a quirk for each problematic device.

I assume you have tested thoroughly for regressions? How about odd
eGalax devices, for instance? Changes affecting existing hardware
makes me nervous. Is it so bad to add this quirk on a per-device
basis? Or perhaps turned on by default for win8 devices only?

Aargh, I forgot the eGalax... (I don't have it anymore on my desk). I
was pretty confident because Win [7-8] is not doing any quirks for the
multitouch devices, and I had in mind that it did not asked for the
reports at startup (at least, I am sure about it for HID/I2C). I'm not
sure win 8 devices is a sufficient denominator, because this init
sequence is not mentioned anywhere in the Win 8 spec. It's true that
we are going to see fewer Win 7 devices, but I would say it's the
exact same problem for win 7 and 8. Moreover, asking this for Win 8
devices only will forces us to detect it in core before hid-multitouch
is loaded because the init reports is called before the parsing.

We already branch on report specifics in hid_add_device(). Adding win8
detection there is more or less what it was built for.

If I capture the Win 7 & Win 8 initialization events and I observe
that they do not retrieve the reports, will it be sufficient as a
guarantee to include this patch even if it is not widely tested under
Linux?

We already have the usbhid quirks to handle odd cases, and we can add
all sorts of generic detection during device add, so there really is
no reason to risk regressions at all, is there?

Cheers,
Henrik