On Sat, 5 May 2007, [EMAIL PROTECTED] wrote: > Hi, > I am using a telephony device, too, and seem to have similar issues. It > is a Yealink P1K for which there is a kernel driver available. As long > as this driver is not loaded the ALSA mixer controls (volume and mute) > work fine. But as soon as the kernel driver (or my own userspace driver) > starts its flow of control messages to query the key matrix, things go > wrong. > 1. The yealink driver receives unusual response codes as soon as mixer > controls are touched. > 2. ALSA mixer controls behave unexpectedly, usually turning mute > spontaneously (urgh) > > I created a commented usbmon log > (http://download.devbase.at/transfers.log) which suggests that both > yealink and ALSA start control transfers which get mixed between setup > and data stage. I am not too familiar with the kernel's USB internals so > is this possible at all?
No, it isn't. You're being misled by the format of the usbmon log. Transfers are logged at the time they are submitted and completed, but the control transfers go out over the wire one at a time, not interleaved. For instance, you'll always see the C lines for two different transfers occurring in the same order as the corresponding S lines. Your log annotations illustrate this misunderstanding. The "going down" and "coming back" parts have nothing to do with Setup vs. Data stages. Rather "going down" (or just S) means the message was Submitted to usbcore, and "coming back" (or just C) means that usbcore has Completed the message. And you got several lines labelled wrong; S always means Submit (or going down) and C always means Complete (or coming back). > The following response of the device is wrong (0 bytes instead of 1 > byte) and apparently this causes ALSA to mute the channel, in this case. Apparently this happened at timestamp 1642959952 in addition to the place you annotated. Specifically: KEYSCAN command submitted: d9f39ce0 1642957022 S Co:006:00 s 21 09 0200 0003 0010 16 = 80010000 00000000 00000000 0000007f MUTE state query submitted: d3e80ec0 1642957096 S Ci:006:00 s a1 81 0101 0600 0001 1 < KEYSCAN command completed: d9f39ce0 1642959949 C Co:006:00 0 16 > MUTE state query completed (device sent back 0 bytes): d3e80ec0 1642959952 C Ci:006:00 0 0 It could be the device itself is getting confused somehow. Or maybe it thinks that sending 0 bytes is a legal response to the query. > What is the solution to handle these types of composite devices? Is > there a way to share the control endpoint? Nothing special should be needed. Endpoint 0 should always be shared without difficulty. If necessary perhaps the ALSA driver could be patched to handle bogus 0-length responses, say by retrying the query? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
