uhidpp(4): logitech hid++ device driver
Hi, Here's a new driver for Logitech HID++ devices, currently limited to exposing battery sensors. Here's an example using a Logitech M330 mouse: $ dmesg | grep uhidpp uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 $ sysctl hw.sensors.uhidpp0 hw.sensors.uhidpp0.raw0=2 (battery levels) hw.sensors.uhidpp0.percent0=70.00% (battery level), OK The raw0 sensor reflects number of available battery levels, the resolution on this device is not great... Most of the code is derived from the hid-logitech-hidpp Linux driver. Some assorted notes: * In order to communicate with the device inside the attach routine, I had to wire up the interrupt handler as this by default is done first once the same attach routine has returned. Hence the introduction of uhidev_set_intr(). If this is an acceptable approach, this can go in as a separate commit. * I kept using the `return -errno' convention from the Linux driver in order to distingush errors from the hardware, which are always positive. I you happen to have a Logitech HID++ device and run into any problem(s), please enable UHIDPP_DEBUG and send me the output. Comments? OK? diff --git share/man/man4/Makefile share/man/man4/Makefile index 02af7a47a44..74a4e17d7dc 100644 --- share/man/man4/Makefile +++ share/man/man4/Makefile @@ -83,8 +83,8 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ - uk.4 ukbd.4 \ + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ + uipaq.4 uk.4 ukbd.4 \ ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \ ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \ uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \ diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 index f0a6776a27b..d264935a65c 100644 --- share/man/man4/uhidev.4 +++ share/man/man4/uhidev.4 @@ -40,6 +40,7 @@ .Cd "ucycom* at uhidev?" .Cd "ugold* at uhidev?" .Cd "uhid*at uhidev?" +.Cd "uhidpp* at uhidev?" .Cd "ukbd*at uhidev?" .Cd "ums* at uhidev?" .Cd "umstc* at uhidev?" @@ -73,6 +74,7 @@ only dispatches data to them based on the report id. .Xr ucycom 4 , .Xr ugold 4 , .Xr uhid 4 , +.Xr uhidpp 4 , .Xr ukbd 4 , .Xr ums 4 , .Xr umstc 4 , diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4 new file mode 100644 index 000..4c78380c35b --- /dev/null +++ share/man/man4/uhidpp.4 @@ -0,0 +1,48 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2021 Anton Lindqvsit +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt UHIDPP 4 +.Os +.Sh NAME +.Nm uhidpp +.Nd Logitech HID++ devices +.Sh SYNOPSIS +.Cd "uhidpp* at uhidev?" +.Sh DESCRIPTION +The +.Nm +driver provides support for Logitech HID++ devices. +It exposes a collection of battery sensor values which are made available +through the +.Xr sysctl 8 +interface. +.Sh SEE ALSO +.Xr intro 4 , +.Xr uhidev 4 , +.Xr usb 4 , +.Xr sensorsd 8 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 6.9 . +.Sh AUTHORS +The +.Nm +driver was written by +.An Anton Lindqvist Aq Mt an...@opensd.org . diff --git share/man/man4/usb.4 share/man/man4/usb.4 index 520f46265e0..b58190539e3 100644 --- share/man/man4/usb.4 +++ share/man/man4/usb.4 @@ -255,6 +255,8 @@ TEMPer gold HID thermometer and hygrometer Generic driver for Human Interface Devices .It Xr uhidev 4 Base driver for all Human Interface Devices +.It Xr uhidpp 4 +Logitech HID++ devices .It Xr ukbd 4 USB keyboards that follow the boot protocol .It Xr ums 4 diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC index 45b3a9b6e66..00ac52adcd6 100644 --- sys/arch/amd64/conf/GENERIC +++ sys/arch/amd64/conf/GENERIC @@ -288,6 +288,7 @@ uhid* at uhidev? # USB generic HID support fido* at uhidev? # FIDO/U2F security key support upd* at uhidev? # USB Power Devices sensors umstc* at uhidev? # Microsoft Surface Type C
Re: uhidpp(4): logitech hid++ device driver
Ping On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote: > Hi, > Here's a new driver for Logitech HID++ devices, currently limited to > exposing battery sensors. Here's an example using a Logitech M330 mouse: > > $ dmesg | grep uhidpp > uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 > $ sysctl hw.sensors.uhidpp0 > hw.sensors.uhidpp0.raw0=2 (battery levels) > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > The raw0 sensor reflects number of available battery levels, the > resolution on this device is not great... > > Most of the code is derived from the hid-logitech-hidpp Linux driver. > Some assorted notes: > > * In order to communicate with the device inside the attach routine, I > had to wire up the interrupt handler as this by default is done first > once the same attach routine has returned. Hence the introduction of > uhidev_set_intr(). If this is an acceptable approach, this can go in > as a separate commit. > > * I kept using the `return -errno' convention from the Linux driver in > order to distingush errors from the hardware, which are always > positive. > > I you happen to have a Logitech HID++ device and run into any > problem(s), please enable UHIDPP_DEBUG and send me the output. > > Comments? OK? > > diff --git share/man/man4/Makefile share/man/man4/Makefile > index 02af7a47a44..74a4e17d7dc 100644 > --- share/man/man4/Makefile > +++ share/man/man4/Makefile > @@ -83,8 +83,8 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ > ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ > - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ > - uk.4 ukbd.4 \ > + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ > + uipaq.4 uk.4 ukbd.4 \ > ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \ > ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \ > uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \ > diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 > index f0a6776a27b..d264935a65c 100644 > --- share/man/man4/uhidev.4 > +++ share/man/man4/uhidev.4 > @@ -40,6 +40,7 @@ > .Cd "ucycom* at uhidev?" > .Cd "ugold* at uhidev?" > .Cd "uhid*at uhidev?" > +.Cd "uhidpp* at uhidev?" > .Cd "ukbd*at uhidev?" > .Cd "ums* at uhidev?" > .Cd "umstc* at uhidev?" > @@ -73,6 +74,7 @@ only dispatches data to them based on the report id. > .Xr ucycom 4 , > .Xr ugold 4 , > .Xr uhid 4 , > +.Xr uhidpp 4 , > .Xr ukbd 4 , > .Xr ums 4 , > .Xr umstc 4 , > diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4 > new file mode 100644 > index 000..4c78380c35b > --- /dev/null > +++ share/man/man4/uhidpp.4 > @@ -0,0 +1,48 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2021 Anton Lindqvsit > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate$ > +.Dt UHIDPP 4 > +.Os > +.Sh NAME > +.Nm uhidpp > +.Nd Logitech HID++ devices > +.Sh SYNOPSIS > +.Cd "uhidpp* at uhidev?" > +.Sh DESCRIPTION > +The > +.Nm > +driver provides support for Logitech HID++ devices. > +It exposes a collection of battery sensor values which are made available > +through the > +.Xr sysctl 8 > +interface. > +.Sh SEE ALSO > +.Xr intro 4 , > +.Xr uhidev 4 , > +.Xr usb 4 , > +.Xr sensorsd 8 , > +.Xr sysctl 8 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Ox 6.9 . > +.Sh AUTHORS > +The > +.Nm > +driver was written by > +.An Anton Lindqvist Aq Mt an...@opensd.org . > diff --git share/man/man4/usb.4 share/man/man4/usb.4 > index 520f46265e0..b58190539e3 100644 > --- share/man/man4/usb.4 > +++ share/man/man4/usb.4 > @@ -255,6 +255,8 @@ TEMPer gold HID thermometer and hygrometer > Generic driver for Human Interface Devices > .It Xr uhidev 4 > Base driver for all Human Interface Devices > +.It Xr uhidpp 4 > +Logitech HID++ devices > .It Xr ukbd 4 > USB keyboards that follow the boot protocol > .It Xr ums 4 > diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC > index 45b3a9b6e66..00ac52adcd6 100644 > --- sys/arch
Re: uhidpp(4): logitech hid++ device driver
Hello Anton, either I failed to use git or then files have changed since the first patch: $ git apply -p0 --check hid_plusplus.patch error: patch failed: share/man/man4/Makefile:83 error: share/man/man4/Makefile: patch does not apply error: patch failed: share/man/man4/uhidev.4:40 error: share/man/man4/uhidev.4: patch does not apply error: patch failed: share/man/man4/usb.4:255 error: share/man/man4/usb.4: patch does not apply error: patch failed: sys/arch/amd64/conf/GENERIC:288 error: sys/arch/amd64/conf/GENERIC: patch does not apply error: patch failed: sys/dev/usb/uhidev.c:950 error: sys/dev/usb/uhidev.c: patch does not apply error: sys/dev/usb/uhidpp.c: already exists in working directory Running that on root of src. A quick peek on sys/dev/usb/uhidev.c file shows that it has been modified on 25th of Jan so I'd guess the patch needs to be updated. Thanks in advance! Been thinking to have a look on that protocol but since I am no HW hacker I've postponed that for years :) -- Kind regards, Ville On Fri, 29 Jan 2021 at 09:21, Anton Lindqvist wrote: > > Ping > > On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote: > > Hi, > > Here's a new driver for Logitech HID++ devices, currently limited to > > exposing battery sensors. Here's an example using a Logitech M330 mouse: > > > > $ dmesg | grep uhidpp > > uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 > > $ sysctl hw.sensors.uhidpp0 > > hw.sensors.uhidpp0.raw0=2 (battery levels) > > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > > > The raw0 sensor reflects number of available battery levels, the > > resolution on this device is not great... > > > > Most of the code is derived from the hid-logitech-hidpp Linux driver. > > Some assorted notes: > > > > * In order to communicate with the device inside the attach routine, I > > had to wire up the interrupt handler as this by default is done first > > once the same attach routine has returned. Hence the introduction of > > uhidev_set_intr(). If this is an acceptable approach, this can go in > > as a separate commit. > > > > * I kept using the `return -errno' convention from the Linux driver in > > order to distingush errors from the hardware, which are always > > positive. > > > > I you happen to have a Logitech HID++ device and run into any > > problem(s), please enable UHIDPP_DEBUG and send me the output. > > > > Comments? OK? > > > > diff --git share/man/man4/Makefile share/man/man4/Makefile > > index 02af7a47a44..74a4e17d7dc 100644 > > --- share/man/man4/Makefile > > +++ share/man/man4/Makefile > > @@ -83,8 +83,8 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > > txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ > > ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > > udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ > > - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ > > - uk.4 ukbd.4 \ > > + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ > > + uipaq.4 uk.4 ukbd.4 \ > > ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \ > > ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \ > > uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \ > > diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 > > index f0a6776a27b..d264935a65c 100644 > > --- share/man/man4/uhidev.4 > > +++ share/man/man4/uhidev.4 > > @@ -40,6 +40,7 @@ > > .Cd "ucycom* at uhidev?" > > .Cd "ugold* at uhidev?" > > .Cd "uhid*at uhidev?" > > +.Cd "uhidpp* at uhidev?" > > .Cd "ukbd*at uhidev?" > > .Cd "ums* at uhidev?" > > .Cd "umstc* at uhidev?" > > @@ -73,6 +74,7 @@ only dispatches data to them based on the report id. > > .Xr ucycom 4 , > > .Xr ugold 4 , > > .Xr uhid 4 , > > +.Xr uhidpp 4 , > > .Xr ukbd 4 , > > .Xr ums 4 , > > .Xr umstc 4 , > > diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4 > > new file mode 100644 > > index 000..4c78380c35b > > --- /dev/null > > +++ share/man/man4/uhidpp.4 > > @@ -0,0 +1,48 @@ > > +.\" $OpenBSD$ > > +.\" > > +.\" Copyright (c) 2021 Anton Lindqvsit > > +.\" > > +.\" Permission to use, copy, modify, and distribute this software for any > > +.\" purpose with or without fee is hereby granted, provided that the above > > +.\" copyright notice and this permission notice appear in all copies. > > +.\" > > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL > > WARRANTIES > > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > > +.\" OR IN CONNECTION WI
Re: uhidpp(4): logitech hid++ device driver
On Fri, Jan 29, 2021 at 07:23:37PM +0200, Ville Valkonen wrote: > Hello Anton, > > either I failed to use git or then files have changed since the first patch: > $ git apply -p0 --check hid_plusplus.patch > error: patch failed: share/man/man4/Makefile:83 > error: share/man/man4/Makefile: patch does not apply > error: patch failed: share/man/man4/uhidev.4:40 > error: share/man/man4/uhidev.4: patch does not apply > error: patch failed: share/man/man4/usb.4:255 > error: share/man/man4/usb.4: patch does not apply > error: patch failed: sys/arch/amd64/conf/GENERIC:288 > error: sys/arch/amd64/conf/GENERIC: patch does not apply > error: patch failed: sys/dev/usb/uhidev.c:950 > error: sys/dev/usb/uhidev.c: patch does not apply > error: sys/dev/usb/uhidpp.c: already exists in working directory > > Running that on root of src. A quick peek on sys/dev/usb/uhidev.c file > shows that it has been modified on 25th of Jan so I'd guess the patch > needs to be updated. > > Thanks in advance! Been thinking to have a look on that protocol but > since I am no HW hacker I've postponed that for years :) Rebased diff, should apply using either git-apply or patch. diff --git share/man/man4/Makefile share/man/man4/Makefile index 70e62135237..f893825ceb9 100644 --- share/man/man4/Makefile +++ share/man/man4/Makefile @@ -83,8 +83,8 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ - ujoy.4 uk.4 ukbd.4 \ + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ + uipaq.4 ujoy.4 uk.4 ukbd.4 ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \ ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \ uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \ diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 index 06911ddef29..aa1efbea710 100644 --- share/man/man4/uhidev.4 +++ share/man/man4/uhidev.4 @@ -40,6 +40,7 @@ .Cd "ucycom* at uhidev?" .Cd "ugold* at uhidev?" .Cd "uhid*at uhidev?" +.Cd "uhidpp* at uhidev?" .Cd "ujoy*at uhidev?" .Cd "ukbd*at uhidev?" .Cd "ums* at uhidev?" @@ -74,6 +75,7 @@ only dispatches data to them based on the report id. .Xr ucycom 4 , .Xr ugold 4 , .Xr uhid 4 , +.Xr uhidpp 4 , .Xr ujoy 4 , .Xr ukbd 4 , .Xr ums 4 , diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4 new file mode 100644 index 000..4c78380c35b --- /dev/null +++ share/man/man4/uhidpp.4 @@ -0,0 +1,48 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2021 Anton Lindqvsit +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt UHIDPP 4 +.Os +.Sh NAME +.Nm uhidpp +.Nd Logitech HID++ devices +.Sh SYNOPSIS +.Cd "uhidpp* at uhidev?" +.Sh DESCRIPTION +The +.Nm +driver provides support for Logitech HID++ devices. +It exposes a collection of battery sensor values which are made available +through the +.Xr sysctl 8 +interface. +.Sh SEE ALSO +.Xr intro 4 , +.Xr uhidev 4 , +.Xr usb 4 , +.Xr sensorsd 8 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 6.9 . +.Sh AUTHORS +The +.Nm +driver was written by +.An Anton Lindqvist Aq Mt an...@opensd.org . diff --git share/man/man4/usb.4 share/man/man4/usb.4 index 8b9e3ffdc3c..245d01cdef4 100644 --- share/man/man4/usb.4 +++ share/man/man4/usb.4 @@ -255,6 +255,8 @@ TEMPer gold HID thermometer and hygrometer Generic driver for Human Interface Devices .It Xr uhidev 4 Base driver for all Human Interface Devices +.It Xr uhidpp 4 +Logitech HID++ devices .It Xr ujoy 4 USB joysticks/gamecontrollers .It Xr ukbd 4 diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC index ffa1b4a497c..643e6bd0ba1 100644 --- sys/arch/amd64/conf/GENERIC +++ sys/arch/amd64/conf/GENERIC @@ -289,6 +289,7 @@ fido* at uhidev? # FIDO/U2F security key support ujoy* at uhidev? # USB joystick/gamecontroller support upd* at uhidev? # USB Power Devices sensors umstc* at uhidev? # Microsoft Surface Type Cover +uhidpp*at uhidev?
Re: uhidpp(4): logitech hid++ device driver
Hi, I have a bit oldish Logitech M705 mouse, bought around 2010-2011. Regarding the dmesg (on below) I can see it gets attached correctly to uhiddp0 but doesn't report battery levels. Here's the line from dmesg: uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device 2 keyboard "K750" serial xx-xx-xx-xx. And corresponding sysctl values: hw.sensors.uhidpp0.raw0=unknown (battery levels) hw.sensors.uhidpp0.raw1=unknown (battery levels) hw.sensors.uhidpp0.percent0=unknown (battery level) hw.sensors.uhidpp0.percent1=unknown (battery level) Not sure if censoring of serial has any value, though. On Ubuntu battery levels are detected correctly so I could probably take a USB dump with Wireshark and compare the differences. And here's sysctl.sensors & dmesg differences (before <-> after the patch): --- sysctl_before.txt Fri Jan 29 21:31:44 2021 +++ sysctl_after.txtFri Jan 29 21:34:50 2021 @@ -5,39 +5,43 @@ hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:c01774372c2b714a hw.diskcount=1 -hw.sensors.cpu0.temp0=54.00 degC +hw.sensors.cpu0.temp0=50.00 degC hw.sensors.acpibtn0.indicator0=On (lid open) hw.sensors.acpibat0.volt0=11.10 VDC (voltage) hw.sensors.acpibat0.volt1=12.38 VDC (current voltage) hw.sensors.acpibat0.power0=0.00 W (rate) -hw.sensors.acpibat0.watthour0=15.64 Wh (last full capacity) +hw.sensors.acpibat0.watthour0=15.62 Wh (last full capacity) hw.sensors.acpibat0.watthour1=0.78 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat0.watthour3=15.62 Wh (remaining capacity), OK hw.sensors.acpibat0.watthour4=23.20 Wh (design capacity) -hw.sensors.acpibat0.raw0=0 (battery idle), OK +hw.sensors.acpibat0.raw0=0 (battery full), OK hw.sensors.acpibat1.volt0=11.10 VDC (voltage) hw.sensors.acpibat1.volt1=12.32 VDC (current voltage) hw.sensors.acpibat1.power0=0.00 W (rate) -hw.sensors.acpibat1.watthour0=16.53 Wh (last full capacity) +hw.sensors.acpibat1.watthour0=16.52 Wh (last full capacity) hw.sensors.acpibat1.watthour1=0.83 Wh (warning capacity) hw.sensors.acpibat1.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat1.watthour3=16.52 Wh (remaining capacity), OK hw.sensors.acpibat1.watthour4=23.20 Wh (design capacity) -hw.sensors.acpibat1.raw0=0 (battery idle), OK +hw.sensors.acpibat1.raw0=0 (battery full), OK hw.sensors.acpiac0.indicator0=On (power supply) -hw.sensors.acpithinkpad0.temp0=55.00 degC -hw.sensors.acpithinkpad0.temp1=55.00 degC -hw.sensors.acpithinkpad0.temp2=55.00 degC -hw.sensors.acpithinkpad0.temp3=55.00 degC -hw.sensors.acpithinkpad0.temp4=55.00 degC -hw.sensors.acpithinkpad0.temp5=55.00 degC -hw.sensors.acpithinkpad0.temp6=55.00 degC -hw.sensors.acpithinkpad0.temp7=55.00 degC -hw.sensors.acpithinkpad0.fan0=4112 RPM +hw.sensors.acpithinkpad0.temp0=51.00 degC +hw.sensors.acpithinkpad0.temp1=51.00 degC +hw.sensors.acpithinkpad0.temp2=51.00 degC +hw.sensors.acpithinkpad0.temp3=51.00 degC +hw.sensors.acpithinkpad0.temp4=51.00 degC +hw.sensors.acpithinkpad0.temp5=51.00 degC +hw.sensors.acpithinkpad0.temp6=51.00 degC +hw.sensors.acpithinkpad0.temp7=51.00 degC +hw.sensors.acpithinkpad0.fan0=3659 RPM hw.sensors.acpithinkpad0.indicator0=Off (port replicator), UNKNOWN -hw.sensors.acpitz0.temp0=55.00 degC (zone temperature) -hw.sensors.pchtemp0.temp0=62.50 degC +hw.sensors.acpitz0.temp0=51.00 degC (zone temperature) +hw.sensors.pchtemp0.temp0=58.00 degC +hw.sensors.uhidpp0.raw0=unknown (battery levels) +hw.sensors.uhidpp0.raw1=unknown (battery levels) +hw.sensors.uhidpp0.percent0=unknown (battery level) +hw.sensors.uhidpp0.percent1=unknown (battery level) hw.cpuspeed=500 hw.setperf=0 hw.vendor=LENOVO @@ -46,7 +50,7 @@ hw.version=ThinkPad X250 hw.serialno=PC031KCD hw.uuid=816b2e2f-d253-cb11-9791-8821c15b5a68 hw.physmem=8277995520 -hw.usermem=8233095168 +hw.usermem=8221360128 hw.ncpufound=2 hw.allowpowerdown=1 hw.perfpolicy=auto And: --- dmesg_before.txt2021-01-29 21:38:10.0 +0200 +++ dmesg_after.txt 2021-01-29 22:03:30.341216215 +0200 @@ -1,7 +1,7 @@ -OpenBSD 6.8-current (GENERIC.MP) #301: Fri Jan 29 02:04:27 MST 2021 - dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP +OpenBSD 6.8-current (GENERIC.MP) #0: Fri Jan 29 21:30:07 EET 2021 +wee...@weezel.lan:/obsd_src/sys/arch/amd64/compile/GENERIC.MP real mem = 8277995520 (7894MB) -avail mem = 8011780096 (7640MB) +avail mem = 8011751424 (7640MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets @@ -18,7 +18,7 @@ acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) -cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.55 MHz, 06-3d-04 +cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.63 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36 ,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAI T,DS- CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,P
Re: uhidpp(4): logitech hid++ device driver
On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > Hi, > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > Regarding the dmesg (on below) I can see it gets attached correctly to > uhiddp0 but doesn't report battery levels. Here's the line from dmesg: > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device 2 keyboard > "K750" serial xx-xx-xx-xx. > And corresponding sysctl values: > hw.sensors.uhidpp0.raw0=unknown (battery levels) > hw.sensors.uhidpp0.raw1=unknown (battery levels) > hw.sensors.uhidpp0.percent0=unknown (battery level) > hw.sensors.uhidpp0.percent1=unknown (battery level) > > Not sure if censoring of serial has any value, though. Glad to see it attaches fine to a receiver with more than one device paired. I only have one device myself and have therefore never been enable to verify this. Could you enable UHIDPP_DEBUG and send me the output? > On Ubuntu battery levels are detected correctly so I could probably > take a USB dump with Wireshark and compare the differences. Taking a USB dump on your Linux machine would be very helpful.
Re: uhidpp(4): logitech hid++ device driver
On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > > Hi, > > > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > > Regarding the dmesg (on below) I can see it gets attached correctly > > to > > uhiddp0 but doesn't report battery levels. Here's the line from > > dmesg: > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device > > 2 keyboard "K750" serial xx-xx-xx-xx. > > And corresponding sysctl values: > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > Not sure if censoring of serial has any value, though. > > Glad to see it attaches fine to a receiver with more than one device > paired. I only have one device myself and have therefore never been > enable to verify this. > > Could you enable UHIDPP_DEBUG and send me the output? > > > On Ubuntu battery levels are detected correctly so I could probably > > take a USB dump with Wireshark and compare the differences. > > Taking a USB dump on your Linux machine would be very helpful. Hi, Yes. Also remembered that you were mentioning about the debug flag but completely forgot that while testing. Then just before going to sleep recalled the debug flag. Here are the results with debug enabled: uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/12.10 addr 3 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/12.10 addr 3 uhidev1: iclass 3/1, 8 report ids ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir wsmouse2 at ums0 mux 0 uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/12.10 addr 3 uhidev2: iclass 3/0, 33 report ids uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 00 00] hidpp_send_report: 10 ff 83 b5 [20 00 00] uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 00 00] hidpp_send_report: 10 ff 83 b5 [40 00 00] uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 00 00] device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 b5 [31 00 00] uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 00 00] hidpp_send_report: 10 ff 83 b5 [21 00 00] uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 00 00] hidpp_send_report: 10 ff 83 b5 [41 00 00] uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 00 00] , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff 83 b5 [32 00 00] uhidpp_intr: 10 ff 8f 83 [b5 03 00] hidpp_send_report: 10 ff 83 b5 [33 00 00] uhidpp_intr: 10 ff 8f 83 [b5 03 00] hidpp_send_report: 10 ff 83 b5 [34 00 00] uhidpp_intr: 10 ff 8f 83 [b5 03 00] hidpp_send_report: 10 ff 83 b5 [35 00 00] uhidpp_intr: 10 ff 8f 83 [b5 03 00] hidpp_send_report: 10 ff 80 00 [10 09 00] uhidpp_intr: 10 ff 80 00 [00 00 00] That's when the mouse was off. When I switched on the mouse kernel panicked. I couldn't break into DDB or alternatively failed to type correct commands blindly. Eventually had to shutdown the system by pressing the power button. Picture of the panic is here: https://imgur.com/a/QRAD5v1 Btw. Time has passed since my previous kernel compile. I saw the procedure has changed a bit since then. I initially tried to compile debug flags by prepending `option UHIDPP_DEBUG` to sys/arch/amd64/compile/GENERIC.MP but couldn't see debug lines in dmesg. By doing the "old way" I got the debug lines: cd arch/amd64/conf cp GENERIC.MP HIDPP.MP # Add debug flags at this point config HIDPP.MP and compiling as usual. Is this the correct way to do it? I'll do the Wireshark later in the evening. -- Regards, Ville
Re: uhidpp(4): logitech hid++ device driver
On Sat, 2021-01-30 at 13:18 +0200, Ville Valkonen wrote: > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > > > Hi, > > > > > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > > > Regarding the dmesg (on below) I can see it gets attached > > > correctly > > > to > > > uhiddp0 but doesn't report battery levels. Here's the line from > > > dmesg: > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, > > > device > > > 2 keyboard "K750" serial xx-xx-xx-xx. > > > And corresponding sysctl values: > > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > > > Not sure if censoring of serial has any value, though. > > > > Glad to see it attaches fine to a receiver with more than one > > device > > paired. I only have one device myself and have therefore never been > > enable to verify this. > > > > Could you enable UHIDPP_DEBUG and send me the output? > > > > > On Ubuntu battery levels are detected correctly so I could > > > probably > > > take a USB dump with Wireshark and compare the differences. > > > > Taking a USB dump on your Linux machine would be very helpful. > > Hi, > > Yes. Also remembered that you were mentioning about the debug flag > but > completely forgot that while testing. Then just before going to sleep > recalled the debug flag. Here are the results with debug enabled: > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB > Receiver" rev 2.00/12.10 addr 3 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd1 at ukbd0 mux 1 > wskbd1: connecting to wsdisplay0 > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB > Receiver" rev 2.00/12.10 addr 3 > uhidev1: iclass 3/1, 8 report ids > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > wsmouse2 at ums0 mux 0 > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB > Receiver" rev 2.00/12.10 addr 3 > uhidev2: iclass 3/0, 33 report ids > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 > 00 00] > hidpp_send_report: 10 ff 83 b5 [20 00 00] > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 > 00 00] > hidpp_send_report: 10 ff 83 b5 [40 00 00] > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 > 00 00] > device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 > b5 [31 00 00] > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 > 00 00] > hidpp_send_report: 10 ff 83 b5 [21 00 00] > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 > 00 00] > hidpp_send_report: 10 ff 83 b5 [41 00 00] > uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 > 00 00] > , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff > 83 b5 [32 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [33 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [34 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [35 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 80 00 [10 09 00] > uhidpp_intr: 10 ff 80 00 [00 00 00] > > > That's when the mouse was off. When I switched on the mouse kernel > panicked. I couldn't break into DDB or alternatively failed to type > correct commands blindly. Eventually had to shutdown the system by > pressing the power button. Picture of the panic is here: > https://imgur.com/a/QRAD5v1 > > Btw. Time has passed since my previous kernel compile. I saw the > procedure has changed a bit since then. I initially tried to compile > debug flags by prepending `option UHIDPP_DEBUG` to > sys/arch/amd64/compile/GENERIC.MP but couldn't see debug lines in > dmesg. By doing the "old way" I got the debug lines: > cd arch/amd64/conf > cp GENERIC.MP HIDPP.MP > # Add debug flags at this point > config HIDPP.MP > and compiling as usual. Is this the correct way to do it? > > I'll do the Wireshark later in the evening. > > -- > Regards, > Ville Hello, please find the link covering the USB capture on Ubuntu: https://paste.c-net.org/FieryExperts What I did: - Turned mouse on - Moved it around - Clicked left, middle and right buttons (not in that order) If you need more more information, please let me know. -- Kind regards, Ville
Re: uhidpp(4): logitech hid++ device driver
On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote: > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > > > Hi, > > > > > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > > > Regarding the dmesg (on below) I can see it gets attached correctly > > > to > > > uhiddp0 but doesn't report battery levels. Here's the line from > > > dmesg: > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device > > > 2 keyboard "K750" serial xx-xx-xx-xx. > > > And corresponding sysctl values: > > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > > > Not sure if censoring of serial has any value, though. > > > > Glad to see it attaches fine to a receiver with more than one device > > paired. I only have one device myself and have therefore never been > > enable to verify this. > > > > Could you enable UHIDPP_DEBUG and send me the output? > > > > > On Ubuntu battery levels are detected correctly so I could probably > > > take a USB dump with Wireshark and compare the differences. > > > > Taking a USB dump on your Linux machine would be very helpful. > > Hi, > > Yes. Also remembered that you were mentioning about the debug flag but > completely forgot that while testing. Then just before going to sleep > recalled the debug flag. Here are the results with debug enabled: > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB Receiver" > rev 2.00/12.10 addr 3 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd1 at ukbd0 mux 1 > wskbd1: connecting to wsdisplay0 > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB Receiver" > rev 2.00/12.10 addr 3 > uhidev1: iclass 3/1, 8 report ids > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > wsmouse2 at ums0 mux 0 > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/12.10 addr 3 > uhidev2: iclass 3/0, 33 report ids > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [20 00 00] > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [40 00 00] > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 00 00] > device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 b5 [31 > 00 00] > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [21 00 00] > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [41 00 00] > uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 00 00] > , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff 83 b5 > [32 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [33 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [34 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [35 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 80 00 [10 09 00] > uhidpp_intr: 10 ff 80 00 [00 00 00] > > > That's when the mouse was off. When I switched on the mouse kernel > panicked. I couldn't break into DDB or alternatively failed to type > correct commands blindly. Eventually had to shutdown the system by > pressing the power button. Picture of the panic is here: > https://imgur.com/a/QRAD5v1 Thanks for the report. Updated diff which should fix the panic: * Fix a bug in uhidpp_is_notification() causing notifications to be detected as responses * Delay installation of sensors * Enable uhidpp on all architectures >From the panic, I can see that your device only supports HID++ 1.0. Querying the battery status works a bit differently compared to HID++ 2.0. I don't have a 1.0 device but can probably give this a try if you're willing to try out future diffs. However, it would ease development by getting this in and continue development in tree. Anyone willing to ok? > Btw. Time has passed since my previous kernel compile. I saw the > procedure has changed a bit since then. I initially tried to compile > debug flags by prepending `option UHIDPP_DEBUG` to > sys/arch/amd64/compile/GENERIC.MP but couldn't see debug lines in > dmesg. By doing the "old way" I got the debug lines: > cd arch/amd64/conf > cp GENERIC.MP HIDPP.MP > # Add debug flags at this point > config HIDPP.MP > and compiling as usual. Is this the correct way to do it? For debug fl
Re: uhidpp(4): logitech hid++ device driver
On Tue, Feb 02, 2021 at 08:23:29AM +0100, Anton Lindqvist wrote: > On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote: > > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > > > > Hi, > > > > > > > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > > > > Regarding the dmesg (on below) I can see it gets attached correctly > > > > to > > > > uhiddp0 but doesn't report battery levels. Here's the line from > > > > dmesg: > > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device > > > > 2 keyboard "K750" serial xx-xx-xx-xx. > > > > And corresponding sysctl values: > > > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > > > > > Not sure if censoring of serial has any value, though. > > > > > > Glad to see it attaches fine to a receiver with more than one device > > > paired. I only have one device myself and have therefore never been > > > enable to verify this. > > > > > > Could you enable UHIDPP_DEBUG and send me the output? > > > > > > > On Ubuntu battery levels are detected correctly so I could probably > > > > take a USB dump with Wireshark and compare the differences. > > > > > > Taking a USB dump on your Linux machine would be very helpful. > > > > Hi, > > > > Yes. Also remembered that you were mentioning about the debug flag but > > completely forgot that while testing. Then just before going to sleep > > recalled the debug flag. Here are the results with debug enabled: > > > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB Receiver" > > rev 2.00/12.10 addr 3 > > uhidev0: iclass 3/1 > > ukbd0 at uhidev0: 8 variable keys, 6 key codes > > wskbd1 at ukbd0 mux 1 > > wskbd1: connecting to wsdisplay0 > > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB Receiver" > > rev 2.00/12.10 addr 3 > > uhidev1: iclass 3/1, 8 report ids > > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > > wsmouse2 at ums0 mux 0 > > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB Receiver" > > rev 2.00/12.10 addr 3 > > uhidev2: iclass 3/0, 33 report ids > > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] > > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [20 00 00] > > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [40 00 00] > > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 00 00] > > device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 b5 [31 > > 00 00] > > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [21 00 00] > > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [41 00 00] > > uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 00 00] > > , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff 83 b5 > > [32 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 83 b5 [33 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 83 b5 [34 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 83 b5 [35 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 80 00 [10 09 00] > > uhidpp_intr: 10 ff 80 00 [00 00 00] > > > > > > That's when the mouse was off. When I switched on the mouse kernel > > panicked. I couldn't break into DDB or alternatively failed to type > > correct commands blindly. Eventually had to shutdown the system by > > pressing the power button. Picture of the panic is here: > > https://imgur.com/a/QRAD5v1 > > Thanks for the report. Updated diff which should fix the panic: > > * Fix a bug in uhidpp_is_notification() causing notifications to be > detected as responses > > * Delay installation of sensors > > * Enable uhidpp on all architectures > > From the panic, I can see that your device only supports HID++ 1.0. > Querying the battery status works a bit differently compared to HID++ > 2.0. I don't have a 1.0 device but can probably give this a try if > you're willing to try out future diffs. > > However, it would ease development by getting this in and continue > development in tree. Anyone willing to ok? The reason why I'm currently reluctant to ok this is because of the uhidev_set_intr() part which you introduce with this diff, and I don't fully understand. I can understand that for this device you seem to have the need to state comman
Re: uhidpp(4): logitech hid++ device driver
On Tue, Feb 02, 2021 at 01:00:48PM +0100, Marcus Glocker wrote: > On Tue, Feb 02, 2021 at 08:23:29AM +0100, Anton Lindqvist wrote: > > > On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote: > > > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > > > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > > > > > Hi, > > > > > > > > > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > > > > > Regarding the dmesg (on below) I can see it gets attached correctly > > > > > to > > > > > uhiddp0 but doesn't report battery levels. Here's the line from > > > > > dmesg: > > > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device > > > > > 2 keyboard "K750" serial xx-xx-xx-xx. > > > > > And corresponding sysctl values: > > > > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > > > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > > > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > > > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > > > > > > > Not sure if censoring of serial has any value, though. > > > > > > > > Glad to see it attaches fine to a receiver with more than one device > > > > paired. I only have one device myself and have therefore never been > > > > enable to verify this. > > > > > > > > Could you enable UHIDPP_DEBUG and send me the output? > > > > > > > > > On Ubuntu battery levels are detected correctly so I could probably > > > > > take a USB dump with Wireshark and compare the differences. > > > > > > > > Taking a USB dump on your Linux machine would be very helpful. > > > > > > Hi, > > > > > > Yes. Also remembered that you were mentioning about the debug flag but > > > completely forgot that while testing. Then just before going to sleep > > > recalled the debug flag. Here are the results with debug enabled: > > > > > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB > > > Receiver" rev 2.00/12.10 addr 3 > > > uhidev0: iclass 3/1 > > > ukbd0 at uhidev0: 8 variable keys, 6 key codes > > > wskbd1 at ukbd0 mux 1 > > > wskbd1: connecting to wsdisplay0 > > > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB > > > Receiver" rev 2.00/12.10 addr 3 > > > uhidev1: iclass 3/1, 8 report ids > > > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > > > wsmouse2 at ums0 mux 0 > > > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > > > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > > > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > > > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB > > > Receiver" rev 2.00/12.10 addr 3 > > > uhidev2: iclass 3/0, 33 report ids > > > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] > > > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 00 00] > > > hidpp_send_report: 10 ff 83 b5 [20 00 00] > > > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 00 00] > > > hidpp_send_report: 10 ff 83 b5 [40 00 00] > > > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 00 00] > > > device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 b5 > > > [31 00 00] > > > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 00 00] > > > hidpp_send_report: 10 ff 83 b5 [21 00 00] > > > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 00 00] > > > hidpp_send_report: 10 ff 83 b5 [41 00 00] > > > uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 00 00] > > > , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff 83 > > > b5 [32 00 00] > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > hidpp_send_report: 10 ff 83 b5 [33 00 00] > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > hidpp_send_report: 10 ff 83 b5 [34 00 00] > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > hidpp_send_report: 10 ff 83 b5 [35 00 00] > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > hidpp_send_report: 10 ff 80 00 [10 09 00] > > > uhidpp_intr: 10 ff 80 00 [00 00 00] > > > > > > > > > That's when the mouse was off. When I switched on the mouse kernel > > > panicked. I couldn't break into DDB or alternatively failed to type > > > correct commands blindly. Eventually had to shutdown the system by > > > pressing the power button. Picture of the panic is here: > > > https://imgur.com/a/QRAD5v1 > > > > Thanks for the report. Updated diff which should fix the panic: > > > > * Fix a bug in uhidpp_is_notification() causing notifications to be > > detected as responses > > > > * Delay installation of sensors > > > > * Enable uhidpp on all architectures > > > > From the panic, I can see that your device only supports HID++ 1.0. > > Querying the battery status works a bit differently compared to HID++ > > 2.0. I don't have a 1.0 device but can probably give this a try if > > you're willing to try out future diffs. > > > > However, it would ease development by getting this in and continue > > development
Re: uhidpp(4): logitech hid++ device driver
On Tue, Feb 02, 2021 at 07:55:17PM +0100, Anton Lindqvist wrote: [...] > > > However, it would ease development by getting this in and continue > > > development in tree. Anyone willing to ok? > > > > The reason why I'm currently reluctant to ok this is because of the > > uhidev_set_intr() part which you introduce with this diff, and I don't > > fully understand. I can understand that for this device you seem to > > have the need to state commands already in the attach code. > > > > But is sc_subdevs[repid] really only used for the interrupt handler? > > Shouldn't it be more generically called something like > > uhidev_set_repid, or uhidev_set_subdev or something like that? > > That's a fair point. How about uhidev_set_report_dev? Yes, I think that's less confusing. I gave it a spin here as well and couldn't face any regression so far. ok mglocker@ > diff --git share/man/man4/Makefile share/man/man4/Makefile > index 70e62135237..22db50677db 100644 > --- share/man/man4/Makefile > +++ share/man/man4/Makefile > @@ -83,8 +83,8 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ > ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ > - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ > - ujoy.4 uk.4 ukbd.4 \ > + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ > + uipaq.4 ujoy.4 uk.4 ukbd.4 \ > ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \ > ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \ > uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \ > diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 > index 06911ddef29..aa1efbea710 100644 > --- share/man/man4/uhidev.4 > +++ share/man/man4/uhidev.4 > @@ -40,6 +40,7 @@ > .Cd "ucycom* at uhidev?" > .Cd "ugold* at uhidev?" > .Cd "uhid*at uhidev?" > +.Cd "uhidpp* at uhidev?" > .Cd "ujoy*at uhidev?" > .Cd "ukbd*at uhidev?" > .Cd "ums* at uhidev?" > @@ -74,6 +75,7 @@ only dispatches data to them based on the report id. > .Xr ucycom 4 , > .Xr ugold 4 , > .Xr uhid 4 , > +.Xr uhidpp 4 , > .Xr ujoy 4 , > .Xr ukbd 4 , > .Xr ums 4 , > diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4 > new file mode 100644 > index 000..4c78380c35b > --- /dev/null > +++ share/man/man4/uhidpp.4 > @@ -0,0 +1,48 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2021 Anton Lindqvsit > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate$ > +.Dt UHIDPP 4 > +.Os > +.Sh NAME > +.Nm uhidpp > +.Nd Logitech HID++ devices > +.Sh SYNOPSIS > +.Cd "uhidpp* at uhidev?" > +.Sh DESCRIPTION > +The > +.Nm > +driver provides support for Logitech HID++ devices. > +It exposes a collection of battery sensor values which are made available > +through the > +.Xr sysctl 8 > +interface. > +.Sh SEE ALSO > +.Xr intro 4 , > +.Xr uhidev 4 , > +.Xr usb 4 , > +.Xr sensorsd 8 , > +.Xr sysctl 8 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Ox 6.9 . > +.Sh AUTHORS > +The > +.Nm > +driver was written by > +.An Anton Lindqvist Aq Mt an...@opensd.org . > diff --git share/man/man4/usb.4 share/man/man4/usb.4 > index 8b9e3ffdc3c..245d01cdef4 100644 > --- share/man/man4/usb.4 > +++ share/man/man4/usb.4 > @@ -255,6 +255,8 @@ TEMPer gold HID thermometer and hygrometer > Generic driver for Human Interface Devices > .It Xr uhidev 4 > Base driver for all Human Interface Devices > +.It Xr uhidpp 4 > +Logitech HID++ devices > .It Xr ujoy 4 > USB joysticks/gamecontrollers > .It Xr ukbd 4 > diff --git sys/arch/alpha/conf/GENERIC sys/arch/alpha/conf/GENERIC > index 05953f8e7cb..c789e5dacad 100644 > --- sys/arch/alpha/conf/GENERIC > +++ sys/arch/alpha/conf/GENERIC > @@ -108,6 +108,7 @@ ucom* at uslhcom? > uhid*at uhidev? # USB generic HID support > fido*at uhidev? # FIDO/U2F security key support > ujoy*at uhidev? # USB joystick/gamecontroller > support > +uhidpp* at uhidev? # Logitech HID++ Devices > upd* at uhidev? # USB Po
Re: uhidpp(4): logitech hid++ device driver
On Tue, 2021-02-02 at 19:55 +0100, Anton Lindqvist wrote: > On Tue, Feb 02, 2021 at 01:00:48PM +0100, Marcus Glocker wrote: > > On Tue, Feb 02, 2021 at 08:23:29AM +0100, Anton Lindqvist wrote: > > > > > On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote: > > > > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > > > > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I have a bit oldish Logitech M705 mouse, bought around > > > > > > 2010-2011. > > > > > > Regarding the dmesg (on below) I can see it gets attached > > > > > > correctly > > > > > > to > > > > > > uhiddp0 but doesn't report battery levels. Here's the line > > > > > > from > > > > > > dmesg: > > > > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, > > > > > > device > > > > > > 2 keyboard "K750" serial xx-xx-xx-xx. > > > > > > And corresponding sysctl values: > > > > > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > > > > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > > > > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > > > > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > > > > > > > > > Not sure if censoring of serial has any value, though. > > > > > > > > > > Glad to see it attaches fine to a receiver with more than one > > > > > device > > > > > paired. I only have one device myself and have therefore > > > > > never been > > > > > enable to verify this. > > > > > > > > > > Could you enable UHIDPP_DEBUG and send me the output? > > > > > > > > > > > On Ubuntu battery levels are detected correctly so I could > > > > > > probably > > > > > > take a USB dump with Wireshark and compare the differences. > > > > > > > > > > Taking a USB dump on your Linux machine would be very > > > > > helpful. > > > > > > > > Hi, > > > > > > > > Yes. Also remembered that you were mentioning about the debug > > > > flag but > > > > completely forgot that while testing. Then just before going to > > > > sleep > > > > recalled the debug flag. Here are the results with debug > > > > enabled: > > > > > > > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech > > > > USB Receiver" rev 2.00/12.10 addr 3 > > > > uhidev0: iclass 3/1 > > > > ukbd0 at uhidev0: 8 variable keys, 6 key codes > > > > wskbd1 at ukbd0 mux 1 > > > > wskbd1: connecting to wsdisplay0 > > > > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech > > > > USB Receiver" rev 2.00/12.10 addr 3 > > > > uhidev1: iclass 3/1, 8 report ids > > > > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > > > > wsmouse2 at ums0 mux 0 > > > > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > > > > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > > > > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > > > > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech > > > > USB Receiver" rev 2.00/12.10 addr 3 > > > > uhidev2: iclass 3/0, 33 report ids > > > > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] > > > > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 > > > > 00 00 00 00] > > > > hidpp_send_report: 10 ff 83 b5 [20 00 00] > > > > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 > > > > 00 00 00 00] > > > > hidpp_send_report: 10 ff 83 b5 [40 00 00] > > > > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 > > > > 00 00 00 00] > > > > device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 > > > > ff 83 b5 [31 00 00] > > > > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 > > > > 00 00 00 00] > > > > hidpp_send_report: 10 ff 83 b5 [21 00 00] > > > > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 > > > > 00 00 00 00] > > > > hidpp_send_report: 10 ff 83 b5 [41 00 00] > > > > uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 > > > > 00 00 00 00] > > > > , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: > > > > 10 ff 83 b5 [32 00 00] > > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > > hidpp_send_report: 10 ff 83 b5 [33 00 00] > > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > > hidpp_send_report: 10 ff 83 b5 [34 00 00] > > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > > hidpp_send_report: 10 ff 83 b5 [35 00 00] > > > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > > > hidpp_send_report: 10 ff 80 00 [10 09 00] > > > > uhidpp_intr: 10 ff 80 00 [00 00 00] > > > > > > > > > > > > That's when the mouse was off. When I switched on the mouse > > > > kernel > > > > panicked. I couldn't break into DDB or alternatively failed to > > > > type > > > > correct commands blindly. Eventually had to shutdown the system > > > > by > > > > pressing the power button. Picture of the panic is here: > > > > https://imgur.com/a/QRAD5v1 > > > > > > Thanks for the report. Updated diff which should fix the panic: > > > > > > * Fix a bug in uhidpp_is_notification() causing notifications to > > > be > > > detected as responses > >
Re: uhidpp(4): logitech hid++ device driver
On Tue, Feb 02, 2021 at 08:23:29AM +0100, Anton Lindqvist wrote: > On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote: > > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > > > > Hi, > > > > > > > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > > > > Regarding the dmesg (on below) I can see it gets attached correctly > > > > to > > > > uhiddp0 but doesn't report battery levels. Here's the line from > > > > dmesg: > > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device > > > > 2 keyboard "K750" serial xx-xx-xx-xx. > > > > And corresponding sysctl values: > > > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > > > > > Not sure if censoring of serial has any value, though. > > > > > > Glad to see it attaches fine to a receiver with more than one device > > > paired. I only have one device myself and have therefore never been > > > enable to verify this. > > > > > > Could you enable UHIDPP_DEBUG and send me the output? > > > > > > > On Ubuntu battery levels are detected correctly so I could probably > > > > take a USB dump with Wireshark and compare the differences. > > > > > > Taking a USB dump on your Linux machine would be very helpful. > > > > Hi, > > > > Yes. Also remembered that you were mentioning about the debug flag but > > completely forgot that while testing. Then just before going to sleep > > recalled the debug flag. Here are the results with debug enabled: > > > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB Receiver" > > rev 2.00/12.10 addr 3 > > uhidev0: iclass 3/1 > > ukbd0 at uhidev0: 8 variable keys, 6 key codes > > wskbd1 at ukbd0 mux 1 > > wskbd1: connecting to wsdisplay0 > > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB Receiver" > > rev 2.00/12.10 addr 3 > > uhidev1: iclass 3/1, 8 report ids > > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > > wsmouse2 at ums0 mux 0 > > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB Receiver" > > rev 2.00/12.10 addr 3 > > uhidev2: iclass 3/0, 33 report ids > > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] > > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [20 00 00] > > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [40 00 00] > > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 00 00] > > device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 b5 [31 > > 00 00] > > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [21 00 00] > > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 00 00] > > hidpp_send_report: 10 ff 83 b5 [41 00 00] > > uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 00 00] > > , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff 83 b5 > > [32 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 83 b5 [33 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 83 b5 [34 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 83 b5 [35 00 00] > > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > > hidpp_send_report: 10 ff 80 00 [10 09 00] > > uhidpp_intr: 10 ff 80 00 [00 00 00] > > > > > > That's when the mouse was off. When I switched on the mouse kernel > > panicked. I couldn't break into DDB or alternatively failed to type > > correct commands blindly. Eventually had to shutdown the system by > > pressing the power button. Picture of the panic is here: > > https://imgur.com/a/QRAD5v1 > > Thanks for the report. Updated diff which should fix the panic: > > * Fix a bug in uhidpp_is_notification() causing notifications to be > detected as responses > > * Delay installation of sensors > > * Enable uhidpp on all architectures > > >From the panic, I can see that your device only supports HID++ 1.0. > Querying the battery status works a bit differently compared to HID++ > 2.0. I don't have a 1.0 device but can probably give this a try if > you're willing to try out future diffs. > > However, it would ease development by getting this in and continue > development in tree. Anyone willing to ok? > > > Btw. Time has passed since my previous kernel compile. I saw the > > procedure has changed a bit since then. I initially tried to compile > > debug flags by prepending `option UHIDPP_DEBUG` to > > sys/arch/amd64/compile/GENERIC.MP but
Re: uhidpp(4): logitech hid++ device driver
On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote: > Hi, > Here's a new driver for Logitech HID++ devices, currently limited to > exposing battery sensors. Here's an example using a Logitech M330 mouse: > > $ dmesg | grep uhidpp > uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 > $ sysctl hw.sensors.uhidpp0 > hw.sensors.uhidpp0.raw0=2 (battery levels) > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK thanks anton, now that this got commited i realize i have a pair of devices: device 1 (M235 according to bottom) previously reported this in dmesg: uhidev0 at uhub0 port 2 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 uhidev1 at uhub0 port 2 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev1: iclass 3/1, 8 report ids ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir wsmouse2 at ums0 mux 0 uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev2: iclass 3/0, 33 report ids uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0 uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0 uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0 uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0 device 2 (M235 2nd gen according to bottom) previously reported this in dmesg (same thing, but the rev/addr values): uhidev1 at uhub0 port 4 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/24.07 addr 3 uhidev1: iclass 3/1 ukbd1 at uhidev1: 8 variable keys, 6 key codes wskbd2 at ukbd1 mux 1 uhidev2 at uhub0 port 4 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/24.07 addr 3 uhidev2: iclass 3/1, 8 report ids ums0 at uhidev2 reportid 2: 16 buttons, Z and W dir wsmouse2 at ums0 mux 0 uhid0 at uhidev2 reportid 3: input=4, output=0, feature=0 uhid1 at uhidev2 reportid 4: input=1, output=0, feature=0 uhid2 at uhidev2 reportid 8: input=1, output=0, feature=0 uhidev3 at uhub0 port 4 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/24.07 addr 3 uhidev3: iclass 3/0, 33 report ids uhid3 at uhidev3 reportid 16: input=6, output=6, feature=0 uhid4 at uhidev3 reportid 17: input=19, output=19, feature=0 uhid5 at uhidev3 reportid 32: input=14, output=14, feature=0 uhid6 at uhidev3 reportid 33: input=31, output=31, feature=0 now device 1/uhidev2 is properly identified by uhidpp: uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/12.03 addr 2 uhidev2: iclass 3/0, 33 report ids uhidpp0 at uhidev2 device 1 mouse "M325" serial 69-b1-af-84 and properly reports sensors: hw.sensors.uhidpp0.raw0=2 (battery levels) hw.sensors.uhidpp0.percent0=70.00% (battery level), OK and device2 (plugged on the same laptop so device renumbered) also works with uhidpp: uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/24.07 addr 2 uhidev2: iclass 3/0, 33 report ids uhidpp0 at uhidev2 device 1 mouse "Wireless Mouse" serial f3-94-18-8c same level reported in sensors for a different mouse (?): hw.sensors.uhidpp0.raw0=2 (battery levels) hw.sensors.uhidpp0.percent0=70.00% (battery level), OK let me know if you need more details/infos from those devices (usbdevs dumps etc..) i'll eventually look at adding support for uhidpp to upower so mouse battery levels can be reported in xfce4-power-manager and gnome, like it does on linux.. Thanks ! Landry
Re: uhidpp(4): logitech hid++ device driver
On Fri, Feb 05, 2021 at 10:36:34AM +0100, Landry Breuil wrote: > On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote: > > Hi, > > Here's a new driver for Logitech HID++ devices, currently limited to > > exposing battery sensors. Here's an example using a Logitech M330 mouse: > > > > $ dmesg | grep uhidpp > > uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 > > $ sysctl hw.sensors.uhidpp0 > > hw.sensors.uhidpp0.raw0=2 (battery levels) > > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > thanks anton, now that this got commited i realize i have a pair of > devices: > > device 1 (M235 according to bottom) previously reported this in dmesg: > > uhidev0 at uhub0 port 2 configuration 1 interface 0 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd1 at ukbd0 mux 1 > uhidev1 at uhub0 port 2 configuration 1 interface 1 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev1: iclass 3/1, 8 report ids > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > wsmouse2 at ums0 mux 0 > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev2: iclass 3/0, 33 report ids > uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0 > uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0 > uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0 > uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0 > > device 2 (M235 2nd gen according to bottom) previously reported this in dmesg > (same thing, but the rev/addr values): > > uhidev1 at uhub0 port 4 configuration 1 interface 0 "Logitech USB Receiver" > rev 2.00/24.07 addr 3 > uhidev1: iclass 3/1 > ukbd1 at uhidev1: 8 variable keys, 6 key codes > wskbd2 at ukbd1 mux 1 > uhidev2 at uhub0 port 4 configuration 1 interface 1 "Logitech USB Receiver" > rev 2.00/24.07 addr 3 > uhidev2: iclass 3/1, 8 report ids > ums0 at uhidev2 reportid 2: 16 buttons, Z and W dir > wsmouse2 at ums0 mux 0 > uhid0 at uhidev2 reportid 3: input=4, output=0, feature=0 > uhid1 at uhidev2 reportid 4: input=1, output=0, feature=0 > uhid2 at uhidev2 reportid 8: input=1, output=0, feature=0 > uhidev3 at uhub0 port 4 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/24.07 addr 3 > uhidev3: iclass 3/0, 33 report ids > uhid3 at uhidev3 reportid 16: input=6, output=6, feature=0 > uhid4 at uhidev3 reportid 17: input=19, output=19, feature=0 > uhid5 at uhidev3 reportid 32: input=14, output=14, feature=0 > uhid6 at uhidev3 reportid 33: input=31, output=31, feature=0 > > now device 1/uhidev2 is properly identified by uhidpp: > > uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/12.03 addr 2 > uhidev2: iclass 3/0, 33 report ids > uhidpp0 at uhidev2 device 1 mouse "M325" serial 69-b1-af-84 > > and properly reports sensors: > hw.sensors.uhidpp0.raw0=2 (battery levels) > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > and device2 (plugged on the same laptop so device renumbered) also works with > uhidpp: > > uhidev2 at uhub0 port 2 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/24.07 addr 2 > uhidev2: iclass 3/0, 33 report ids > uhidpp0 at uhidev2 device 1 mouse "Wireless Mouse" serial f3-94-18-8c > > same level reported in sensors for a different mouse (?): > hw.sensors.uhidpp0.raw0=2 (battery levels) > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > let me know if you need more details/infos from those devices (usbdevs dumps > etc..) As both your devices only are capable of reporting two battery levels, as given by hw.sensors.uhidpp0.raw0, it's quite likely that they will report the same level. > i'll eventually look at adding support for uhidpp to upower so mouse battery > levels can be reported in xfce4-power-manager and gnome, like it does on > linux.. There has been some work on this from a Linux perspective[1], not sure if there's anything you could piggy back on there. Let me know if any more data needs to be expsoed in order to satisfy upower. [1] https://julien.danjou.info/logitech-unifying-upower/
Re: uhidpp(4): logitech hid++ device driver
Hi, I have a Logitech M570 which seems to be handled by this new driver. However I don't see any battery level information. dmesg: uhidpp0 at uhidev4 device 1 mouse "M570" serial ef-81-ff-80 sysctl kern.version: kern.version=OpenBSD 6.8-current (GENERIC.MP) #313: Fri Feb 5 18:31:44 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP hw.sensors.uhidpp0 does not seem to exist. Regards, Anindya
Re: uhidpp(4): logitech hid++ device driver
Hi,
On Mon, Feb 08, 2021 at 02:50:39PM -0800, Anindya Mukherjee wrote:
> Hi, I have a Logitech M570 which seems to be handled by this new driver.
> However I don't see any battery level information.
>
> dmesg:
> uhidpp0 at uhidev4 device 1 mouse "M570" serial ef-81-ff-80
>
> sysctl kern.version:
> kern.version=OpenBSD 6.8-current (GENERIC.MP) #313: Fri Feb 5 18:31:44 MST
> 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> hw.sensors.uhidpp0 does not seem to exist.
>
> Regards,
> Anindya
>
Could you try the following diff and send me the complete dmesg. I've
also prepared an amd64 kernel with the patch applied:
https://www.basename.se/tmp/bsd.uhidpp.battery
diff --git sys/dev/usb/uhidpp.c sys/dev/usb/uhidpp.c
index b041d86fecd..27f6137ec06 100644
--- sys/dev/usb/uhidpp.c
+++ sys/dev/usb/uhidpp.c
@@ -29,7 +29,7 @@
#include
#include
-/* #define UHIDPP_DEBUG */
+#define UHIDPP_DEBUG
#ifdef UHIDPP_DEBUG
#define DPRINTF(x...) do { \
@@ -84,12 +84,16 @@ int uhidpp_debug = 1;
#define HIDPP_GET_LONG_REGISTER0x83
#define HIDPP_REG_ENABLE_REPORTS 0x00
+#define HIDPP_REG_BATTERY_STATUS 0x07
#define HIDPP_REG_PAIRING_INFORMATION 0xb5
#define HIDPP_NOTIF_DEVICE_BATTERY_STATUS (1 << 4)
#define HIDPP_NOTIF_RECEIVER_WIRELESS (1 << 0)
#define HIDPP_NOTIF_RECEIVER_SOFTWARE_PRESENT (1 << 3)
+/* Number of battery levels supported by HID++ 1.0 devices. */
+#define HIDPP_BATTERY_NLEVELS 7
+
/* HID++ 1.0 error codes. */
#define HIDPP_ERROR0x8f
#define HIDPP_ERROR_SUCCESS0x00
@@ -112,7 +116,6 @@ int uhidpp_debug = 1;
* greater than zero which is reserved for notifications.
*/
#define HIDPP_SOFTWARE_ID 0x01
-#define HIDPP_SOFTWARE_ID_MASK 0x0f
#define HIDPP_SOFTWARE_ID_LEN 4
#define HIDPP20_FEAT_ROOT_IDX 0x00
@@ -154,8 +157,8 @@ int uhidpp_debug = 1;
/* Feature access report used by the HID++ 2.0 (and greater) protocol. */
struct fap {
- uint8_t feature_index;
- uint8_t funcindex_clientid;
+ uint8_t feature_idx;
+ uint8_t funcidx_swid;
uint8_t params[HIDPP_REPORT_LONG_PARAMS_MAX];
};
@@ -185,6 +188,8 @@ struct uhidpp_notification {
struct uhidpp_device {
uint8_t d_id;
uint8_t d_connected;
+ uint8_t d_major;
+ uint8_t d_minor;
struct {
struct ksensor b_sens[UHIDPP_NSENSORS];
uint8_t b_feature_idx;
@@ -237,8 +242,10 @@ struct uhidpp_notification
*uhidpp_claim_notification(struct uhidpp_softc *);
int uhidpp_consume_notification(struct uhidpp_softc *, struct uhidpp_report *);
int uhidpp_is_notification(struct uhidpp_softc *, struct uhidpp_report *);
-int hidpp_get_protocol_version(struct uhidpp_softc *, uint8_t, int *, int *);
+int hidpp_get_protocol_version(struct uhidpp_softc *, uint8_t, uint8_t *,
+uint8_t *);
+int hidpp10_get_battery_status(struct uhidpp_softc *, uint8_t, uint8_t *);
int hidpp10_get_name(struct uhidpp_softc *, uint8_t, char *, size_t);
int hidpp10_get_serial(struct uhidpp_softc *, uint8_t, uint8_t *, size_t);
int hidpp10_get_type(struct uhidpp_softc *, uint8_t, const char **);
@@ -520,7 +527,7 @@ void
uhidpp_device_connect(struct uhidpp_softc *sc, struct uhidpp_device *dev)
{
struct ksensor *sens;
- int error, major, minor;
+ int error;
uint8_t feature_type;
MUTEX_ASSERT_LOCKED(&sc->sc_mtx);
@@ -529,30 +536,40 @@ uhidpp_device_connect(struct uhidpp_softc *sc, struct
uhidpp_device *dev)
if (dev->d_connected)
return;
- error = hidpp_get_protocol_version(sc, dev->d_id, &major, &minor);
+ error = hidpp_get_protocol_version(sc, dev->d_id,
+ &dev->d_major, &dev->d_minor);
if (error) {
- DPRINTF("%s: protocol version failure: device_id=%d,
error=%d\n",
+ DPRINTF("%s: protocol version failure: device_id=%d, "
+ "error=%d\n",
__func__, dev->d_id, error);
return;
}
DPRINTF("%s: device_id=%d, version=%d.%d\n",
- __func__, dev->d_id, major, minor);
+ __func__, dev->d_id, dev->d_major, dev->d_minor);
- error = hidpp20_root_get_feature(sc, dev->d_id,
- HIDPP20_FEAT_BATTERY_IDX,
- &dev->d_battery.b_feature_idx, &feature_type);
- if (error) {
- DPRINTF("%s: battery feature index failure: device_id=%d, "
- "error=%d\n", __func__, dev->d_id, error);
- return;
- }
+ if (dev->d_major >= 2) {
+ error = hidpp20_root_get_feature(sc, dev->d_id,
+ HIDPP20_FEAT_BATTERY_IDX,
+ &dev->d_battery.b_feature_idx, &feature_type);
+
Re: uhidpp(4): logitech hid++ device driver
On Tue, Feb 09, 2021 at 08:34:00AM +0100, Anton Lindqvist wrote:
> Hi,
>
> On Mon, Feb 08, 2021 at 02:50:39PM -0800, Anindya Mukherjee wrote:
> > Hi, I have a Logitech M570 which seems to be handled by this new driver.
> > However I don't see any battery level information.
> >
> > dmesg:
> > uhidpp0 at uhidev4 device 1 mouse "M570" serial ef-81-ff-80
> >
> > sysctl kern.version:
> > kern.version=OpenBSD 6.8-current (GENERIC.MP) #313: Fri Feb 5 18:31:44 MST
> > 2021
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > hw.sensors.uhidpp0 does not seem to exist.
> >
> > Regards,
> > Anindya
> >
>
> Could you try the following diff and send me the complete dmesg. I've
> also prepared an amd64 kernel with the patch applied:
>
> https://www.basename.se/tmp/bsd.uhidpp.battery
Thanks! I'll try it as soon as I can and report back.
>
> diff --git sys/dev/usb/uhidpp.c sys/dev/usb/uhidpp.c
> index b041d86fecd..27f6137ec06 100644
> --- sys/dev/usb/uhidpp.c
> +++ sys/dev/usb/uhidpp.c
> @@ -29,7 +29,7 @@
> #include
> #include
>
> -/* #define UHIDPP_DEBUG */
> +#define UHIDPP_DEBUG
> #ifdef UHIDPP_DEBUG
>
> #define DPRINTF(x...) do { \
> @@ -84,12 +84,16 @@ int uhidpp_debug = 1;
> #define HIDPP_GET_LONG_REGISTER 0x83
>
> #define HIDPP_REG_ENABLE_REPORTS 0x00
> +#define HIDPP_REG_BATTERY_STATUS 0x07
> #define HIDPP_REG_PAIRING_INFORMATION0xb5
>
> #define HIDPP_NOTIF_DEVICE_BATTERY_STATUS(1 << 4)
> #define HIDPP_NOTIF_RECEIVER_WIRELESS(1 << 0)
> #define HIDPP_NOTIF_RECEIVER_SOFTWARE_PRESENT(1 << 3)
>
> +/* Number of battery levels supported by HID++ 1.0 devices. */
> +#define HIDPP_BATTERY_NLEVELS7
> +
> /* HID++ 1.0 error codes. */
> #define HIDPP_ERROR 0x8f
> #define HIDPP_ERROR_SUCCESS 0x00
> @@ -112,7 +116,6 @@ int uhidpp_debug = 1;
> * greater than zero which is reserved for notifications.
> */
> #define HIDPP_SOFTWARE_ID0x01
> -#define HIDPP_SOFTWARE_ID_MASK 0x0f
> #define HIDPP_SOFTWARE_ID_LEN4
>
> #define HIDPP20_FEAT_ROOT_IDX0x00
> @@ -154,8 +157,8 @@ int uhidpp_debug = 1;
>
> /* Feature access report used by the HID++ 2.0 (and greater) protocol. */
> struct fap {
> - uint8_t feature_index;
> - uint8_t funcindex_clientid;
> + uint8_t feature_idx;
> + uint8_t funcidx_swid;
> uint8_t params[HIDPP_REPORT_LONG_PARAMS_MAX];
> };
>
> @@ -185,6 +188,8 @@ struct uhidpp_notification {
> struct uhidpp_device {
> uint8_t d_id;
> uint8_t d_connected;
> + uint8_t d_major;
> + uint8_t d_minor;
> struct {
> struct ksensor b_sens[UHIDPP_NSENSORS];
> uint8_t b_feature_idx;
> @@ -237,8 +242,10 @@ struct uhidpp_notification
> *uhidpp_claim_notification(struct uhidpp_softc *);
> int uhidpp_consume_notification(struct uhidpp_softc *, struct uhidpp_report
> *);
> int uhidpp_is_notification(struct uhidpp_softc *, struct uhidpp_report *);
>
> -int hidpp_get_protocol_version(struct uhidpp_softc *, uint8_t, int *, int
> *);
> +int hidpp_get_protocol_version(struct uhidpp_softc *, uint8_t, uint8_t *,
> +uint8_t *);
>
> +int hidpp10_get_battery_status(struct uhidpp_softc *, uint8_t, uint8_t *);
> int hidpp10_get_name(struct uhidpp_softc *, uint8_t, char *, size_t);
> int hidpp10_get_serial(struct uhidpp_softc *, uint8_t, uint8_t *, size_t);
> int hidpp10_get_type(struct uhidpp_softc *, uint8_t, const char **);
> @@ -520,7 +527,7 @@ void
> uhidpp_device_connect(struct uhidpp_softc *sc, struct uhidpp_device *dev)
> {
> struct ksensor *sens;
> - int error, major, minor;
> + int error;
> uint8_t feature_type;
>
> MUTEX_ASSERT_LOCKED(&sc->sc_mtx);
> @@ -529,30 +536,40 @@ uhidpp_device_connect(struct uhidpp_softc *sc, struct
> uhidpp_device *dev)
> if (dev->d_connected)
> return;
>
> - error = hidpp_get_protocol_version(sc, dev->d_id, &major, &minor);
> + error = hidpp_get_protocol_version(sc, dev->d_id,
> + &dev->d_major, &dev->d_minor);
> if (error) {
> - DPRINTF("%s: protocol version failure: device_id=%d,
> error=%d\n",
> + DPRINTF("%s: protocol version failure: device_id=%d, "
> + "error=%d\n",
> __func__, dev->d_id, error);
> return;
> }
>
> DPRINTF("%s: device_id=%d, version=%d.%d\n",
> - __func__, dev->d_id, major, minor);
> + __func__, dev->d_id, dev->d_major, dev->d_minor);
>
> - error = hidpp20_root_get_feature(sc, dev->d_id,
> - HIDPP20_FEAT_BATTERY_IDX,
> - &dev->d_battery.b_feature_idx, &feature_type);
> - if (error) {
> - DPRINTF("%s: battery feature index
Re: uhidpp(4): logitech hid++ device driver
Hi, Sorry for the delay. I am running the latest snapshot: kern.version=OpenBSD 6.9-beta (GENERIC.MP) #331: Thu Feb 11 20:28:45 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP which seems to have the latest updates. However I still do not see battery levels for my M570. Full dmesg below. Please let me know if I can test anything. Regards, Anindya OpenBSD 6.9-beta (GENERIC.MP) #331: Thu Feb 11 20:28:45 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34201006080 (32616MB) avail mem = 33149145088 (31613MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe (94 entries) bios0: vendor Dell Inc. version "1.5.6" date 12/07/2016 bios0: Dell Inc. OptiPlex 7040 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT UEFI LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR TPM2 ASF! BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3393.29 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.11 MHz, 06-5e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.11 MHz, 06-5e-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.11 MHz, 06-5e-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu
Re: uhidpp(4): logitech hid++ device driver
On Fri, Feb 12, 2021 at 03:48:51AM -0800, Anindya Mukherjee wrote: > Hi, > > Sorry for the delay. I am running the latest snapshot: > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #331: Thu Feb 11 20:28:45 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > which seems to have the latest updates. However I still do not see battery > levels for my M570. Full dmesg below. Please let me know if I can test > anything. Could you try a kernel with revision 1.10 of dev/usb/uhidpp.c present and UHIDPP_DEBUG enabled. I have also prepared an amd64 kernel with the necessary bits available here: https://www.basename.se/tmp/bsd.uhidpp Please send me the complete dmesg from this kernel. It won't make any battery sensors appear but rather help diagnose.
Re: uhidpp(4): logitech hid++ device driver
Hi, I used your kernel to generate the dmesg below. Please have a look, thanks! OpenBSD 6.9-beta (GENERIC.MP) #310: Sun Feb 14 15:42:32 CET 2021 an...@desk.basename.se:/home/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34201006080 (32616MB) avail mem = 33149136896 (31613MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe (94 entries) bios0: vendor Dell Inc. version "1.5.6" date 12/07/2016 bios0: Dell Inc. OptiPlex 7040 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT UEFI LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR TPM2 ASF! BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3393.14 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.11 MHz, 06-5e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.11 MHz, 06-5e-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.11 MHz, 06-5e-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
