linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 219111] Xone:23C mixer not recognized as a 2in/2out device
Date: Thu, 08 Aug 2024 18:22:40 +0000	[thread overview]
Message-ID: <bug-219111-208809-gn1ERFC4L8@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-219111-208809@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=219111

--- Comment #38 from Alan Stern (stern@rowland.harvard.edu) ---
It's more than just the driver knowing what configuration to use.  The device
has to be _told_ to use that configuration; until it is told it won't use any
configuration at all and won't function.  Your usbmon traces and Windows packet
captures all show the computer telling the device to use configuration 1.  (If
you made a usbmon trace with old_scheme_first=Y, presumably it would show the
computer telling the device to use configuration 2.)

The configuration matters because the data sent over the USB connection is
formatted differently depending on the number of channels.  No matter what the
driver may know about the possible configs, as long as the device is using
config 1, it will provide only two-channel stereo.  And as long as it is using
config 2, it will provide only four-channel stereo.

The difference between the old scheme and the new scheme is rather technical. 
It has to do with how the device is initialized when it is first plugged in
(and also whenever it gets reset).

With the old scheme, after performing an initial reset the computer asks the
device to send just the first 8 bytes of its device descriptor, then the
computer tells the device what address to use, and then it reads the complete
device descriptor and all the other descriptors.

With the new scheme, after performing the initial reset the computer asks the
device to send the first 64 bytes of its device descriptor.  Since the device
descriptor is only 18 bytes long, the response is always a short one.  The
computer then resets the device a second time, tells it what address to use,
and reads all the descriptors.  (That's why I thought skipping the second reset
might cause the device to make both configurations available, like it does with
the old scheme.)

The old scheme is what the USB 2.0 specification recommends.  The new scheme is
what Microsoft implemented early on, however, and as a result quite a few
devices would work with the new scheme but not the old one.  In theory any
device should work properly with either scheme, but in practice they don't
always do so.  As in this case.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2024-08-08 18:22 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-30 18:11 [Bug 219111] New: Xone:23C mixer not recognized as a 2in/2out device bugzilla-daemon
2024-07-30 18:13 ` [Bug 219111] " bugzilla-daemon
2024-07-30 18:14 ` bugzilla-daemon
2024-07-30 18:14 ` bugzilla-daemon
2024-07-30 18:16 ` bugzilla-daemon
2024-07-31 14:59 ` bugzilla-daemon
2024-07-31 15:38 ` bugzilla-daemon
2024-07-31 15:46 ` bugzilla-daemon
2024-07-31 15:47 ` bugzilla-daemon
2024-07-31 18:14 ` bugzilla-daemon
2024-07-31 18:53 ` bugzilla-daemon
2024-07-31 19:20 ` bugzilla-daemon
2024-07-31 19:21 ` bugzilla-daemon
2024-07-31 19:27 ` bugzilla-daemon
2024-07-31 19:28 ` bugzilla-daemon
2024-08-01  7:41 ` bugzilla-daemon
2024-08-01 15:01 ` bugzilla-daemon
2024-08-04 10:39 ` bugzilla-daemon
2024-08-04 15:38 ` bugzilla-daemon
2024-08-04 19:13 ` bugzilla-daemon
2024-08-05 13:41 ` bugzilla-daemon
2024-08-05 13:41 ` bugzilla-daemon
2024-08-05 14:55 ` bugzilla-daemon
2024-08-05 16:13 ` bugzilla-daemon
2024-08-05 16:15 ` bugzilla-daemon
2024-08-05 16:20 ` bugzilla-daemon
2024-08-06 14:09 ` bugzilla-daemon
2024-08-06 14:12 ` bugzilla-daemon
2024-08-06 14:41 ` bugzilla-daemon
2024-08-06 15:46 ` bugzilla-daemon
2024-08-06 15:50 ` bugzilla-daemon
2024-08-06 19:08 ` bugzilla-daemon
2024-08-07 12:28 ` bugzilla-daemon
2024-08-07 12:29 ` bugzilla-daemon
2024-08-08  7:30 ` bugzilla-daemon
2024-08-08 12:02 ` bugzilla-daemon
2024-08-08 16:19 ` bugzilla-daemon
2024-08-08 17:12 ` bugzilla-daemon
2024-08-08 18:22 ` bugzilla-daemon [this message]
2024-08-08 18:36 ` bugzilla-daemon
2024-08-08 19:49 ` bugzilla-daemon
2024-08-08 20:11 ` bugzilla-daemon
2024-08-09  1:38 ` bugzilla-daemon
2024-08-09  8:14 ` bugzilla-daemon
2024-08-09  9:33 ` bugzilla-daemon
2024-08-09 14:06 ` bugzilla-daemon
2024-08-09 14:56 ` bugzilla-daemon
2024-08-09 15:20 ` bugzilla-daemon
2024-08-09 15:29 ` bugzilla-daemon
2024-08-09 15:44 ` bugzilla-daemon
2024-08-10 10:48 ` bugzilla-daemon
2024-08-10 11:48 ` bugzilla-daemon
2024-08-10 15:49 ` bugzilla-daemon
2024-08-10 17:10 ` bugzilla-daemon
2024-08-10 17:19 ` bugzilla-daemon
2024-08-10 19:37 ` bugzilla-daemon
2024-08-11  1:52 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-219111-208809-gn1ERFC4L8@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).