From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750727AbWGDPzd (ORCPT ); Tue, 4 Jul 2006 11:55:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751279AbWGDPzd (ORCPT ); Tue, 4 Jul 2006 11:55:33 -0400 Received: from ns.suse.de ([195.135.220.2]:30351 "EHLO mx1.suse.de") by vger.kernel.org with ESMTP id S1750727AbWGDPzd (ORCPT ); Tue, 4 Jul 2006 11:55:33 -0400 Date: Tue, 04 Jul 2006 17:55:25 +0200 Message-ID: From: Takashi Iwai To: Johannes Berg Cc: Dmitry Torokhov , linux-input , Richard Purdie , alsa-devel@lists.sourceforge.net, Linux Kernel list , linuxppc-dev list Subject: Re: [Alsa-devel] sound connector detection In-Reply-To: <1151933414.20701.38.camel@localhost> References: <1151671786.13412.6.camel@localhost> <200607011609.59426.dtor@insightbb.com> <1151933414.20701.38.camel@localhost> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta25) (eggplant) (+CVS-20060326) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Mon, 03 Jul 2006 15:30:14 +0200, Johannes Berg wrote: > > > > I am not too happy with putting this kind of switches into input layer, > > it should be reserved for "real" buttons, ones that user can explicitely > > push or toggle (lid switch is on the edge here but it and sleep button > > are used for similar purposes so it makes sense to have it in input layer > > too). But "cable X connected" kind of events is too much [for input layer, > > there could well be a separate layer for it]. If we go this way we'd have > > to move cable detection code from network to input layer as well ;) > > I sort of see the point. But I think it is indeed unfortunate that we > have all these events scattered throughout. I could live with the > current approach abusing the alsa mixer API, but there's little point in > making that element user-visible. So maybe I just need some new alsa > definitions here. Such a control element doesn't have to be IFACE_MIXER if you want to hide. You can use IFACE_CARD, for example, for a card-specific element but not belonging to the mixer component. > Although, come to think of it, a daemon keeping the mixer open blocks > unloading the module. I suppose I'd rather have it the other way around > like the eventdev system does -- the device goes away and all reads to > it fail. That's true. OTOH, invoking a command at each time isn't always a good solution, depending on the event-frequency and heaviness. Takashi