From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: Jack event API - decision needed Date: Tue, 28 Jun 2011 19:59:18 -0700 Message-ID: <20110629025916.GA22472@opensource.wolfsonmicro.com> References: <4DFF4D15.6050809@canonical.com> <20110627120743.GA20707@sirena.org.uk> <4E0A00E3.5000102@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from opensource2.wolfsonmicro.com (opensource.wolfsonmicro.com [80.75.67.52]) by alsa0.perex.cz (Postfix) with ESMTP id 64F8D245CF for ; Wed, 29 Jun 2011 04:59:22 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: ALSA Development Mailing List , Kay Sievers , Lennart Poettering , David Henningsson List-Id: alsa-devel@alsa-project.org On Tue, Jun 28, 2011 at 06:35:33PM +0200, Takashi Iwai wrote: > If only the same functionality is required as currently done in the > input-jack layer, re-implementing the jack-detection elements in ALSA > control API is pretty easy. It means that the control element would > have some jack name with a location prefix or such, reports the > current jack status, and notifies the jack change. That's all. > Optionally, it can have a TLV data giving the HD-audio jack > attribute, too. It needs a subset of the current information - it should report only audio events, so pretty much only headphone, microphone or line out presence. Anything else needs to be reported via a different API and figured out by userspace, and the input device should stay there for button press events.