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:

quoted

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:

quoted

On Mon, Dec 14, 2015 at 8:22 AM, Bastien Nocera 
[off-list ref]

wrote:

quoted

quoted

On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote:

quoted

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.