Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
No, it doesn't work. On 12/19/2015 12:06 AM, Bastien Nocera wrote: > On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: >> Use multitouch driver instead of microsoft one for Microsoft Surface >> Type Covers. >> >> By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as >> the multitouch pads do. >> >> Signed-off-by: Akihiko Odaki > > All the multimedia keys work, and MT support also works, on my Surface > 3 cover (045e:07de). > > *But* the Caps-Lock key's LED doesn't light up anymore. Can you verify > it does on yours as well? > > Cheers > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: > Use multitouch driver instead of microsoft one for Microsoft Surface > Type Covers. > > By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as > the multitouch pads do. > > Signed-off-by: Akihiko Odaki All the multimedia keys work, and MT support also works, on my Surface 3 cover (045e:07de). *But* the Caps-Lock key's LED doesn't light up anymore. Can you verify it does on yours as well? Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
On Fri, Dec 18, 2015 at 10:12 AM, Akihiko Odaki wrote: > The "Charm" keys seem to issue short-cut key combinations. > I also found Microsoft's document by searching for the combinations. > > https://msdn.microsoft.com/en-us/library/windows/hardware/dn614461(v=vs.85).aspx > > So the behavior of hid-multitouch is completely fine. OK, so it looks like there was no need to use hid-microsoft for these covers. However, I'd rather not add a full batch of the PIDs, but rather a completed tested environment before migrating these covers from hid-microsoft to hid-multitouch. Can you restrict the patch to the covers you actually have and were able to test? Cheers, Benjamin > > On 12/18/2015 03:28 PM, Akihiko Odaki wrote: >>> The search, share, connect(?), and settings keys >> I tested the patch again with xev and found that those "charm" >> keys don't respond both on hid-microsoft and hid-multitouch, while >> other keys respond. I'll have a further look. >> >> Anyway, keys working with hid-microsoft also work with >> hid-multitouch, so It's ready for merging, I think. >> >> On 12/15/2015 01:39 AM, Donavan Lance wrote: >>> On Mon, Dec 14, 2015 at 8:22 AM, Bastien Nocera >>> >> wrote: On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: > Use multitouch driver instead of microsoft one for Microsoft > Surface Type Covers. > > By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as > well as the multitouch pads do. I've discussed this a couple of weeks back with Benjamin Tissoires, and this patch would break the special keys (mute, brightness up/down, keyboard backlight up/down and play/pause). The recommended way to fix this was to move multi-touch processing into the Microsoft driver, so that it would handle the trackpad's multi- touch events. You should be able to do this by carefully picking up the handling code from hid-multitouch, or do something similar to what's done in hid- wacom, which has the same problem as the Type Cover handling. Can you confirm that this does indeed break those special keys? If it does, it's a NAK from my side. >>> >>> For what it's worth the special keys on my keyboard work fine >>> when using this patch. I'm using a Surface Pro 3, Type Cover 3, >>> running GNOME and Fedora 23. The search, share, connect(?), and >>> settings keys are the only ones not mapped to anything out of the >>> box, but they are recognized by xev. >>> -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
The "Charm" keys seem to issue short-cut key combinations. I also found Microsoft's document by searching for the combinations. https://msdn.microsoft.com/en-us/library/windows/hardware/dn614461(v=vs.85).aspx So the behavior of hid-multitouch is completely fine. On 12/18/2015 03:28 PM, Akihiko Odaki wrote: >> The search, share, connect(?), and settings keys > I tested the patch again with xev and found that those "charm" > keys don't respond both on hid-microsoft and hid-multitouch, while > other keys respond. I'll have a further look. > > Anyway, keys working with hid-microsoft also work with > hid-multitouch, so It's ready for merging, I think. > > On 12/15/2015 01:39 AM, Donavan Lance wrote: >> On Mon, Dec 14, 2015 at 8:22 AM, Bastien Nocera >> > wrote: >>> On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: Use multitouch driver instead of microsoft one for Microsoft Surface Type Covers. By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as the multitouch pads do. >>> >>> I've discussed this a couple of weeks back with Benjamin >>> Tissoires, and this patch would break the special keys (mute, >>> brightness up/down, keyboard backlight up/down and >>> play/pause). >>> >>> The recommended way to fix this was to move multi-touch >>> processing into the Microsoft driver, so that it would handle >>> the trackpad's multi- touch events. >>> >>> You should be able to do this by carefully picking up the >>> handling code from hid-multitouch, or do something similar to >>> what's done in hid- wacom, which has the same problem as the >>> Type Cover handling. >>> >>> Can you confirm that this does indeed break those special >>> keys? If it does, it's a NAK from my side. >> >> For what it's worth the special keys on my keyboard work fine >> when using this patch. I'm using a Surface Pro 3, Type Cover 3, >> running GNOME and Fedora 23. The search, share, connect(?), and >> settings keys are the only ones not mapped to anything out of the >> box, but they are recognized by xev. >> -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
> The search, share, connect(?), and settings keys I tested the patch again with xev and found that those "charm" keys don't respond both on hid-microsoft and hid-multitouch, while other keys respond. I'll have a further look. Anyway, keys working with hid-microsoft also work with hid-multitouch, so It's ready for merging, I think. On 12/15/2015 01:39 AM, Donavan Lance wrote: > On Mon, Dec 14, 2015 at 8:22 AM, Bastien Nocera > wrote: >> On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: >>> Use multitouch driver instead of microsoft one for Microsoft >>> Surface Type Covers. >>> >>> By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as >>> well as the multitouch pads do. >> >> I've discussed this a couple of weeks back with Benjamin >> Tissoires, and this patch would break the special keys (mute, >> brightness up/down, keyboard backlight up/down and play/pause). >> >> The recommended way to fix this was to move multi-touch >> processing into the Microsoft driver, so that it would handle the >> trackpad's multi- touch events. >> >> You should be able to do this by carefully picking up the >> handling code from hid-multitouch, or do something similar to >> what's done in hid- wacom, which has the same problem as the Type >> Cover handling. >> >> Can you confirm that this does indeed break those special keys? >> If it does, it's a NAK from my side. > > For what it's worth the special keys on my keyboard work fine when > using this patch. I'm using a Surface Pro 3, Type Cover 3, running > GNOME and Fedora 23. The search, share, connect(?), and settings > keys are the only ones not mapped to anything out of the box, but > they are recognized by xev. > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
On Mon, Dec 14, 2015 at 8:22 AM, Bastien Nocera wrote: > On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: >> Use multitouch driver instead of microsoft one for Microsoft Surface >> Type Covers. >> >> By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as >> the multitouch pads do. > > I've discussed this a couple of weeks back with Benjamin Tissoires, and > this patch would break the special keys (mute, brightness up/down, > keyboard backlight up/down and play/pause). > > The recommended way to fix this was to move multi-touch processing into > the Microsoft driver, so that it would handle the trackpad's multi- > touch events. > > You should be able to do this by carefully picking up the handling code > from hid-multitouch, or do something similar to what's done in hid- > wacom, which has the same problem as the Type Cover handling. > > Can you confirm that this does indeed break those special keys? If it > does, it's a NAK from my side. For what it's worth the special keys on my keyboard work fine when using this patch. I'm using a Surface Pro 3, Type Cover 3, running GNOME and Fedora 23. The search, share, connect(?), and settings keys are the only ones not mapped to anything out of the box, but they are recognized by xev. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: > Use multitouch driver instead of microsoft one for Microsoft Surface > Type Covers. > > By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as > the multitouch pads do. I've discussed this a couple of weeks back with Benjamin Tissoires, and this patch would break the special keys (mute, brightness up/down, keyboard backlight up/down and play/pause). The recommended way to fix this was to move multi-touch processing into the Microsoft driver, so that it would handle the trackpad's multi- touch events. You should be able to do this by carefully picking up the handling code from hid-multitouch, or do something similar to what's done in hid- wacom, which has the same problem as the Type Cover handling. Can you confirm that this does indeed break those special keys? If it does, it's a NAK from my side. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
