From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Clemens Ladisch" Subject: Re: Channel mapping Date: Wed, 21 Nov 2007 16:17:41 +0100 Message-ID: <1195658261.9272.1222564051@webmail.messagingengine.com> References: <20071120005151.GA25276@tango.0pointer.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by alsa0.perex.cz (Postfix) with ESMTP id 843A5243C6 for ; Wed, 21 Nov 2007 16:17:42 +0100 (CET) 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 , Lennart Poettering Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org Takashi Iwai wrote: > Yes, querying channel mapping is another missing piece with popular > demand. > > The implementation would be easy, I guess. But we have to define the > way to inform this from kernel to user space: whether create a new > ioctl or extend the existing ones (if possible)... It's just metadata that describes a PCM device, so I think we should use TLV for this. The existing struct snd_ctl_tlv uses a single integer to identify control elements. We could restrict control numid's to 31 bits and use the upper bit to signal that this value includes device type and device number in the lower bits, if we want to reuse the same TLV ioctls. Regards, Clemens