At Fri, 06 Mar 2015 11:20:22 +0100, David Henningsson wrote:
On 2015-03-06 10:57, Ingo Brückl wrote:
Takashi Iwai wrote on Fri, 06 Mar 2015 10:38:49 +0100:
Even if you try parsing the topology at first with ignoring 0x15, you'll need to add the path over 0x15 manually back to the information. Otherwise it can't work.
Why can't it work? I'm not going to use the speaker.
There is no known hardware that has an speaker with no connection to it (and it would be a BIOS error if there was one), so it is not a priority (perhaps not even of interest) of the driver to support it. Especially not as the option of using e g hdajackretask [1] to disable the speaker permanently is an easier and better way than starting to mess around with the connections and paths manually.
I understand that your intentions are good and that you want to help other users as well, and I don't want to scare you off, but in this case it seems to me like you have some private patches that makes the driver half broken, and then you want the official Linux kernel to fix up your private half broken scenario. Which doesn't really make sense.
Right. The big difference is "not using" and "disabling". The former is user's decision, but without telling the driver to disable the functionality, the driver must still assume that it might be used in future. So, a more desirable solution for the former would be to implement the automatic speaker on/off (and limit the auto-mute behavior) depending on the channel mode configuration. This will need a lot of work.
OTOH, the latter can be achieved easily by changing the pin default configuration, even dynamically reconfigurable via hdajackretask, as David suggested.
Takashi
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
[1] or the kernel interfaces that hdajackretask is a front-end for