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. >> >> 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 -- Rahul Rameshbabu
