On Fri, Mar 7, 2014 at 12:50 PM, Derya <derya.kiran@xxxxxxxx> wrote: > > Am 07.03.2014 17:51, schrieb Benjamin Tissoires: > >> Hi Derya, >> >> On Fri, Mar 7, 2014 at 10:53 AM, Derya <derya.kiran@xxxxxxxx> wrote: >>> >>> 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 :) >> >>> 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 >> >>> 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 :) >> >>> 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. >> >>> 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. > >> >>> 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 :-) > >>> 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. > >>> 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 > >> >> Cheers, >> Benjamin >> >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-input" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
