| Message ID | 20160603093855.GC6063@mail.corp.redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Jiri Kosina |
| Headers | show |
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: > > > > > > > > > > On May 31 2016 or thereabouts, Andy Shevchenko wrote: > > > > On Tue, 2016-05-31 at 18:07 +0200, Benjamin Tissoires wrote: > > > > > On May 20 2016 or thereabouts, Benjamin Tissoires wrote: > > > > > > On May 13 2016 or thereabouts, Andy Shevchenko wrote: > > > > > > Would you mind sending me a hid-recorder[1] trace of the > > > > > > device > > > > > > while > > > > > > typing few keys and using the touchpad? > > > > > > > > > > OK, so it looks like your touchpad stays in the mouse emulation > > > mode > > > for > > > some reasons. Did you do the recordings with hid-multitouch > > > patched, > > > or > > > with plain hid-generic or an other one? > > > > 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. > > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid- > multitouch.c > index ac35731..e51a753 100644 > --- a/drivers/hid/hid-multitouch.c > +++ b/drivers/hid/hid-multitouch.c > @@ -1379,6 +1379,10 @@ static const struct hid_device_id mt_devices[] > = { > MT_USB_DEVICE(USB_VENDOR_ID_ILITEK, > USB_DEVICE_ID_ILITEK_MULTITOUCH) }, > > + /* Microsoft */ > + { .driver_data = MT_CLS_WIN_8, > + MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x07cd) }, > +
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: > > > > > > > > > > > > On May 31 2016 or thereabouts, Andy Shevchenko wrote: > > > > > On Tue, 2016-05-31 at 18:07 +0200, Benjamin Tissoires wrote: > > > > > > On May 20 2016 or thereabouts, Benjamin Tissoires wrote: > > > > > > > On May 13 2016 or thereabouts, Andy Shevchenko wrote: > > > > > > > Would you mind sending me a hid-recorder[1] trace of the > > > > > > > device > > > > > > > while > > > > > > > typing few keys and using the touchpad? > > > > > > > > > > > > > OK, so it looks like your touchpad stays in the mouse emulation > > > > mode > > > > for > > > > some reasons. Did you do the recordings with hid-multitouch > > > > patched, > > > > or > > > > with plain hid-generic or an other one? > > > > > > 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 Can you attach the dmesg when plugging in the type cover? Cheers, Benjamin > > > > > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid- > > multitouch.c > > index ac35731..e51a753 100644 > > --- a/drivers/hid/hid-multitouch.c > > +++ b/drivers/hid/hid-multitouch.c > > @@ -1379,6 +1379,10 @@ static const struct hid_device_id mt_devices[] > > = { > > MT_USB_DEVICE(USB_VENDOR_ID_ILITEK, > > USB_DEVICE_ID_ILITEK_MULTITOUCH) }, > > > > + /* Microsoft */ > > + { .driver_data = MT_CLS_WIN_8, > > + MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x07cd) }, > > + > > > > > -- > Andy Shevchenko <andriy.shevchenko@linux.intel.com> > 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
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.
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. Cheers, Benjamin -- 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
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. > > Cheers, > Benjamin
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 -- 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
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.
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index ac35731..e51a753 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -1379,6 +1379,10 @@ static const struct hid_device_id mt_devices[] = { MT_USB_DEVICE(USB_VENDOR_ID_ILITEK, USB_DEVICE_ID_ILITEK_MULTITOUCH) }, + /* Microsoft */ + { .driver_data = MT_CLS_WIN_8, + MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x07cd) }, + /* MosArt panels */ { .driver_data = MT_CLS_CONFIDENCE_MINUS_ONE, MT_USB_DEVICE(USB_VENDOR_ID_ASUS,