The below patch fixes a bug 64811
(https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
Surface Type/Touch cover 2 devices being detected as a multitouch
device.
The fix adds the HID of the two devices to hid-microsoft driver. This
ensures that hid-input will eventually be used for the device and not
hid-multitouch.
>From 866c814f3f6740a5a79858fdf8bf5bbcdc3b57f8 Mon Sep 17 00:00:00 2001
From: Reyad Attiyat <[email protected]>
Date: Mon, 20 Jan 2014 16:24:49 -0600
Subject: [PATCH 1/2] Added in ID's for Surface Type/Touch cover 2 to the
hid-microsoft driver
---
drivers/hid/hid-ids.h | 4 +++-
drivers/hid/hid-microsoft.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..b523a8b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -611,7 +611,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
-
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 551795b..2599de8 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
+ .driver_data = 0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = 0 },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
--
1.8.4.2
On Mon, 20 Jan 2014, Reyad Attiyat wrote:
> The below patch fixes a bug 64811
> (https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
> Surface Type/Touch cover 2 devices being detected as a multitouch
> device.
> The fix adds the HID of the two devices to hid-microsoft driver. This
> ensures that hid-input will eventually be used for the device and not
> hid-multitouch.
Hi,
your patch is missing hid_have_special_driver[] entry, therefore correct
driver binding is not guaranteed.
--
Jiri Kosina
SUSE Labs
On Tue, Jan 21, 2014 at 12:47 AM, Jiri Kosina <[email protected]> wrote:
> On Mon, 20 Jan 2014, Reyad Attiyat wrote:
>
>> The below patch fixes a bug 64811
>> (https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
>> Surface Type/Touch cover 2 devices being detected as a multitouch
>> device.
>> The fix adds the HID of the two devices to hid-microsoft driver. This
>> ensures that hid-input will eventually be used for the device and not
>> hid-multitouch.
>
> Hi,
>
> your patch is missing hid_have_special_driver[] entry, therefore correct
> driver binding is not guaranteed.
>
> --
> Jiri Kosina
> SUSE Labs
>
Hi,
Thanks for reminding me of hid_have_special_driver[]. I noticed that
this device has the HID_DG_CONTACTID and in the comment of the
hid_have_sepcial_driver[]
* Please note that for multitouch devices (driven by hid-multitouch driver),
* there is a proper autodetection and autoloading in place (based on presence
* of HID_DG_CONTACTID), so those devices don't need to be added to this list,
* as we are doing the right thing in hid_scan_usage().
This device should not be driven by hid-multitouch as it does not
handle keyboard/mouse input devices.
I submitted a new patch below with it added. I believe it should still
be part of this array, in case this kind of implementation is
fixed/updated.
>From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
From: Reyad Attiyat <[email protected]>
Date: Tue, 21 Jan 2014 01:22:25 -0600
Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
This is to fix bug 64811 where this device is detected as a multitouch device
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 4 +++-
drivers/hid/hid-microsoft.c | 4 ++++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 253fe23..88eb4a6 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1778,6 +1778,9 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TOUCH_COVER_2) },
+
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..b523a8b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -611,7 +611,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
-
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 551795b..2599de8 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
+ .driver_data = 0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = 0 },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
--
1.8.4.2
Hi Reyad,
On Tue, Jan 21, 2014 at 2:33 AM, Reyad Attiyat <[email protected]> wrote:
> On Tue, Jan 21, 2014 at 12:47 AM, Jiri Kosina <[email protected]> wrote:
>> On Mon, 20 Jan 2014, Reyad Attiyat wrote:
>>
>>> The below patch fixes a bug 64811
>>> (https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
>>> Surface Type/Touch cover 2 devices being detected as a multitouch
>>> device.
>>> The fix adds the HID of the two devices to hid-microsoft driver. This
>>> ensures that hid-input will eventually be used for the device and not
>>> hid-multitouch.
>>
>> Hi,
>>
>> your patch is missing hid_have_special_driver[] entry, therefore correct
>> driver binding is not guaranteed.
>>
>> --
>> Jiri Kosina
>> SUSE Labs
>>
>
> Hi,
>
> Thanks for reminding me of hid_have_special_driver[]. I noticed that
> this device has the HID_DG_CONTACTID and in the comment of the
> hid_have_sepcial_driver[]
>
> * Please note that for multitouch devices (driven by hid-multitouch driver),
> * there is a proper autodetection and autoloading in place (based on presence
> * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
> * as we are doing the right thing in hid_scan_usage().
>
> This device should not be driven by hid-multitouch as it does not
> handle keyboard/mouse input devices.
> I submitted a new patch below with it added. I believe it should still
> be part of this array, in case this kind of implementation is
> fixed/updated.
This implementation is perfectly fine (I am referring to the "fixed/updated"):
- if your device should be driven by hid-multitouch, then you _don't_
add it to hid_have_special_driver
- if your device should not be driven by hid-multitouch, then you
_need_ to add it to hid_have_special_driver.
Adding the device to hid_have_special_driver prevents the detection of
the group HID_GRP_MULTITOUCH, so you will not end with a race between
hid-multitouch and your special hid driver.
>
> From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
> From: Reyad Attiyat <[email protected]>
> Date: Tue, 21 Jan 2014 01:22:25 -0600
> Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
> This is to fix bug 64811 where this device is detected as a multitouch device
>
You are missing a commit message here (the first message you sent
would fit perfectly here).
Other than that, I played a little with the report descriptor pointed
in the bugzilla.
I think I will be able to handle this touch cover in hid-multitouch,
but that would require more testings/debugging. Microsoft seems to
have implemented an indirect (dual) touchpad here, but until we know
which mode we should put it into, it's going to be tricky to set it up
correctly.
One last thing, in the bugzilla, in the comment 2 you say: "I still
have issues with the type cover 2 even with this fix". Are you still
experiencing those disconnection? If so, maybe we should switch to
hid-multitouch at some point.
So to sum up, with the commit message amended:
Reviewed-by: Benjamin Tissoires <[email protected]>
Cheers,
Benjamin
> ---
> drivers/hid/hid-core.c | 3 +++
> drivers/hid/hid-ids.h | 4 +++-
> drivers/hid/hid-microsoft.c | 4 ++++
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 253fe23..88eb4a6 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1778,6 +1778,9 @@ static const struct hid_device_id
> hid_have_special_driver[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_PRESENTER_8K_USB) },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_TOUCH_COVER_2) },
> +
> { HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
> { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) },
> { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
> USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index f9304cb..b523a8b 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -611,7 +611,9 @@
> #define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
> #define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
> #define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
> -
> +#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
> +#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
> +
> #define USB_VENDOR_ID_MOJO 0x8282
> #define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
>
> diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
> index 551795b..2599de8 100644
> --- a/drivers/hid/hid-microsoft.c
> +++ b/drivers/hid/hid-microsoft.c
> @@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
> .driver_data = MS_NOGET },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
> .driver_data = MS_DUPLICATE_USAGES },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
> + .driver_data = 0 },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
> + .driver_data = 0 },
>
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_PRESENTER_8K_BT),
> .driver_data = MS_PRESENTER },
> --
> 1.8.4.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Benjamin,
>>
>> Hi,
>>
>> Thanks for reminding me of hid_have_special_driver[]. I noticed that
>> this device has the HID_DG_CONTACTID and in the comment of the
>> hid_have_sepcial_driver[]
>>
>> * Please note that for multitouch devices (driven by hid-multitouch driver),
>> * there is a proper autodetection and autoloading in place (based on presence
>> * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
>> * as we are doing the right thing in hid_scan_usage().
>>
>> This device should not be driven by hid-multitouch as it does not
>> handle keyboard/mouse input devices.
>> I submitted a new patch below with it added. I believe it should still
>> be part of this array, in case this kind of implementation is
>> fixed/updated.
>
> This implementation is perfectly fine (I am referring to the "fixed/updated"):
> - if your device should be driven by hid-multitouch, then you _don't_
> add it to hid_have_special_driver
> - if your device should not be driven by hid-multitouch, then you
> _need_ to add it to hid_have_special_driver.
>
> Adding the device to hid_have_special_driver prevents the detection of
> the group HID_GRP_MULTITOUCH, so you will not end with a race between
> hid-multitouch and your special hid driver.
>
Thanks for clearing that up. I understand the proper use of this array
now, under this circumstance and am glad to know that there will be no
race when added.
>>
>> From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
>> From: Reyad Attiyat <[email protected]>
>> Date: Tue, 21 Jan 2014 01:22:25 -0600
>> Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
>> This is to fix bug 64811 where this device is detected as a multitouch device
>>
>
> You are missing a commit message here (the first message you sent
> would fit perfectly here).
>
Sorry about that, I'm new to submitting patches to these mailing lists.
> Other than that, I played a little with the report descriptor pointed
> in the bugzilla.
>
> I think I will be able to handle this touch cover in hid-multitouch,
> but that would require more testings/debugging. Microsoft seems to
> have implemented an indirect (dual) touchpad here, but until we know
> which mode we should put it into, it's going to be tricky to set it up
> correctly.
>
> One last thing, in the bugzilla, in the comment 2 you say: "I still
> have issues with the type cover 2 even with this fix". Are you still
> experiencing those disconnection? If so, maybe we should switch to
> hid-multitouch at some point.
>
I tried some patches that I think you posted to hid-input about hid-multitouch.
The patches added in support for function callbacks to allow for a
generic protocol.
This worked after I changed mt_input_mapping() to set the protocol to
mt_protocol_generic
851 * such as Mouse that might have the same GenericDesktop usages. */
852 if (field->application != HID_DG_TOUCHSCREEN &&
853 field->application != HID_DG_PEN &&
854 field->application != HID_DG_TOUCHPAD)
855 td->protocols[report_id] = mt_protocol_generic;
I still experience the disconnects with both of these solutions. Do
you have any idea what could cause this?
It seems to happen when I'm typing fast or holding a key. I'm guessing
the only way to fix this properly is
to snoop USB packets in Windows to see how the device is handled there.
Another bug is the device stays on, lit, in standby mode.
What do you think is the best solution to take? By that I mean should
I keep the patch as part of hid-microsoft?
On Tue, 21 Jan 2014, Benjamin Tissoires wrote:
> > From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
> > From: Reyad Attiyat <[email protected]>
> > Date: Tue, 21 Jan 2014 01:22:25 -0600
> > Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
> > This is to fix bug 64811 where this device is detected as a multitouch device
> >
>
> You are missing a commit message here (the first message you sent
> would fit perfectly here).
Also it's missing a Signed-off-by: line and Reyad's mail client damaged
the patch by line-wrapping.
> So to sum up, with the commit message amended:
> Reviewed-by: Benjamin Tissoires <[email protected]>
Reyad, please do a full resubmission with
- proper changelog
- Signed-off-by: line added
- Benjamin's Reviewed-by: line added
- your mail client fixed so that it doesn't damage the patch
I'll then queue the patch in my tree.
Thanks,
--
Jiri Kosina
SUSE Labs
Hi Reyad,
On Wed, Jan 22, 2014 at 12:05 AM, Reyad Attiyat <[email protected]> wrote:
> Hello Benjamin,
>
>>>
>>> Hi,
>>>
>>> Thanks for reminding me of hid_have_special_driver[]. I noticed that
>>> this device has the HID_DG_CONTACTID and in the comment of the
>>> hid_have_sepcial_driver[]
>>>
>>> * Please note that for multitouch devices (driven by hid-multitouch driver),
>>> * there is a proper autodetection and autoloading in place (based on presence
>>> * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
>>> * as we are doing the right thing in hid_scan_usage().
>>>
>>> This device should not be driven by hid-multitouch as it does not
>>> handle keyboard/mouse input devices.
>>> I submitted a new patch below with it added. I believe it should still
>>> be part of this array, in case this kind of implementation is
>>> fixed/updated.
>>
>> This implementation is perfectly fine (I am referring to the "fixed/updated"):
>> - if your device should be driven by hid-multitouch, then you _don't_
>> add it to hid_have_special_driver
>> - if your device should not be driven by hid-multitouch, then you
>> _need_ to add it to hid_have_special_driver.
>>
>> Adding the device to hid_have_special_driver prevents the detection of
>> the group HID_GRP_MULTITOUCH, so you will not end with a race between
>> hid-multitouch and your special hid driver.
>>
>
> Thanks for clearing that up. I understand the proper use of this array
> now, under this circumstance and am glad to know that there will be no
> race when added.
>
>>>
>>> From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
>>> From: Reyad Attiyat <[email protected]>
>>> Date: Tue, 21 Jan 2014 01:22:25 -0600
>>> Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
>>> This is to fix bug 64811 where this device is detected as a multitouch device
>>>
>>
>> You are missing a commit message here (the first message you sent
>> would fit perfectly here).
>>
>
> Sorry about that, I'm new to submitting patches to these mailing lists.
>
>> Other than that, I played a little with the report descriptor pointed
>> in the bugzilla.
>>
>> I think I will be able to handle this touch cover in hid-multitouch,
>> but that would require more testings/debugging. Microsoft seems to
>> have implemented an indirect (dual) touchpad here, but until we know
>> which mode we should put it into, it's going to be tricky to set it up
>> correctly.
>>
>> One last thing, in the bugzilla, in the comment 2 you say: "I still
>> have issues with the type cover 2 even with this fix". Are you still
>> experiencing those disconnection? If so, maybe we should switch to
>> hid-multitouch at some point.
>>
> I tried some patches that I think you posted to hid-input about hid-multitouch.
> The patches added in support for function callbacks to allow for a
> generic protocol.
> This worked after I changed mt_input_mapping() to set the protocol to
> mt_protocol_generic
>
> 851 * such as Mouse that might have the same GenericDesktop usages. */
> 852 if (field->application != HID_DG_TOUCHSCREEN &&
> 853 field->application != HID_DG_PEN &&
> 854 field->application != HID_DG_TOUCHPAD)
> 855 td->protocols[report_id] = mt_protocol_generic;
yep, I was referring to this patch series. Thanks for testing :)
>
> I still experience the disconnects with both of these solutions. Do
> you have any idea what could cause this?
Well, my first thought may be a mechanical issue (don't know if the
cover is still using magnets).
As for the software/firmware issue, I can think of two possibilities right now:
- the device expects us to empty its whole data queues, and we don't.
So after some time, it resets itself. I remember on the bug report of
having seen several USB devices, so maybe one of them is ignored and
it does not like it
- firmware issue: the device has been properly tested/certified in a
specific mode (the feature INPUT_MODE shows a maximal of 10,
multitouch devices generally have only 2 modes, not 10). So if we are
not in the same mode it is under Windows, then we are screwed.
> It seems to happen when I'm typing fast or holding a key. I'm guessing
> the only way to fix this properly is
> to snoop USB packets in Windows to see how the device is handled there.
Yep, that seems like a plan.
> Another bug is the device stays on, lit, in standby mode.
I would say that means that the suspend do not ask the usb keyboard to
go to sleep so that you can wake your device up by hitting a key (I
guess, I am not 100% sure regarding suspend and PM). Maybe play with
the suspend/resume callbacks and see if they are called.
>
> What do you think is the best solution to take? By that I mean should
> I keep the patch as part of hid-microsoft?
Yep. For the time being, keep it under hid-microsoft. If I manage to
convince myself to resubmit the patches I sent last month (which I
definitively should do), then we can think at switching it to
hid-multitouch if there is a gain (touchpad reporting full touches,
not mouse emulation, and/or fix the disconnect issue).
However, I don't plan to buy a surface 2 soon. I will not be able to
debug it easily, so you will be on your own :) Still, do not hesitate
to send me usb captures or hid-record[1] logs if you need a hand.
Cheers,
Benjamin
[1] http://bentiss.github.io/hid-replay-docs/