All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Torokhov <dtor@insightbb.com>
Cc: linux-input <linux-input@atrey.karlin.mff.cuni.cz>,
	Richard Purdie <rpurdie@rpsys.net>,
	alsa-devel@lists.sourceforge.net,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: sound connector detection
Date: Mon, 03 Jul 2006 15:30:14 +0200	[thread overview]
Message-ID: <1151933414.20701.38.camel@localhost> (raw)
In-Reply-To: <200607011609.59426.dtor@insightbb.com>


[-- Attachment #1.1: Type: text/plain, Size: 1073 bytes --]


> 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.

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.

johannes

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

[-- Attachment #2: Type: text/plain, Size: 299 bytes --]

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Torokhov <dtor@insightbb.com>
Cc: linux-input <linux-input@atrey.karlin.mff.cuni.cz>,
	Richard Purdie <rpurdie@rpsys.net>,
	alsa-devel@lists.sourceforge.net,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: sound connector detection
Date: Mon, 03 Jul 2006 15:30:14 +0200	[thread overview]
Message-ID: <1151933414.20701.38.camel@localhost> (raw)
In-Reply-To: <200607011609.59426.dtor@insightbb.com>

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


> 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.

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.

johannes

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

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Torokhov <dtor@insightbb.com>
Cc: alsa-devel@lists.sourceforge.net,
	linux-input <linux-input@atrey.karlin.mff.cuni.cz>,
	Richard Purdie <rpurdie@rpsys.net>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: sound connector detection
Date: Mon, 03 Jul 2006 15:30:14 +0200	[thread overview]
Message-ID: <1151933414.20701.38.camel@localhost> (raw)
In-Reply-To: <200607011609.59426.dtor@insightbb.com>

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


> 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.

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.

johannes

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

  parent reply	other threads:[~2006-07-03 13:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-30 12:49 sound connector detection Johannes Berg
2006-06-30 12:49 ` Johannes Berg
2006-06-30 12:49 ` Johannes Berg
2006-07-01 20:09 ` Dmitry Torokhov
2006-07-01 20:09   ` Dmitry Torokhov
2006-07-01 20:09   ` Dmitry Torokhov
2006-07-02  9:28   ` Richard Purdie
2006-07-02  9:28     ` Richard Purdie
2006-07-02  9:28     ` Richard Purdie
2006-07-03  2:48     ` Dmitry Torokhov
2006-07-03  2:48       ` Dmitry Torokhov
2006-07-03 13:31       ` Johannes Berg
2006-07-03 13:31         ` Johannes Berg
2006-07-03 13:31         ` Johannes Berg
2006-07-03 13:30   ` Johannes Berg [this message]
2006-07-03 13:30     ` Johannes Berg
2006-07-03 13:30     ` Johannes Berg
2006-07-04 15:55     ` Takashi Iwai
2006-07-04 15:55       ` [Alsa-devel] " Takashi Iwai
2006-07-04 15:55       ` Takashi Iwai
2006-07-04 18:51       ` Johannes Berg
2006-07-04 18:51         ` [Alsa-devel] " Johannes Berg
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=1151933414.20701.38.camel@localhost \
    --to=johannes@sipsolutions.net \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=dtor@insightbb.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.