From: Alan Stern <stern@rowland.harvard.edu>
To: Bastien Nocera <hadess@hadess.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC] USB: core: Add wireless_status sysfs attribute
Date: Tue, 17 Jan 2023 11:01:42 -0500 [thread overview]
Message-ID: <Y8bGZuMAvMRCTDQB@rowland.harvard.edu> (raw)
In-Reply-To: <d9f8b9413c10fcf067658979d16a4f5c7abe69e7.camel@hadess.net>
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 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?
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?
Alan Stern
next prev parent reply other threads:[~2023-01-17 16:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 15:17 [RFC] USB: core: Add wireless_status sysfs attribute Bastien Nocera
2023-01-17 16:01 ` Alan Stern [this message]
2023-01-17 16:35 ` Bastien Nocera
2023-01-17 16:14 ` Greg Kroah-Hartman
2023-01-17 16:36 ` Bastien Nocera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8bGZuMAvMRCTDQB@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=benjamin.tissoires@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hadess@hadess.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox