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.
Signed-off-by: Benjamin Tissoires <[email protected]>
---
drivers/hid/hid-multitouch.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index d99b959..197c2e6 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -957,6 +957,15 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
hdev->quirks |= HID_QUIRK_NO_INPUT_SYNC;
/*
+ * 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.
+ */
+ hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
+
+ /*
* This allows the driver to handle different input sensors
* that emits events through different reports on the same HID
* device.
--
1.8.3.1
Hi Benjamin,
> 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?
>
> Signed-off-by: Benjamin Tissoires <[email protected]>
> ---
> drivers/hid/hid-multitouch.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index d99b959..197c2e6 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -957,6 +957,15 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
> hdev->quirks |= HID_QUIRK_NO_INPUT_SYNC;
>
> /*
> + * 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.
> + */
> + hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
> +
> + /*
> * This allows the driver to handle different input sensors
> * that emits events through different reports on the same HID
> * device.
> --
> 1.8.3.1
>
Thanks,
Henrik
Hi Henrik,
On Thu, Jul 18, 2013 at 9:24 PM, <[email protected]> wrote:
> Hi Benjamin,
>
>> 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.
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?
Cheers,
Benjamin
Hi Benjamin,
> >> 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
Hi Henrik,
On Fri, Jul 19, 2013 at 11:04 PM, <[email protected]> wrote:
> Hi Benjamin,
>
>> >> 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.
right. So I will send a following series to detect win8 multitouch
device in core.
>
>> 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?
Actually, the current quirk is not imitating Windows behavior. Windows
does not retrieve the input reports, but only the feature reports.
This scheme is also useful for us as the feature_mapping() callback
makes use of the ->value, and if we do not retrieve the feature
report, the field is left uninitialized.
I will also add an other quirk to retrieve only the features at init.
>
> 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?
Ok, so let's go for another patch series.. :)
Cheers,
Benjamin