I have a pair of (3.5mm) headphones that work fine but send erroneous headphone control signals (i.e. raising and lowering the volume, skipping/pausing). Personally, I never use inline headphone controls anyway.
I'm pretty sure there isn't any official way to disable inline headphone controls on Windows, but is there a registry hack, or an external program that could do the same thing? Thanks!
So.. AFAIU from the linux documentation and code, jack keys mapping is handled not by the general HDA controller but it's up to the specific codec chip (which makes sense considering it's the thing sitting right behind the physical TR(R)S connector, and how detection works).
After poking a bit around the drivers for my Conexant CX20751 (you can easily see what they are in the device manager, from the driver details of the device immediately within "High Definition Audio Controller" when you view them by connection), I actually found they had some explicit knob *somehow* related to this. In the Windows registry class dedicated to multimedia devices (HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e96c-e325-11ce-bfc1-08002be10318}), there is the Settings\EPattributes\EPSettings\HeadsetCtrlEnable subkey which seems all about it. In particular toggling the Enable and ForceDisableHeadset values could probably be enough to thwart the parsing of the buttons signal.
And a bit more generically, there are usually a thousand and one ways that you can retask the jacks to force them into one dumb state (one of the old desktop tricks with quirky microphones or speakers, was to misconfigure with the AC97 standard the front panel). Almost certainly, with Realtek solutions you could use their "driver test utility" to do something.
All of this is very hardware specific though (on top of extremely undocumented) and so I guess it's not 100% a solution.
Very much presumably we are then left with something like a VK_VOLUME_DOWN/APPCOMMAND_VOLUME_DOWN message haunting the system (but seriously, this is just a guess, don't at me.. I wonder if ASIO playback that bypasses the Windows audio service couldn't also work around that).
Thankfully this is a step that we can tinker with too (especially since it's up to individual programs to actually interpret and respect the commands). But I'll leave you to my answer to another question about media keys.
