Fix the $@%* bug already (aka "the long-overdue mentoring posts")

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.