Re: [PATCH 0/2 ] Surface Pro 2 HID sensor, wacom, keyboard/multitouch composite device

Am 07.03.2014 17:51, schrieb Benjamin Tissoires:

Hi Derya,

On Fri, Mar 7, 2014 at 10:53 AM, Derya [off-list ref] wrote:

quoted

The MS Surface Pro 2 has a very annoying USB composite device on port 2.3.
It has 3 interfaces:
- Interface 0 is the sensor-hub
- Interface 1 is the wacom digitizer² (it's one without finger input, there
is an atmel digitizer on port 2.4 for finger input)
- Interface 2 is the keyboard, if a keyboard cover is attached.

Oh... yes, indeed, it's gona be tricky :)

quoted

This USB composite device changes it product id depending if and which
keyboard cover is attached.
Each of this hid devices contains several collections, this complicated
everything.
I have uploaded a lsusb output to: http://pastebin.com/Jun5sa2t

Thanks

quoted

I have to say, that I'm neither a developer nor a programmer, this means
this things are beyond my ken, please excuse if my remarks aren't accurate.

But you still made the patches, so you are a programmer :)

quoted

The Touch and Type Covers (2) didn't work out of the box. Someone one the
ubuntuforums made a patch which adds them to the microsoft special driver,
but this leads to loading that driver for all the 3 interfaces and prevents
loading of hid-sensor-hub for interface 0, if a keyboard cover is attached.
Sadly this patch is submitted to the upstream kernel source.

Well, if it breaks things, it's still time to revert it.

quoted

Without that patch the keyboard covers are loading hid-multitouch instead of
hid-generic. This misbehaviour is a result of the fancy hid collections,
that the keyboards have. With hid-multitouch neither the keyboard nor the
touchpad of the cover works². I added an if clause to hid_scan_input_usage
to prevent loading of hid-multitouch for the keyboards. With hid-generic
keyboard and touchpad are working (they come up as one input)

More comment on that in the patch

I will follow your comments and update the patch.

quoted

We also need the HID_QUIRK_NOGET for this usb composite device, without it
hid-sensor-hub fails with a submit urb failure evertime a keyboard cover is
(de)attached and it takes some seconds until the keyboard and wacom
digitizer responds.

Can you test if HID_QUIRK_NO_INIT_INPUT_REPORTS works. It's a little
bit less a hammer than NO_GET, and I am pretty sure that this is what
Windows does by default.

Sure, I can give it a try :-)

quoted

The second patch adds HID_SENSOR_HUB_ENUM_QUIRK for the Surface Pro 2's
sensor-hub. There is still a bug with the sensors and the Surface Pro 2, but
I didn't dig into it yet (hid-sensor-magn-3d fails to setup attributes)

Regards,

Derya



1 I'm also working to get the wacom driver working. At the moment the stylus
works with hid-generic(if my patch is applied, without it use
hid-microsoft). I got it working with wacom driver without disturbing the
other interfaces, but the wacom interface contains also some fancy
collection. The wacom driver doesn't care of them, this leads to losing the
on device volume and left meta keys. With hid-generic they work, but the
input events get distorted after the use of the eraser. But, this is another
story...

For the record, I am tempted (and some people at wacom too) to switch
the Wacom devices to use hid-wacom instead of wacom.ko. This may solve
your problems here.

I've looked into hid-wacom and thought, it would be better to use it 
instead of wacom.ko, but then I saw it contains only wireless device. It 
seemed to be the wrong place. The other thing is, if I use hid-wacom, 
then I have to add that USB composite device again to the special driver 
list, like with hid-microsoft, and this leads us to the same problem. It 
would load hid-wacom for all 3 interfaces. Or am I wrong? With wacom.ko 
I'm using the macro USB_DEVICE_INTERFACE_NUMBER (instead of USB_DEVICE 
and USB_DEVICE_AND_INTERFACE_INFO, which are used for other wacon 
devices) to applied the driver only to the wacom interface without 
disturbing the other ones.
I will try to use hid-wacom, but this will take some time.

quoted

2 @Benjamin Tissoires
I have tried your patches for fancy collection in hid-multitouch. It seems
to be the right way to solve the problem with the keyboard (better than my
approach to exclude this devices in hid_scan_input_usage), but it has the
some drawbacks at the moment. It splits the input into 5 pieces. 2 seperate
keyboard inputs that leads into losing the caps lock led. The touchpad is
mapped as a mouse. There is also a consumer device, which gives me no input
and an unkown device, but no multitouch device. There is a HID_DG_INPUTMODE
out of range error in dmesg. Please, contact me, if you need some logs.

With the lsusb output I should be able to conduct more tests. But I
may not have time to do them.
Did you used the latest patch applied this week by Jiri?

I tried it with this 
http://www.spinics.net/lists/linux-input/msg30018.html patch set.

Cheers,
Benjamin

quoted

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html