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

On Fri, Mar 7, 2014 at 12:50 PM, Derya [off-list ref] wrote:

Am 07.03.2014 17:51, schrieb Benjamin Tissoires:

quoted

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

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

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.

You can, but you will loose your time I think. I just mentioned that
because I mainly wanted to warn Jiri and others on the list that some
people are thinking of it.
But As you said there is not the thing you need currently for this
device, so if you can manage to use wacom.ko, that's fine.

quoted

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.

Alright, this is the last one which has been applied by Jiri.
I'll definitively have to check this out them :(

Cheers,
Benjamin

quoted

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