linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: alsa-devel@lists.sourceforge.net
Cc: linux-input <linux-input@atrey.karlin.mff.cuni.cz>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Richard Purdie <rpurdie@rpsys.net>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: sound connector detection
Date: Fri, 30 Jun 2006 14:49:46 +0200	[thread overview]
Message-ID: <1151671786.13412.6.camel@localhost> (raw)

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Hi,

One Apple machines I have with snd-aoa the situation that the alsa
driver can detect changes in in/output connector state ("is headphone
plugged in" etc.) and currently surfaces it through a read-only alsa
mixer element. That isn't really ideal since nothing is prepared to
handle such events, hence I provide an additional control that allows an
in-kernel toggle from speakers to headphone on headphone plug (and vice
versa).

I'd really like to see this handled in userspace (additionally or
possibly event instead), since there are complications especially with
input (line-in) detection and user preferences of what should happen
then. The number of cases can become large, especially when throwing in
digital and combo connectors that aren't handled yet.

Now, is it appropriate to create an input device for the state of these
things and add new constants like SW_LINEIN_INSERTED,
SW_LINEOUT_INSERTED, SW_OPTICALOUT_INSERTED, SW_OPTICALIN_INSERTED and
if so, how do I reflect the fact that on some machines optical and
analog input/output is mutually exclusive, while on others it isn't?
That would probably require another SW_COMBO_IN/OUT set...

Or should I simply stick with (a) read-only mixer control(s), and for
the mutually exclusive case create a tristate (none, optical, analog)
one? But SW_HEADPHONE_INSERT already exists, so we may want to do this
identically on different machines.

Comments appreciated.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

             reply	other threads:[~2006-07-01 16:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-30 12:49 Johannes Berg [this message]
2006-07-01 20:09 ` sound connector detection Dmitry Torokhov
2006-07-02  9:28   ` Richard Purdie
2006-07-03  2:48     ` Dmitry Torokhov
2006-07-03 13:31       ` Johannes Berg
2006-07-03 13:30   ` Johannes Berg
2006-07-04 15:55     ` [Alsa-devel] " Takashi Iwai
2006-07-04 18:51       ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1151671786.13412.6.camel@localhost \
    --to=johannes@sipsolutions.net \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).