Microsoft Surface Pro 3 Type Cover keyboard

PATCH Jarrad Whitaker 4 participants 7 messages Oct 23, 2014 – Nov 4, 2014 3 messages not in the archive

Subsystems (2)

HID USB HID/hidbp drivers (USB keyboards, mice, remote controls, ...)

lore

Share & tools

lore

Jarrad Whitaker

author

2014-10-23 15:57 UTC #0 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The keyboard on the Surface Pro 3 type cover does not function without some patching, similar to what was apparently required for the SP2 type/touch covers.

A working patch against 3.16 attached, it's an amalgamation of "some dude posted this on the ubuntu/arch forums and it seems to work" so I'm making no claims that it's kernel-quality! Just trying to give a better indication of what needs to be added. My C is rudimentary and my knowledge of the kernel limited to 'fakeroot debian/rules updateconfigs', sorry. :)
Happy to test any improved version, but note I only have a type, not a touch cover.

Patch source is
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/, which in turn sources a Russian site.

c.f. https://bugzilla.kernel.org/show_bug.cgi?id=86641

Jarrad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUSSVZAAoJED3oB8CFhvqeL2oP/3aaFFjCMaVKyJKB7Xi5DgLq WuHLnKUVVVcriW+ZP6AoCdowNEDqlmtrW0Ytvr0wbPGNOutPpWrrNKn9/LDXblt/ 26CLTM3M44hnyST3QbyfCNOhKKncPBMdqz0jwcsJnElSRWVjSmiQ4LoHcBkrnUTV TwoURkA75TzRKqcy5v9FHHAezGXLmqiSym8/F9RBO2ELi2s8bRuL/a8BLo3HQjSS HPCoCiZ0wlrTImT/w1DW1EpPNXkQ1EjhHZdnz9DrGlr0ha9LtstrFeM15TXWBLME /hqn7wFehwuxIZccMg1ZiDidf2tMPNnvPOnng/PiJDa7pOlzSn9OAMggLm//yk4m oyyvzr75onZa4m61Ay2Llhs+2NLAywke+04FXJ3YxQ4h+3AW+cMOIcdqzHbof2tI TfwMfVlmVbgdIRnzYDVXGCh7odnd18Bt/xR/YSGJVpoMZMsMlav8QTNzVw8kkiIZ 35j2C/MBme3NPhXVsg7pgILgSQH0MdHqdC/aRMQQiqItVvobGgPpTf8KtGXwBbEy 7wEAlUkr4bgdsAkX1hNuFCtCPZ7fm2lJoxWm8sOUBkbp2gx+JaSmL4Qyv8CkWj+C K2FNqlf4DFb6JyN21fENmou9lTfhUujC3/ECeOfRiip/6ol01VFebUDS6dQcM7PK kQInY7SjFoCx0u8y4YMM
=CI1g
-----END PGP SIGNATURE-----

drivers/hid/hid-core.c +4 -0

index 8ed66fd..420810c 100644
@@ -702,6 +702,10 @@ static void hid_scan_collection(struct hid_parser *parser, unsigned type)
 	if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
 	    type == HID_COLLECTION_PHYSICAL)
 		hid->group = HID_GROUP_SENSOR_HUB;
+	if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
+		hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 &&
+		hid->group == HID_GROUP_MULTITOUCH)
+	hid->group = HID_GROUP_GENERIC;
 }
 
 static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)

drivers/hid/hid-ids.h +1 -0

index 48b66bb..cd0ca8d 100644
@@ -638,6 +638,7 @@
 #define USB_DEVICE_ID_MS_SURFACE_PRO_2   0x0799
 #define USB_DEVICE_ID_MS_TOUCH_COVER_2   0x07a7
 #define USB_DEVICE_ID_MS_TYPE_COVER_2    0x07a9
+#define USB_DEVICE_ID_MS_TYPE_COVER_3   0x07dc
 
 #define USB_VENDOR_ID_MOJO		0x8282
 #define USB_DEVICE_ID_RETRO_ADAPTER	0x3201

drivers/hid/hid-microsoft.c +2 -1

index 8ba17a9..d878567 100644
@@ -274,7 +274,8 @@ 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_3),
+		.driver_data = MS_HIDINPUT },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT),
 		.driver_data = MS_PRESENTER },
 	{ }

drivers/hid/usbhid/hid-quirks.c +1 -0

index 31e6727..18cd2c6 100644
@@ -74,6 +74,7 @@ static const struct hid_blacklist {
 	{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, HID_QUIRK_NO_INIT_REPORTS },
 	{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
+	{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3, HID_QUIRK_NO_INIT_REPORTS },
 	{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL, HID_QUIRK_NO_INIT_REPORTS },
 	{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, HID_QUIRK_NO_INIT_REPORTS },
 	{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE, HID_QUIRK_NO_INIT_REPORTS },

Jiri Kosina

2014-11-03 13:33 UTC #1 lore raw

Quoted 13 lines · Jarrad Whitaker

The keyboard on the Surface Pro 3 type cover does not function without some patching, similar to what was apparently required for the SP2 type/touch covers.
A working patch against 3.16 attached, it's an amalgamation of "some dude posted this on the ubuntu/arch forums and it seems to work" so I'm making no claims that it's kernel-quality! Just trying to give a better indication of what needs to be added. My C is rudimentary and my knowledge of the kernel limited to 'fakeroot debian/rules updateconfigs', sorry. :)
Happy to test any improved version, but note I only have a type, not a touch cover.

Quoted 3 lines

Patch source is
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/, which in turn sources a Russian site.

Hi,

thanks. Adding Alan Wu to CC, who sent me a slightly different patch for this issue -- see the archives of linux-input list from a few days back.

Your patch is missing at least Signed-off-by: line, and also seems to lack the update to hid_have_special_driver[].

Could you two guys please cooperate and send me a patch that should be applied? I don't have the device so can't really test properly myself.

Thanks,

Signature · 2 lines

Jiri Kosina
SUSE Labs

Benjamin Tissoires

2014-11-03 15:28 UTC #2 lore raw

Quoted 19 lines · Jiri Kosina

Quoted 13 lines · Jarrad Whitaker
The keyboard on the Surface Pro 3 type cover does not function without some patching, similar to what was apparently required for the SP2 type/touch covers.
A working patch against 3.16 attached, it's an amalgamation of "some dude posted this on the ubuntu/arch forums and it seems to work" so I'm making no claims that it's kernel-quality! Just trying to give a better indication of what needs to be added. My C is rudimentary and my knowledge of the kernel limited to 'fakeroot debian/rules updateconfigs', sorry. :)
Happy to test any improved version, but note I only have a type, not a touch cover.
Quoted 3 lines
Patch source is
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/, which in turn sources a Russian site.

Quoted 7 lines

Hi,
thanks. Adding Alan Wu to CC, who sent me a slightly different patch for this issue -- see the archives of linux-input list from a few days back.
Your patch is missing at least Signed-off-by: line, and also seems to lack the update to hid_have_special_driver[].

Jiri, actually, the hid_have_special_driver entry is not 100% required to make it work (though it would be cleaner, I agree). Actually, the TypeCover presents a Precision TouchPad, so hid-core considers it should have the hid-multitouch driver driving it (see
https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )

I am not sure we should use hid-multtiouch or hid-microsoft. My guess is that both will work, but hid-multitouch might provide true raw reporting for the touchpad. On the other hand, maybe hid-microsoft will bind special keys that hid-multitouch will not...

If the path is to go through hid-microsoft, then Jarrad, Alan, yes, please, add your device to hid_have_special_driver.

Cheers,
Benjamin

Quoted 13 lines

Could you two guys please cooperate and send me a patch that should be applied? I don't have the device so can't really test properly myself.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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

A message that is not in the archive (sent off-list or not yet received): CAE7eX3JsnY_xAookiT_ycdES5dRP6GkAa+bcRyQ5HaU9iMtGQw@mail.gmail.com

Benjamin Tissoires

2014-11-03 20:39 UTC #4 lore raw

Quoted 51 lines · Andrew Duggan

Quoted 36 lines · Benjamin Tissoires
Quoted 19 lines · Jiri Kosina
Quoted 13 lines · Jarrad Whitaker
The keyboard on the Surface Pro 3 type cover does not function without some patching, similar to what was apparently required for the SP2 type/touch covers.
A working patch against 3.16 attached, it's an amalgamation of "some dude posted this on the ubuntu/arch forums and it seems to work" so I'm making no claims that it's kernel-quality! Just trying to give a better indication of what needs to be added. My C is rudimentary and my knowledge of the kernel limited to 'fakeroot debian/rules updateconfigs', sorry. :)
Happy to test any improved version, but note I only have a type, not a touch cover.
Quoted 3 lines
Patch source is
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/, which in turn sources a Russian site.
Quoted 8 lines
Hi,
thanks. Adding Alan Wu to CC, who sent me a slightly different patch for this issue -- see the archives of linux-input list from a few days back.
Your patch is missing at least Signed-off-by: line, and also seems to lack
the update to hid_have_special_driver[].
Jiri, actually, the hid_have_special_driver entry is not 100% required to make it work (though it would be cleaner, I agree). Actually, the TypeCover presents a Precision TouchPad, so hid-core considers it should have the hid-multitouch driver driving it (see
https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
Quoted 5 lines
I am not sure we should use hid-multitouch or hid-microsoft. My guess is that both will work, but hid-multitouch might provide true raw reporting for the touchpad. On the other hand, maybe hid-microsoft will bind special keys that hid-multitouch will not...
I would think that being able to do multifinger gestures would make using hid-multitouch preferable. Using hid-microsoft will keep the touchpad in mouse mode since the host needs to send the feature report to switch the touchpad into PTP mode. In PTP mode, this touchpad will report absolute data for three fingers.

Quoted 5 lines

I think the main issue is how do you get the keyboard working when the device is using the hid-multitouch driver. After looking at the bug above and Benjamin's changes on Github it looks like adding an entry in mt_devices and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard. Is that correct? I haven't been able to try it out.

Correct. See https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
The reporter seems to claim that it works for him, but I need to check
if the touchpad is correctly presented (properties, etc), if the
touchpad data come from the raw node, and not the mouse node, and if
there is no problems with respect to the keyboard. I'd prefer the
owners of the device to double check all of this.

Quoted 4 lines

If hid-microsoft has functionality which hid-multitouch doesn't provide is there a way to combine the two without reimplementing the functionality of one driver into the other?

The problem with this device is that the keyboard and touchpad are on the same hid device, on different collections. So if hid-microsoft does fancy stuff on the keyboard level, the only option will be to merge hid-multitouch in hid-input (this might be needed at some point).

Cheers,
Benjamin

Quoted 28 lines

Quoted 26 lines
If the path is to go through hid-microsoft, then Jarrad, Alan, yes, please, add your device to hid_have_special_driver.
Cheers,
Benjamin
Quoted 6 lines
Could you two guys please cooperate and send me a patch that should be applied? I don't have the device so can't really test properly myself.
Thanks,
Quoted 8 lines
--
Jiri Kosina
SUSE Labs
--
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
--
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

A message that is not in the archive (sent off-list or not yet received): CABkLPOLiiyHSQs=nu0js_NDL61JxoQXGYo9ZwkJ_oT0samftYA@mail.gmail.com

Benjamin Tissoires

2014-11-03 21:27 UTC #6 lore raw

Quoted 12 lines · Alan Wu

My initial checks after sudo cat /dev/hidraw0 shows that moving multiple fingers does work with my patch as earlier using hid-microsoft. However, the dim and brightness keys (Fn+F1, Fn+F2) does not work.
My tests with multiple fingers include:
moving one finger,
adding and moving second finger with first finger held, moving first finger with second finger stationary, adding and moving third finger with first and second finger held, moving first or second finger with third finger held. repeating with up to eight fingers.

Quoted 7 lines

It is hard to check moving two fingers at the same time with another one (or more) fingers held stationary because the way the output works. It comes out something like this, so I can't tell if they are doing what they are supposed to.
^@^@^C\377^@^@
Please let me know how to continue testing.

You can check the various event node outputs by using evemu. If the touchpad presents ABS_MT_SLOT and makes use of it, you are using the raw reporting mode.

You can also assess it with programs like mtview[1] of mtdiag-qt[2] (both need to be run as root to get access to the event nodes).

Quoted 6 lines

I'm currently adding the hid_have_special_driver
and a couple other lines from Jarrad's website to the patch and will test it soon before submitting.
Also, how can I continue this thread to linux-input mailing list from gmail? It keeps rejecting my mail.

You need to use the "Plain Text Mode" mode. There is a small arrow on the bottom right of the compose window (next to the trash) and above "Print", you have the previously mentioned mode.

Cheers,
Benjamin

[1] https://github.com/whot/mtview (or maybe
http://bitmath.org/code/mtview/, I can not remember if the bitmath one is still actively supported)
[2] https://github.com/bentiss/mtdiag-qt

Quoted 131 lines

Quoted 126 lines · Benjamin Tissoires
Quoted 58 lines · Andrew Duggan
Quoted 41 lines · Benjamin Tissoires
Quoted 24 lines · Jiri Kosina
Quoted 15 lines · Jarrad Whitaker
The keyboard on the Surface Pro 3 type cover does not function without
some patching, similar to what was apparently required for the SP2 type/touch covers.
A working patch against 3.16 attached, it's an amalgamation of "some dude posted this on the ubuntu/arch forums and it seems to work" so I'm making no claims that it's kernel-quality! Just trying to give a better indication of what needs to be added. My C is rudimentary and my knowledge of the kernel limited to 'fakeroot debian/rules updateconfigs', sorry. :)
Happy to test any improved version, but note I only have a type, not a
touch cover.
Quoted 4 lines
Patch source is
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/,
which
in turn sources a Russian site.
Hi,
Quoted 8 lines
thanks. Adding Alan Wu to CC, who sent me a slightly different patch for
this issue -- see the archives of linux-input list from a few days back.
Your patch is missing at least Signed-off-by: line, and also seems to lack
the update to hid_have_special_driver[].
Jiri, actually, the hid_have_special_driver entry is not 100% required to make it work (though it would be cleaner, I agree). Actually, the TypeCover presents a Precision TouchPad, so hid-core considers it should have the hid-multitouch driver driving it (see
https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
Quoted 5 lines
I am not sure we should use hid-multitouch or hid-microsoft. My guess is that both will work, but hid-multitouch might provide true raw reporting for the touchpad. On the other hand, maybe hid-microsoft will bind special keys that hid-multitouch will not...
I would think that being able to do multifinger gestures would make using
hid-multitouch preferable. Using hid-microsoft will keep the touchpad in mouse mode since the host needs to send the feature report to switch the touchpad into PTP mode. In PTP mode, this touchpad will report absolute data
for three fingers.
Quoted 8 lines
I think the main issue is how do you get the keyboard working when the device is using the hid-multitouch driver. After looking at the bug above
and Benjamin's changes on Github it looks like adding an entry in mt_devices
and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard. Is that
correct? I haven't been able to try it out.
Correct. See
https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
The reporter seems to claim that it works for him, but I need to check if the touchpad is correctly presented (properties, etc), if the touchpad data come from the raw node, and not the mouse node, and if there is no problems with respect to the keyboard. I'd prefer the owners of the device to double check all of this.
Quoted 6 lines
If hid-microsoft has functionality which hid-multitouch doesn't provide is
there a way to combine the two without reimplementing the functionality of
one driver into the other?
The problem with this device is that the keyboard and touchpad are on the same hid device, on different collections. So if hid-microsoft does fancy stuff on the keyboard level, the only option will be to merge hid-multitouch in hid-input (this might be needed at some point).
Cheers,
Benjamin
Quoted 32 lines
Quoted 30 lines
If the path is to go through hid-microsoft, then Jarrad, Alan, yes, please, add your device to hid_have_special_driver.
Cheers,
Benjamin
Quoted 8 lines
Could you two guys please cooperate and send me a patch that should be
applied? I don't have the device so can't really test properly myself.
Thanks,
Quoted 9 lines
--
Jiri Kosina
SUSE Labs
--
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
--
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

Jarrad Whitaker

author

2014-11-04 01:08 UTC #7 lore raw

Wow, what a flurry of activity! I don't have much to add beyond Alan's patch on its own did not work for me, I am assuming this is due to manually needing to assign it to evdev which I did not do. Also, on the dim/brightness keys, these control the backlight of the keyboard itself and as far as I can tell do not even pass any signal to the device's native Windows 8.
Can probably test a little more tonight or tomorrow, but I am in the middle of exams I'm afraid and this could be a dangerously effective form of procrastination, so I won't be able to so much for a couple of weeks yet.

Given the tiny scope of the current patch, is there a chance it could get into 3.18 as is so people at least have a working keyboard, then we continue to work on a proper solution for later?

Jarrad

P.S. sorry, my win8 mail app lies about sending in plaintext mode.

Quoted 179 lines · Benjamin Tissoires

Quoted 12 lines · Alan Wu
My initial checks after sudo cat /dev/hidraw0 shows that moving multiple fingers does work with my patch as earlier using hid-microsoft. However, the dim and brightness keys (Fn+F1, Fn+F2) does not work.
My tests with multiple fingers include:
moving one finger,
adding and moving second finger with first finger held, moving first finger with second finger stationary, adding and moving third finger with first and second finger held, moving first or second finger with third finger held. repeating with up to eight fingers.
Quoted 7 lines
It is hard to check moving two fingers at the same time with another one (or more) fingers held stationary because the way the output works. It comes out something like this, so I can't tell if they are doing what they are supposed to.
^@^@^C\377^@^@
Please let me know how to continue testing.
You can check the various event node outputs by using evemu. If the touchpad presents ABS_MT_SLOT and makes use of it, you are using the raw reporting mode.
You can also assess it with programs like mtview[1] of mtdiag-qt[2] (both need to be run as root to get access to the event nodes).
Quoted 6 lines
I'm currently adding the hid_have_special_driver
and a couple other lines from Jarrad's website to the patch and will test it soon before submitting.
Also, how can I continue this thread to linux-input mailing list from gmail? It keeps rejecting my mail.
You need to use the "Plain Text Mode" mode. There is a small arrow on the bottom right of the compose window (next to the trash) and above "Print", you have the previously mentioned mode.
Cheers,
Benjamin
[1] https://github.com/whot/mtview (or maybe
http://bitmath.org/code/mtview/, I can not remember if the bitmath one is still actively supported)
[2] https://github.com/bentiss/mtdiag-qt
Quoted 131 lines
Quoted 126 lines · Benjamin Tissoires
Quoted 58 lines · Andrew Duggan
Quoted 41 lines · Benjamin Tissoires
Quoted 24 lines · Jiri Kosina
Quoted 15 lines · Jarrad Whitaker
The keyboard on the Surface Pro 3 type cover does not function without
some patching, similar to what was apparently required for the SP2 type/touch covers.
A working patch against 3.16 attached, it's an amalgamation of "some dude posted this on the ubuntu/arch forums and it seems to work" so I'm making no claims that it's kernel-quality! Just trying to give a better indication of what needs to be added. My C is rudimentary and my knowledge of the kernel limited to 'fakeroot debian/rules updateconfigs', sorry. :)
Happy to test any improved version, but note I only have a type, not a
touch cover.
Quoted 4 lines
Patch source is
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/,
which
in turn sources a Russian site.
Hi,
Quoted 8 lines
thanks. Adding Alan Wu to CC, who sent me a slightly different patch for
this issue -- see the archives of linux-input list from a few days back.
Your patch is missing at least Signed-off-by: line, and also seems to lack
the update to hid_have_special_driver[].
Jiri, actually, the hid_have_special_driver entry is not 100% required to make it work (though it would be cleaner, I agree). Actually, the TypeCover presents a Precision TouchPad, so hid-core considers it should have the hid-multitouch driver driving it (see
https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
Quoted 5 lines
I am not sure we should use hid-multitouch or hid-microsoft. My guess is that both will work, but hid-multitouch might provide true raw reporting for the touchpad. On the other hand, maybe hid-microsoft will bind special keys that hid-multitouch will not...
I would think that being able to do multifinger gestures would make using
hid-multitouch preferable. Using hid-microsoft will keep the touchpad in mouse mode since the host needs to send the feature report to switch the touchpad into PTP mode. In PTP mode, this touchpad will report absolute data
for three fingers.
Quoted 8 lines
I think the main issue is how do you get the keyboard working when the device is using the hid-multitouch driver. After looking at the bug above
and Benjamin's changes on Github it looks like adding an entry in mt_devices
and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard. Is that
correct? I haven't been able to try it out.
Correct. See
https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
The reporter seems to claim that it works for him, but I need to check if the touchpad is correctly presented (properties, etc), if the touchpad data come from the raw node, and not the mouse node, and if there is no problems with respect to the keyboard. I'd prefer the owners of the device to double check all of this.
Quoted 6 lines
If hid-microsoft has functionality which hid-multitouch doesn't provide is
there a way to combine the two without reimplementing the functionality of
one driver into the other?
The problem with this device is that the keyboard and touchpad are on the same hid device, on different collections. So if hid-microsoft does fancy stuff on the keyboard level, the only option will be to merge hid-multitouch in hid-input (this might be needed at some point).
Cheers,
Benjamin
Quoted 32 lines
Quoted 30 lines
If the path is to go through hid-microsoft, then Jarrad, Alan, yes, please, add your device to hid_have_special_driver.
Cheers,
Benjamin
Quoted 8 lines
Could you two guys please cooperate and send me a patch that should be
applied? I don't have the device so can't really test properly myself.
Thanks,
Quoted 9 lines
--
Jiri Kosina
SUSE Labs
--
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
--
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

A message that is not in the archive (sent off-list or not yet received): CABkLPOK2YQDddLpF2VvoAKxNVYsCOg0-W41SBiSZkDi7df9Opw@mail.gmail.com

Alan Wu

2014-11-04 02:32 UTC #9 lore raw

Hi all,
I submitted the new patch. Please review and comment.

Thanks,
Alan

Quoted 261 lines · Alan Wu

Hi all,
So after using the patch with Jarrad's changes added in, I was able to
revert the evdev config to its original and have no problems. I have attached the evdev.conf as follows. However, multitouch does not seem to work since ABS_MT_SLOT is defined, but not used. I have attached some sample tests with multiple fingers. I'm not sure what changed between the tests, however, one showed EV_ABS and the other used EV_REL.
I did not realize the dim/brightness was for the type cover hardware backlight, and what Jarrad said makes sense that it probably does not send a signal.
Please give me some suggestions on what I can do to investigate the ABS_MT_SLOT issue now, as this is my first time working with the kernel. However, I would second Jarrad's suggestion that we patch this for now and get multitouch working later, so at least I can keep ubuntu updated without messing with the kernel myself every time.
I will submit the patch soon to the mailing list.
Thanks,
Alan
Quoted 232 lines · Jarrad Whitaker
Wow, what a flurry of activity! I don't have much to add beyond Alan's patch on its own did not work for me, I am assuming this is due to manually needing to assign it to evdev which I did not do. Also, on the dim/brightness keys, these control the backlight of the keyboard itself and as far as I can tell do not even pass any signal to the device's native Windows 8.
Can probably test a little more tonight or tomorrow, but I am in the middle of exams I'm afraid and this could be a dangerously effective form of procrastination, so I won't be able to so much for a couple of weeks yet.
Given the tiny scope of the current patch, is there a chance it could get into 3.18 as is so people at least have a working keyboard, then we continue to work on a proper solution for later?
Jarrad
P.S. sorry, my win8 mail app lies about sending in plaintext mode.
Quoted 210 lines · Benjamin Tissoires
Quoted 23 lines · Alan Wu
My initial checks after sudo cat /dev/hidraw0 shows that moving multiple
fingers does work with my patch as earlier using hid-microsoft. However,
the dim and brightness keys (Fn+F1, Fn+F2) does not work.
My tests with multiple fingers include:
moving one finger,
adding and moving second finger with first finger held, moving first finger with second finger stationary, adding and moving third finger with first and second finger held, moving first or second finger with third finger held. repeating with up to eight fingers.
It is hard to check moving two fingers at the same time with another one (or
more) fingers held stationary because the way the output works. It comes
out something like this, so I can't tell if they are doing what they are
supposed to.
^@^@^C\377^@^@
Quoted 1 line
Please let me know how to continue testing.
You can check the various event node outputs by using evemu. If the touchpad presents ABS_MT_SLOT and makes use of it, you are using the raw reporting mode.
You can also assess it with programs like mtview[1] of mtdiag-qt[2] (both need to be run as root to get access to the event nodes).
Quoted 8 lines
I'm currently adding the hid_have_special_driver
and a couple other lines from Jarrad's website to the patch and will test it
soon before submitting.
Also, how can I continue this thread to linux-input mailing list from gmail?
It keeps rejecting my mail.
You need to use the "Plain Text Mode" mode. There is a small arrow on the bottom right of the compose window (next to the trash) and above "Print", you have the previously mentioned mode.
Cheers,
Benjamin
[1] https://github.com/whot/mtview (or maybe
http://bitmath.org/code/mtview/, I can not remember if the bitmath one is still actively supported)
[2] https://github.com/bentiss/mtdiag-qt
Quoted 155 lines
Quoted 150 lines · Benjamin Tissoires
Quoted 73 lines · Andrew Duggan
Quoted 52 lines · Benjamin Tissoires
Quoted 37 lines · Jiri Kosina
Quoted 21 lines · Jarrad Whitaker
The keyboard on the Surface Pro 3 type cover does not function without
some patching, similar to what was apparently required for the SP2
type/touch covers.
A working patch against 3.16 attached, it's an amalgamation of "some
dude posted this on the ubuntu/arch forums and it seems to work" so
I'm making no claims that it's kernel-quality! Just trying to give a
better indication of what needs to be added. My C is rudimentary and
my knowledge of the kernel limited to 'fakeroot debian/rules updateconfigs', sorry. :)
Happy to test any improved version, but note I only have a type, not
a
touch cover.
Quoted 4 lines
Patch source is
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/,
which
in turn sources a Russian site.
Hi,
thanks. Adding Alan Wu to CC, who sent me a slightly different patch
for
this issue -- see the archives of linux-input list from a few days
back.
Quoted 4 lines
Your patch is missing at least Signed-off-by: line, and also seems to
lack
the update to hid_have_special_driver[].
Jiri, actually, the hid_have_special_driver entry is not 100% required
to make it work (though it would be cleaner, I agree). Actually, the TypeCover presents a Precision TouchPad, so hid-core considers it should have the hid-multitouch driver driving it (see
https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
Quoted 6 lines
I am not sure we should use hid-multitouch or hid-microsoft. My guess
is that both will work, but hid-multitouch might provide true raw reporting for the touchpad. On the other hand, maybe hid-microsoft will bind special keys that hid-multitouch will not...
I would think that being able to do multifinger gestures would make using
hid-multitouch preferable. Using hid-microsoft will keep the touchpad in
mouse mode since the host needs to send the feature report to switch the
touchpad into PTP mode. In PTP mode, this touchpad will report absolute
data
for three fingers.
Quoted 10 lines
I think the main issue is how do you get the keyboard working when the
device is using the hid-multitouch driver. After looking at the bug above
and Benjamin's changes on Github it looks like adding an entry in mt_devices
and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard. Is
that
correct? I haven't been able to try it out.
Correct. See
https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
The reporter seems to claim that it works for him, but I need to check if the touchpad is correctly presented (properties, etc), if the touchpad data come from the raw node, and not the mouse node, and if there is no problems with respect to the keyboard. I'd prefer the owners of the device to double check all of this.
Quoted 8 lines
If hid-microsoft has functionality which hid-multitouch doesn't provide
is
there a way to combine the two without reimplementing the functionality
of
one driver into the other?
The problem with this device is that the keyboard and touchpad are on the same hid device, on different collections. So if hid-microsoft does fancy stuff on the keyboard level, the only option will be to merge hid-multitouch in hid-input (this might be needed at some point).
Cheers,
Benjamin
Quoted 35 lines
Quoted 33 lines
If the path is to go through hid-microsoft, then Jarrad, Alan, yes, please, add your device to hid_have_special_driver.
Cheers,
Benjamin
Quoted 9 lines
Could you two guys please cooperate and send me a patch that should
be
applied? I don't have the device so can't really test properly myself.
Thanks,
Quoted 10 lines
--
Jiri Kosina
SUSE Labs
--
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
--
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