Need information to implement correct handling of the GSP 370 wireless headset

Need information to implement correct handling of the GSP 370 wireless headset

[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.

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.

So my 2 questions are:

- What are these USB "URB_CONTROL out" events? (Does not seem to be HID 
reports?)

- In which subsystem would I want to implement them? Or should this be 
handled in userspace?

Bast regards,

Werner

Re: Need information to implement correct handling of the GSP 370 wireless headset

[Werner Sembach]

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.
>
> 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?)
>
> - In which subsystem would I want to implement them? Or should this be 
> handled in userspace?
>
> Bast regards,
>
> Werner
>

Re: Need information to implement correct handling of the GSP 370 wireless headset

[Rahul Rameshbabu]

On Fri, 07 Jul, 2023 23:22:58 +0200 Werner Sembach <werner@rdorf.de> 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

Re: Need information to implement correct handling of the GSP 370 wireless headset

[Werner Sembach]

Am 21.07.23 um 04:45 schrieb Rahul Rameshbabu:
> On Fri, 07 Jul, 2023 23:22:58 +0200 Werner Sembach <werner@rdorf.de> 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