linux-kernel - Re: [RFC] USB: core: Add wireless

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <83d8a06403d098f90760c199674ed585ca725b13.camel@hadess.net>
Date:   Tue, 17 Jan 2023 17:35:58 +0100
From:   Bastien Nocera <hadess@...ess.net>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC] USB: core: Add wireless_status sysfs attribute

On Tue, 2023-01-17 at 11:01 -0500, Alan Stern wrote:
> On Tue, Jan 17, 2023 at 04:17:23PM +0100, Bastien Nocera wrote:
> > Hey,
> > 
> > TLDR: new sysfs attribute that makes it possible to leave receivers
> > for
> > wireless headsets plugged in. At the USB level, or at the base
> > driver
> > level?
> > 
> > Longer version:
> > I started working on implementing support for some wireless
> > headsets
> > that use USB receivers to communicate to the headset itself.
> > 
> > The USB receivers have multiple interfaces, and independent drivers
> > for
> > each, as is wont to do for USB devices. There's usually a HID
> > interface
> > to do the custom stuff (LEDs, battery status, connection status,
> > etc.)
> > and a standard audio class interface.
> > 
> > Those drivers don't know anything about each other, and getting
> > them to
> > talk to each other would be rather complicated. Additionally the
> > audio
> > interface is still somewhat functional when the headset is
> > disconnected.
> > 
> > In the end, I came up with this new sysfs attribute that would make
> > it
> > possible for user-space (PulseAudio or Pipewire) to know whether
> > the
> > receiver is plugged in or not.
> > 
> > That allows user-space to not show the battery information for the
> > device (rather than 0 percent), not offer the headset as an output,
> > and
> > potentially automatically switch to it when the headset is powered
> > on.
> > 
> > The question is whether this should be a USB sysfs attribute, or
> > one at
> > the base driver level. Example implementation of the USB sysfs
> > attribute itself below.
> 
> Do you know of any non-USB devices using the receiver/emitter
> approach?

I don't know of any.

> 
> > I have a patch for a USB API as well, but I'm having some problems
> > creating deferred work on a soft irq.
> > 
> > Cheers
> > 
> > ----
> > Add a wireless_status sysfs attribute to USB devices to keep track
> > of
> > whether a USB device that uses a receiver/emitter combo has its
> > emitter connected or disconnected.
> > 
> > By default, the USB device will declare not to use a
> > receiver/emitter.
> 
> How do you plan to tell which devices do use a receiver/emitter?  Is 
> this something the drivers already knowo about?

This is something that will need to be done on a device-by-device
basis. For example, I have some patches to the hid-logitech-hidpp
driver to set the wireless status when the headset is turned on.

This would allow leaving the receiver plugged in, and user-space would
know when the headset was actually available.

> 
> Is it conceivable that a single device might have more than one 
> receiver?  If so, should the attribute belong to an interface rather 
> than to the USB device?

The USB device is usually (always?) the receiver, so this kind of setup
wouldn't make much sense to me.

We could have it at the interface level, certainly, as Greg mentioned.
That's probably the path I will take.