[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b356b5684cc631513c0498f18d7c185b77416f85.camel@hadess.net>
Date: Thu, 08 Dec 2022 16:20:48 +0100
From: Bastien Nocera <hadess@...ess.net>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Jiri Kosina <jikos@...nel.org>,
Filipe Laíns <lains@...eup.net>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
linux-input@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: [Regression] Logitech BT mouse unusable after commit
532223c8ac57 (still in 6.1-rc8)
On Wed, 2022-12-07 at 18:44 +0100, Rafael J. Wysocki wrote:
> On Wed, Dec 7, 2022 at 6:19 PM Bastien Nocera <hadess@...ess.net>
> wrote:
> >
> > On Wed, 2022-12-07 at 12:07 +0100, Rafael J. Wysocki wrote:
> > > # hidpp-list-features /dev/hidraw1
> > > Bluetooth Mouse M336/M337/M535 (046d:b016) is a HID++ 4.5 device
> > > Feature 0x01: [0x0001] Feature set
> > > Feature 0x02: [0x0003] Device FW version
> > > Feature 0x03: [0x0005] Device name
> > > Feature 0x04: [0x0020] Reset
> > > Feature 0x05: [0x1e00] Enable hidden features (hidden)
> > > Feature 0x06: [0x1800] Generic Test (hidden, internal)
> > > Feature 0x07: [0x1000] Battery status
> > > Feature 0x08: [0x1b04] Reprog controls v4
> > > Feature 0x09: [0x2100] Vertical scrolling
> > > Feature 0x0a: [0x2200] Mouse pointer
> > > Feature 0x0b: [0x2205] Pointer speed
> > > Feature 0x0c: [0x18b1] ? (hidden, internal)
> > > Feature 0x0d: [0x2121] Hi-res wheel
> > > Feature 0x0e: [0x1f03] ? (hidden, internal)
> >
> > Would you be able to enable debugging for the hid subsystem to get
> > some
> > debug data when getting the version from the device fails?
>
> I guess I could, but I think that the device is just quirky.
>
> At least the BT layer appears to think that it is connected.
>
> Anyway, what exactly do you need?
>
> > I can't see any problems in there that wouldn't also have impacted
> > all
> > the other Logitech Bluetooth devices listed in the support devices
> > list.
> >
> > If the problem is a timeout, maybe we should lower the timeouts we
> > currently have (5*HZ = 5 seconds, right?), so we can retry 5 times
> > one
> > second instead.
>
> No, it doesn't take 5 sec to get a response from it. It rather looks
> like __hidpp_send_report() returns an error.
Adding "debug" on the kernel command-line should be enough to get debug
out of hidpp_send_message_sync():
https://stackoverflow.com/a/63682160
Either that or turn all the dbg_hid() into hid_err() if you're going to
be compiling the kernel.
We're mainly interested in the error code from the device, as that's
what I'm guessing is caused the error to propagate.
> > Still, as I mentioned earlier, I can't reproduce the problem on
> > another
> > Bluetooth Classic device...
Powered by blists - more mailing lists