Bug 494284 – linux breaks headphones in windows

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Jonathan Fraser 2013-12-15 01:50:51 UTC]

Since this is a cross OS bug, I will place it here in the hopes that it is picked up by a wise a noble champion. Fearless enough to wade into the bowels of the beast which is linux sound.    

After a warm reboot from linux into windows 7, the head phone jack no longer works (in windows). The main speakers will mute but, no sound out of the headphones. The headphones always work in gentoo.  While you may think aha, this is a windows bug. But no no my friend, as a cold boot or reboot from windows leaves the headphones in a working state. 

It appears as though the linux sound system places the sound card in such a state that the headphones become unusable from windows.

Reproducible: Always

Steps to Reproduce:
1.Have a dual boot system of the appropriate hardware
2.boot into linux, enjoy headphones
3.reboot into windows
4.cry silently
Actual Results:  
The headphones mute the main speakers in windows but produce no sound.

Expected Results:  
the headphones should work in windows regardless of what OS I rebooted from.

Laptop, G74Sx with a realtek sound card. This uses the intel_hda module. The particular realtek chip is ALC269VB.

[Comment 1 Tom Wijsman (TomWij) (RETIRED) 2013-12-15 02:05:57 UTC]

The state with which you boot your computer is not a more working state that the state with which you reboot, neither are they as bad as one another; they are just, well, a slight bit different. And that's why assuming the state you boot with is a good state; because if you do so, it depends on how you boot. And doing that during boot, that sounds like a bug to me. Given that it works on Gentoo, I am quite convinced we left a good state behind; seems it isn't picked up well.

[Comment 2 Tom Wijsman (TomWij) (RETIRED) 2013-12-15 02:09:00 UTC]

Two typos there, it is late here: s/that/than/ s/state;/state is bad;/

[Comment 3 Jonathan Fraser 2013-12-15 05:41:22 UTC]

I had a feeling this is the response I would get. NMP is way to easy to say. The truth is, it is a Realtek card, therefore Realtek gets to decide what the valid configuration states of its card are. Since there are probably no published standards this must be guessed; however, it is still Realtek that gets to decide that, they built the hardware. If Gentoo/linux is placing the card in a configuration state not recognized by the OEM (although perhaps functional) this is a bug of Gentoo/linux. If this is causing erratic behaviour it is a bug that should be fixed.  

What if some dev decided to, lets say, erase all the firmware in the system, but it's ok because it always reloads it at boot. This would break every OS that expects the firmware to be there but linux would load fine. That behaviour is pretty unambiguously not acceptable. This is the logic you seem to be missing. 

Because Gentoo/linux is reverse engineering drivers/userland, it is their responsibility not make changes which break compatibility with the hardware manufacture's specifications whether they are published or not.

[Comment 4 Tom Wijsman (TomWij) (RETIRED) 2013-12-15 09:09:09 UTC]

You will want to file this upstream or at the manufacturer that develops the module, it is still NPM because we do not patch intel_hda at this moment; what can we do about something that is outside the scope of Gentoo Linux itself?

You can use https://bugzilla.kernel.org/ to report Linux kernel bugs.

Reverse engineering is unnecessary, because of manufacturer contributions:

 $ grep -i 'copyright\|contacts\|\(realtek\|intel\).com' /usr/src/linux/sound/pci/hda/hda_intel.c
 *  Copyright(c) 2004 Intel Corporation. All rights reserved.
 *  Copyright (c) 2004 Takashi Iwai <[e-mail]>
 *                     PeiSen Hou <[e-mail]>
 *  CONTACTS:
 *  Matt Jared		[e-mail]
 *  Andy Kopp		[e-mail]
 *  Dan Kogan		[e-mail]

It is thus the manufacturer's responsibility to keep compatibility.