Re: [PATCH v3] HID: logitech-headset: add a battery driver for the PRO X 2

[Méven]

Subject: Re: [PATCH v3] HID: logitech-headset: add a battery driver
for the PRO X 2

On <date of his mail>, Jiri Kosina wrote:
> One question though -- is it really practical to have this as a user
> selectable option?
> I think it'd make sense to have just selected by HID_LOGITECH_DJ the same
> way as it selects HID_LOGITECH_HIDPP. What do you think?

Agreed, a separate prompt is not useful here. The driver only matters to
people with a Logitech receiver, and those kernels have HID_LOGITECH_DJ
enabled anyway. I missed this opportunity.

In v4, HID_LOGITECH_HEADSET is a hidden option, and HID_LOGITECH_DJ
selects it next to HID_LOGITECH_HIDPP. HID_LOGITECH_DJ already depends
on USB_HID, so the select leaves no dependency unmet. I will send it
shortly.

Thanks,
Méven

Le ven. 16 oct. 2026 à 11:04, Jiri Kosina <jikos@xxxxxxxxxx> a écrit :
>
> On Sun, 11 Oct 2026, Méven Car wrote:
>
> > The PRO X 2 LIGHTSPEED receiver does not speak HID++, so
> > hid-logitech-hidpp cannot read its battery. Its report descriptor has a
> > consumer collection for the media keys and two vendor collections, and
> > no report 0x10 or 0x11.
> >
> > The battery answers on usage page 0xffa0. A single 64 byte frame on
> > report 0x51 asks for it, with no handshake, and the reply gives the
> > level and whether the headset is charging. The driver asks every 120
> > seconds. It also reads the power frames that the headset sends on its
> > own. A switch-off frame marks the headset absent at once, and a
> > switch-on frame moves the next request to one second later, so the level
> > appears without waiting for the poll.
> >
> > hid-generic sets HID_QUIRK_INPUT_PER_APP, so this receiver had one input
> > device per application collection, among them the Consumer Control node
> > for the media keys. A driver does not inherit that quirk, so probe sets
> > it and the input devices stay as they were.
> >
> > The power supply is registered with POWER_SUPPLY_SCOPE_DEVICE. The
> > headset is present from a reply until the next switch-off frame, and
> > capacity returns -ENODATA while it is absent, so a headset that is off
> > when the driver binds reports no level.
> >
> > The G522 LIGHTSPEED uses the same vendor protocol with a different frame
> > layout. That device is left out until someone can test it.
> >
> > Assisted-by: Claude:claude-opus-5
> > Signed-off-by: Méven Car <meven@xxxxxxx>
> > ---
> > Changes in v3:
> > - Request the battery level one second after a power-on frame, so the
> >   level appears without waiting for the 120 second poll.
> > - Report the headset as absent until the first battery reply, and return
> >   -ENODATA for capacity while it is absent.
> > - Queue the poll on system_dfl_wq instead of the system_wq.
> >
> >  drivers/hid/Kconfig                |  11 +
> >  drivers/hid/Makefile               |   1 +
> >  drivers/hid/hid-ids.h              |   1 +
> >  drivers/hid/hid-logitech-headset.c | 319 +++++++++++++++++++++++++++++
> >  4 files changed, 332 insertions(+)
> >  create mode 100644 drivers/hid/hid-logitech-headset.c
> >
> > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> > index 48934c4f3..5c845b1b8 100644
> > --- a/drivers/hid/Kconfig
> > +++ b/drivers/hid/Kconfig
> > @@ -670,6 +670,17 @@ config HID_LOGITECH_DJ
> >       generic USB_HID driver and all incoming events will be multiplexed
> >       into a single mouse and a single keyboard device.
> >
> > +config HID_LOGITECH_HEADSET
> > +     tristate "Logitech wireless headset battery"
> > +     depends on USB_HID
> > +     select POWER_SUPPLY
> > +     help
> > +     Support for the battery of Logitech wireless gaming headsets that
> > +     report it over a vendor collection instead of HID++.
>
> Thanks a lot for the patch.
>
> One question though -- is it really practical to have this as a user
> selectable option?
> I think it'd make sense to have just selected by HID_LOGITECH_DJ the same
> way as it selects HID_LOGITECH_HIDPP. What do you think?
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>


-- 
Méven