Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1423070 > unrolled thread

Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to  report multitouch data Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2016-06-15 16:30 +0200
    Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to  report multitouch data Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-06-23 09:30 +0200

#1423070 — Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

On Jun 13 2016 or thereabouts, Andy Shevchenko wrote:
> On Fri, 2016-06-03 at 15:32 +0200, Benjamin Tissoires wrote:
> > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote:
> > > On Fri, 2016-06-03 at 14:23 +0200, Benjamin Tissoires wrote:
> > > 
> > > > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote:
> > > > > On Fri, 2016-06-03 at 11:38 +0200, Benjamin Tissoires wrote:
> > > > > > On Jun 02 2016 or thereabouts, Andy Shevchenko wrote:
> > > > > > > On Thu, 2016-06-02 at 16:11 +0200, Benjamin Tissoires wrote:
> > > 
> > > 
> > > > > > > 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.
> > > 
> > > > 
> > > > 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/

Cheers,
Benjamin

[toc] | [next] | [standalone]

#1429526

On Wed, 2016-06-15 at 16:28 +0200, Benjamin Tissoires wrote:
> On Jun 13 2016 or thereabouts, Andy Shevchenko wrote:
> > On Fri, 2016-06-03 at 15:32 +0200, Benjamin Tissoires wrote:
> > > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote:
> > > > On Fri, 2016-06-03 at 14:23 +0200, Benjamin Tissoires wrote:
> > > > 
> > > > > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote:
> > > > > > On Fri, 2016-06-03 at 11:38 +0200, Benjamin Tissoires wrote:
> > > > > > > On Jun 02 2016 or thereabouts, Andy Shevchenko wrote:
> > > > > > > > On Thu, 2016-06-02 at 16:11 +0200, Benjamin Tissoires
> > > > > > > > wrote:
> > > > 
> > > > 
> > > > > > > > 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.
> > > > 
> > > > > 
> > > > > 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 <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web