On Tue, 2016-10-18 at 14:07 +0200, Takashi Iwai wrote:
On Wed, 12 Oct 2016 18:15:04 +0200, Bastien Nocera wrote:
On Wed, 2016-10-12 at 18:06 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user- initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function.
I'm guessing it doesn't support it then (see attached log)
So this looks like a HID, not from the audio device class. It's an oft-seen implementation.
I also checked the input device output when plugging in something, with evtest, and no feedback either.
Then at first you need to hack a HID driver to support this device. It'll create an input device, and then we'll need to find some way to couple the given input device and the audio device. We can parse the sysfs device path to figure out, but I'm not sure what's the best way to tell it to applications.
You misunderstood. There's no input events on the input device, there's also no hidraw events (hid-recorder didn't see any events) and using usbmon also got me no USB events whatsoever when plugging or unplugging a jack on either the headphones or the microphone jack.
So there's really nothing that we can do for this hardware. Shame, it would have been pretty useful to me :)
Thanks all for your help