From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: [PATCH] ALSA: hda/jack - Also add jack kctls for Conexant codecs
Date: Thu, 22 Dec 2011 01:08:09 +0000 [thread overview]
Message-ID: <20111222010808.GC27144@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <s5hr4zydm0m.wl%tiwai@suse.de>
On Wed, Dec 21, 2011 at 03:42:17PM +0100, Takashi Iwai wrote:
> Mark Brown wrote:
> > I was rather expecting that the patches would be posted to the list for
> > review at some point (though I may have missed them as not having
> > generic support is really disappointing).
> Err, sorry, I thought I have posted some in RFC, but wasn't there.
> The essential patch for the common helper is attached below.
Thanks. It'll be tomorrow at the earliest before I can read it properly.
> > We should at least verify
> > that the userspace interface isn't going to cause problems for non-HDA
> > systems.
> Well, the kctl-jack part itself can't break anything right now since
> it's used only in HD-audio. If others will use, this will be a pure
> addition, so it won't break except for possibly different ctl numids.
I'm more worried about the userspace interface than the in kernel one,
we can rewrite the kernel if it sucks but we're stuck with userspace.
> The question toward the integration with the input-jack stuff is still
> open. In the HD-audio case, input-jack functions are merged into the
> kctl-jack helpers. But for others, it doesn't have to be so.
I really don't see any reason why you'd want to have to worry about the
specific mechanisms in drivers (and there's also the extcon/switch stuff
that's looking likely to hit soon). Indeed the extcon stuff might make
this needless anyway.
> One remaining obstacle for this integration is that the input-jack
> provides multiple key bits per jack entry while this doesn't exist in
> the kctl notification. With kctl, the notifier says just that the
> value was changed. Then the user-space can query the current value
> (not necessarily a boolean but can be an integer or else), but the
> value isn't passed in the notification itself. So, it's a different
> design.
The detail in the notification seems completely trivial to deal with -
the input layer also provides similar readback support, it just happens
to have a more verbose report (and it needs the cache for readback
anyway as it also uses it to eliminate noop reports).
next prev parent reply other threads:[~2011-12-22 1:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 14:23 [PATCH] ALSA: hda/jack - Also add jack kctls for Conexant codecs David Henningsson
2011-12-20 14:32 ` Takashi Iwai
2011-12-20 14:44 ` Takashi Iwai
2011-12-20 23:58 ` Mark Brown
2011-12-21 14:42 ` Takashi Iwai
2011-12-22 1:08 ` Mark Brown [this message]
2011-12-22 12:21 ` Mark Brown
2011-12-22 13:55 ` Takashi Iwai
2011-12-22 14:12 ` Mark Brown
2011-12-22 14:19 ` Takashi Iwai
2011-12-22 14:29 ` Mark Brown
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=20111222010808.GC27144@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=david.henningsson@canonical.com \
--cc=tiwai@suse.de \
/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).