Am 21.07.23 um 04:45 schrieb Rahul Rameshbabu:
On Fri, 07 Jul, 2023 23:22:58 +0200 Werner Sembach <werner@xxxxxxxx> wrote:
Am 07.07.23 um 23:12 schrieb Werner Sembach:
Hi,
The EPOS GSP 370 wireless headset has a volume control knob on the headset.
Turning this has 2 effects on Linux:
- The volume gets adjusted in firmware
- A volume up/down key event is sent to the OS and the volume is adjustet on
the OS level (the dongle registers both as a audio device and an usb keyboard
to do this)
This double volume adjust is ofc not the intended behavior and induces all
kinds of wiredness, like the os is already displaying 100% volume but you can
still turn it higher because the firmware has not yet reached max volume.
What you will likely want to do is implement a custom USB mixer quirk
for the audio device advertised by the USB dongle. I delve into this
more in the section discussing which subsystem would be appropriate for
this.
Thank you very much for giving me the starting points, now I only need
to find some time to work on this.
Running Wireshark on Windows and Linux I recognized that Windows is sending
"URB_CONTROL out" events to the dongle on volume adjust, which Linux doesn't,
these events have a paylode that seems to encode a volume value in 2 byte with
little endianess.
I'm unsure if I can attach pcap file or if it will get blocked in the list so
i will send them as a reply.
As I thought: The pcapng files are to big for the mailing list. When someone is
interested let me know how I can send them (should I open a Bugzilla Ticket for
it?).
So my 2 questions are:
- What are these USB "URB_CONTROL out" events? (Does not seem to be HID
reports?)
URB stands for USB Request Block. You are specifically working with the
USB layer here rather than the HID layer that abstracts away the lower
level transport interface.
URB in general is a system (OS) - defined format for interacting with
the core host controller driver in the OS stack. This means the
implementation of sending requests to the USB hub driver in Linux and
Windows differ. You may want to understand the specific requests made by
the Windows USB client driver for the headset and implement an
equivalent driver using the URB API of the linux kernel.
Generic Overview
* https://wiki.osdev.org/Universal_Serial_Bus#Host_Controller_Driver
Linux specific information
* https://static.lwn.net/images/pdf/LDD3/ch13.pdf
* https://docs.kernel.org/driver-api/usb/URB.html
* https://docs.kernel.org/driver-api/usb/writing_usb_driver.html
Windows specific information
* https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-control-transfer
- In which subsystem would I want to implement them? Or should this be handled
in userspace?
I am guessing you would not need to add any additional support for the
USB keyboard device advertised by the dongle. It's working fine and
advertising media keys to the system as you expect. Your goal now more
likely is to send USB requests to the headset (dongle) whenever the
volume level is changed for the audio device through the system. I
assume such a "driver" (quirk) would live under sound/usb in the kernel
tree just like sound/usb/mixer_scarlett.c,
sound/usb/mixer_scarlett_gen2.c, and other usb mixer implementations in
the kernel. Specifically in sound/usb/mixer_scarlett.c, I think you will
find the add_output_ctls function to be a helpful reference for defining
a new volume control that properly controls the device firmware volume
level based on the ALSA PCM level set in the kernel by user interaction
with the userspace audio component on his/her system. You will see all
these mixer implementations then get instantiated in
sound/usb/mixer_quirks.c in the snd_usb_mixer_apply_create_quirk
function.
Bast regards,
Werner
Might want to ask the alsa-devel mailing list about how to go about
handling the device firmware audio control as well in the linux audio
stack if you did not find this explanation suitable for getting
started/want to inquire further about the ALSA kernel architecture.
https://www.alsa-project.org/wiki/Mailing-lists
I will do that when the first question undoubtly pop up once I start
reading the mixer_* source code ^^.
-- Rahul Rameshbabu
