I meant to post yesterday, but
volunteering and cooking for
Thanksgiving were higher priorities. Without further ado...
Recently I dove into the
Ask Ubuntu pond, and as always it's wonderful seeing so many open source contributors assisting each other with goodwill. I deal in defect (aka "bug") reports mainly, and some of the Ask Ubuntu posts seem to be disguised as such reports. When I come upon these posts, I try to
redirect the posters toward the debugging process so that we can resolve the underlying defects. Certain areas in the Ubuntu software stack are notoriously difficult to troubleshoot, and to that end I'm going to document a recent attempt to resolve the user's defect report so that we have some sort of "institutional knowledge transfer." Please feel free to raise pertinent questions and suggestions in the comments.
Here is a
common symptom: "
my laptop's speakers don't mute when I insert headphones." We call this class of bug "jack sense" ones, and it's nearly always a sound driver defect, so it belongs in the "
alsa-driver (Ubuntu)" component in Launchpad. Because the defect has both hardware (sound controller and codec) and software (alsa-driver) portions, we must
obtain sufficient information. For new
defect reports, we request that the reporter use either the
ubuntu-bug alsa-base
command or follow a
more thorough but tedious debugging procedure. For existing bug reports, we request that the reporter use the
apport-collect bugnumber
command or follow the script in the alternate debugging procedure.
Once we've received the requested debugging information, we need to
inspect the sound codec slot's state (aka "codec dump"). Conexant parsers live in
sound/pci/hda/patch_conexant.c in the [kernel] source code. Note the Vendor ID, because it refers to the specific function in the parser, so in this case we look at the
patch_cxt5066() function. Of particular importance is the node ID associated with the headphone jack. This is referred to in the "codec dump" as having "[Jack] HP" in the description string. In this Conexant variant, we're looking thusly at NID 0x19.
Now, a note regarding the current Conexant parsers: there is no automatic BIOS-based setup, and in this way they diverge pretty spectacularly from the Realtek and IDT/Sigmatel ones; emerging Conexant ones are more like Realtek and IDT/Sigmatel. Because there isn't an "auto" model, all entries have to be hard-coded. In the case of
patch_cxt5066(), the default model is
CXT5066_LAPTOP ("laptop" model quirk) and uses
spec->init_verbs[0] = cxt5066_init_verbs;
to initialize the codec.
cxt5066_init_verbs[] has this snippet corresponding to NID 0x19:
/* not handling these yet */
{0x19, AC_VERB_SET_UNSOLICITED_ENABLE, 0},
which means that to properly enable jack sense for the reporter's machine we need to add a function to handle
intrinsic unsolicited responses, specifically Presence Detect. Luckily, a
patch courtesy of
David Henningsson landed earlier this summer adding this very functionality, so we only need to
check that the proper NIDs are referenced, and upon confirmation then
generate a one-line patch to enable jack sense for the bug reporter's machine.
You may notice astutely that I've worded the above process differently from how it appears chronologically in the bug report. The more one works with a particular kernel subsystem (or any software, really) the more readily one is aware how [often] bugs are resolved. In this case, sound driver development moves rapidly, so it's often in the reporter's interest to be using the latest code. Also,
patch tagging and reviewing are important.
