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.
