On Wed, 2016-06-15 at 16:28 +0200, Benjamin Tissoires wrote:

On Jun 13 2016 or thereabouts, Andy Shevchenko wrote:

quoted

On Fri, 2016-06-03 at 15:32 +0200, Benjamin Tissoires wrote:

quoted

On Jun 03 2016 or thereabouts, Andy Shevchenko wrote:

quoted

On Fri, 2016-06-03 at 14:23 +0200, Benjamin Tissoires wrote:

quoted

On Jun 03 2016 or thereabouts, Andy Shevchenko wrote:

quoted

On Fri, 2016-06-03 at 11:38 +0200, Benjamin Tissoires wrote:

quoted

On Jun 02 2016 or thereabouts, Andy Shevchenko wrote:

quoted

On Thu, 2016-06-02 at 16:11 +0200, Benjamin Tissoires
wrote:

quoted

quoted

quoted

quoted

I take linux-next + your two patches from this thread (+
some
unrelated
to HID patches).

OK. I think I know what happened:
- Microsoft forgot to put the Win 8 certification blob in
this
  particular device (of course, because Microsoft)
- we do not detect it as a Win 8 certified and do not set
the
  HID_QUIRK_NO_INIT_REPORTS flag
- your dmesg should show some error on plug, and then hid
can't
set
the
  input mode
- I can't add a "if win 8 then show the mouse collection"
because
your
  device doesn't report itself as win 8 :)

Anyway, could you try applying this small diff after my 2
patches
and
report if you now have a working touchpad?:

Nope. There is still no /dev/input/eventX associated with
touchpad.

Weird. On my system, if I replay your logs, I see 4 new nodes:
/dev/input/event21:	Microsoft Surface Keyboard Keyboard
/dev/input/event22:	Microsoft Surface Keyboard Consumer
Control
/dev/input/event23:	Microsoft Surface Keyboard Touchpad
/dev/input/event24:	Microsoft Surface Keyboard Keyboard

I had a line in dmesg that input8 is allocated to Touchpad, but
no
eventX (0..6 IIRC) from /dev/input reflects Touchpad events. I
can
get
them only via /dev/usb/hiddev0.

quoted

Can you attach the dmesg when plugging in the type cover?

I will do later, but there is no such thing 'plugging in'. It's
a
part
of the notebook, so, I can do detach-attach cycle, though it
shouldn't
matter, it should work immediately after boot I suppose.

Actually, if the touchpad doesn't want to be set to the multitouch
mode,
we might as well take your v2 of your patch in addition to this
series.
This should hopefully make the caps lock LED happy and at least
enable
the mouse collection. If someone wants to debug why the device
doesn't
want to switch to mt, I'd be happy to help/review patches, but I
think
we might as well take the easiest path :)

So Andy, if you still have the energy for this:
please apply this series and yours
(https://patchwork.kernel.org/patch/9069371/)

And report if this is sufficient enough.

Attached dmesg and hid-recorder files. Doesn't work. In dmesg it
complained on USB transfer at some point during boot.

Could you please double check your tree? The error in the dmesg can't
happen if you applied https://patchwork.kernel.org/patch/9069371/
which
sets the quirk HID_QUIRK_NO_INIT_REPORTS.

In usbhid_start(), we check for this quirk before entering the only
function that contains the error "timeout initializing reports\n".
(hiddev has an ioctl that can call it, but I assume you don't have any
userspace tool calling it, that would be insane).

So, your tree should have:
- latest Jiri's for-next branch (I usually merge it with the latest
  official rc)
- https://patchwork.kernel.org/patch/9081731/
- https://patchwork.kernel.org/patch/9081761/
- https://patchwork.kernel.org/patch/9069371/

Yes, that's how it looks like.

Actually the branch I'm using is public https://bitbucket.org/andy-shev/
linux/branch/topic%2Fdw%2Fqrk


P.S. Let me couple of days I will test once more to be sure.

-- 

Andy Shevchenko [off-list ref]
Intel Finland Oy
--
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