* [PATCH] Provide sequencer sound card number / PID via alsa-lib
@ 2016-02-12 18:57 Martin Koegler
2016-02-13 12:36 ` Takashi Sakamoto
0 siblings, 1 reply; 21+ messages in thread
From: Martin Koegler @ 2016-02-12 18:57 UTC (permalink / raw)
To: alsa-devel; +Cc: Martin Koegler
From: Martin Koegler <martin.koegler@chello.at>
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
include/seq.h | 1 +
include/sound/asequencer.h | 5 +++--
src/seq/seq.c | 11 +++++++++++
src/seq/seq_hw.c | 8 +++++++-
4 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/seq.h b/include/seq.h
index 9576822..77996e5 100644
--- a/include/seq.h
+++ b/include/seq.h
@@ -143,6 +143,7 @@ snd_seq_client_type_t snd_seq_client_info_get_type(const snd_seq_client_info_t *
const char *snd_seq_client_info_get_name(snd_seq_client_info_t *info);
int snd_seq_client_info_get_broadcast_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info);
+int snd_seq_client_info_get_owner(const snd_seq_client_info_t *info);
const unsigned char *snd_seq_client_info_get_event_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_num_ports(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_event_lost(const snd_seq_client_info_t *info);
diff --git a/include/sound/asequencer.h b/include/sound/asequencer.h
index 09c8a00..7ebf7fd 100644
--- a/include/sound/asequencer.h
+++ b/include/sound/asequencer.h
@@ -24,7 +24,7 @@
/** version of the sequencer */
-#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
+#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
/**
* definition of sequencer event types
@@ -356,7 +356,8 @@ struct snd_seq_client_info {
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
- char reserved[64]; /* for future use */
+ int owner; /* RO: card number[kernel] / PID[user] */
+ char reserved[64 - sizeof(int)]; /* for future use */
};
diff --git a/src/seq/seq.c b/src/seq/seq.c
index 620ca3f..2505293 100644
--- a/src/seq/seq.c
+++ b/src/seq/seq.c
@@ -1522,6 +1522,17 @@ int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info)
}
/**
+ * \brief Get the sound card number (kernel) or owning PID
+ * \param info client_info container
+ * \return card number/PID/-1 if value is not available.
+ */
+int snd_seq_client_info_get_owner(const snd_seq_client_info_t *info)
+{
+ assert(info);
+ return info->owner;
+}
+
+/**
* \brief (DEPRECATED) Get the event filter bitmap of a client_info container
* \param info client_info container
* \return NULL if no event filter, or pointer to event filter bitmap
diff --git a/src/seq/seq_hw.c b/src/seq/seq_hw.c
index d033367..a4c083a 100644
--- a/src/seq/seq_hw.c
+++ b/src/seq/seq_hw.c
@@ -32,10 +32,11 @@ const char *_snd_module_seq_hw = "";
#ifndef DOC_HIDDEN
#define SNDRV_FILE_SEQ ALSA_DEVICE_DIRECTORY "seq"
#define SNDRV_FILE_ALOADSEQ ALOAD_DEVICE_DIRECTORY "aloadSEQ"
-#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 1)
+#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 2)
typedef struct {
int fd;
+ int micro_version;
} snd_seq_hw_t;
#endif /* DOC_HIDDEN */
@@ -100,6 +101,8 @@ static int snd_seq_hw_get_client_info(snd_seq_t *seq, snd_seq_client_info_t * in
/*SYSERR("SNDRV_SEQ_IOCTL_GET_CLIENT_INFO failed");*/
return -errno;
}
+ if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX))
+ info->owner = -1;
return 0;
}
@@ -368,6 +371,8 @@ static int snd_seq_hw_query_next_client(snd_seq_t *seq, snd_seq_client_info_t *i
/*SYSERR("SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT failed");*/
return -errno;
}
+ if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX))
+ info->owner = -1;
return 0;
}
@@ -480,6 +485,7 @@ int snd_seq_hw_open(snd_seq_t **handle, const char *name, int streams, int mode)
return -ENOMEM;
}
hw->fd = fd;
+ hw->micro_version = SNDRV_PROTOCOL_MICRO(ver);
if (streams & SND_SEQ_OPEN_OUTPUT) {
seq->obuf = (char *) malloc(seq->obufsize = SND_SEQ_OBUF_SIZE);
if (!seq->obuf) {
--
2.1.4
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide sequencer sound card number / PID via alsa-lib
2016-02-12 18:57 Martin Koegler
@ 2016-02-13 12:36 ` Takashi Sakamoto
2016-02-13 12:45 ` Martin Koegler
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Sakamoto @ 2016-02-13 12:36 UTC (permalink / raw)
To: Martin Koegler, alsa-devel
Hi,
On Feb 13 2016 03:57, Martin Koegler wrote:
> From: Martin Koegler <martin.koegler@chello.at>
>
> Signed-off-by: Martin Koegler <martin.koegler@chello.at>
This is related to your below patch.
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104229.html
Would you please re-post this patch with your comments again so that the
other developers can get to know your intension?
> ---
> include/seq.h | 1 +
> include/sound/asequencer.h | 5 +++--
> src/seq/seq.c | 11 +++++++++++
> src/seq/seq_hw.c | 8 +++++++-
> 4 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/include/seq.h b/include/seq.h
> index 9576822..77996e5 100644
> --- a/include/seq.h
> +++ b/include/seq.h
> @@ -143,6 +143,7 @@ snd_seq_client_type_t snd_seq_client_info_get_type(const snd_seq_client_info_t *
> const char *snd_seq_client_info_get_name(snd_seq_client_info_t *info);
> int snd_seq_client_info_get_broadcast_filter(const snd_seq_client_info_t *info);
> int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info);
> +int snd_seq_client_info_get_owner(const snd_seq_client_info_t *info);
> const unsigned char *snd_seq_client_info_get_event_filter(const snd_seq_client_info_t *info);
> int snd_seq_client_info_get_num_ports(const snd_seq_client_info_t *info);
> int snd_seq_client_info_get_event_lost(const snd_seq_client_info_t *info);
> diff --git a/include/sound/asequencer.h b/include/sound/asequencer.h
> index 09c8a00..7ebf7fd 100644
> --- a/include/sound/asequencer.h
> +++ b/include/sound/asequencer.h
> @@ -24,7 +24,7 @@
>
>
> /** version of the sequencer */
> -#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
> +#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
>
> /**
> * definition of sequencer event types
> @@ -356,7 +356,8 @@ struct snd_seq_client_info {
> unsigned char event_filter[32]; /* event filter bitmap */
> int num_ports; /* RO: number of ports */
> int event_lost; /* number of lost events */
> - char reserved[64]; /* for future use */
> + int owner; /* RO: card number[kernel] / PID[user] */
> + char reserved[64 - sizeof(int)]; /* for future use */
> };
>
>
> diff --git a/src/seq/seq.c b/src/seq/seq.c
> index 620ca3f..2505293 100644
> --- a/src/seq/seq.c
> +++ b/src/seq/seq.c
> @@ -1522,6 +1522,17 @@ int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info)
> }
>
> /**
> + * \brief Get the sound card number (kernel) or owning PID
> + * \param info client_info container
> + * \return card number/PID/-1 if value is not available.
> + */
> +int snd_seq_client_info_get_owner(const snd_seq_client_info_t *info)
> +{
> + assert(info);
> + return info->owner;
> +}
> +
> +/**
> * \brief (DEPRECATED) Get the event filter bitmap of a client_info container
> * \param info client_info container
> * \return NULL if no event filter, or pointer to event filter bitmap
> diff --git a/src/seq/seq_hw.c b/src/seq/seq_hw.c
> index d033367..a4c083a 100644
> --- a/src/seq/seq_hw.c
> +++ b/src/seq/seq_hw.c
> @@ -32,10 +32,11 @@ const char *_snd_module_seq_hw = "";
> #ifndef DOC_HIDDEN
> #define SNDRV_FILE_SEQ ALSA_DEVICE_DIRECTORY "seq"
> #define SNDRV_FILE_ALOADSEQ ALOAD_DEVICE_DIRECTORY "aloadSEQ"
> -#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 1)
> +#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 2)
>
> typedef struct {
> int fd;
> + int micro_version;
> } snd_seq_hw_t;
> #endif /* DOC_HIDDEN */
>
> @@ -100,6 +101,8 @@ static int snd_seq_hw_get_client_info(snd_seq_t *seq, snd_seq_client_info_t * in
> /*SYSERR("SNDRV_SEQ_IOCTL_GET_CLIENT_INFO failed");*/
> return -errno;
> }
> + if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX))
> + info->owner = -1;
> return 0;
> }
>
> @@ -368,6 +371,8 @@ static int snd_seq_hw_query_next_client(snd_seq_t *seq, snd_seq_client_info_t *i
> /*SYSERR("SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT failed");*/
> return -errno;
> }
> + if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX))
> + info->owner = -1;
> return 0;
> }
>
> @@ -480,6 +485,7 @@ int snd_seq_hw_open(snd_seq_t **handle, const char *name, int streams, int mode)
> return -ENOMEM;
> }
> hw->fd = fd;
> + hw->micro_version = SNDRV_PROTOCOL_MICRO(ver);
> if (streams & SND_SEQ_OPEN_OUTPUT) {
> seq->obuf = (char *) malloc(seq->obufsize = SND_SEQ_OBUF_SIZE);
> if (!seq->obuf) {
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide sequencer sound card number / PID via alsa-lib
2016-02-13 12:36 ` Takashi Sakamoto
@ 2016-02-13 12:45 ` Martin Koegler
0 siblings, 0 replies; 21+ messages in thread
From: Martin Koegler @ 2016-02-13 12:45 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel, Martin Koegler
On Sat, Feb 13, 2016 at 09:36:46PM +0900, Takashi Sakamoto wrote:
> On Feb 13 2016 03:57, Martin Koegler wrote:
> > From: Martin Koegler <martin.koegler@chello.at>
> >
> > Signed-off-by: Martin Koegler <martin.koegler@chello.at>
>
> This is related to your below patch.
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104229.html
>
> Would you please re-post this patch with your comments again so that the
> other developers can get to know your intension?
I will repost.
There is a 3rd related kernel patch:
https://patchwork.kernel.org/bundle/e9925248/provide%20sequencer%20sound%20card/
Regards,
Martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] Provide sequencer sound card number / PID via alsa-lib
@ 2016-02-13 13:42 Martin Koegler
2016-02-13 13:42 ` [PATCH] Show sequencer sound card numer/PID via aconnect Martin Koegler
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Martin Koegler @ 2016-02-13 13:42 UTC (permalink / raw)
To: alsa-devel; +Cc: Martin Koegler
From: Martin Koegler <martin.koegler@chello.at>
rawmidi devices expose the card number via IOCTLs, which allows to
find the corresponding device in sysfs.
The sequencer provides no identifing data. Chromium works around this
issue by scanning rawmidi as well as sequencer devices and matching
them by using assumtions, how the kernel register sequencer devices.
This changes adds support for exposing the card number for kernel clients
as well as the PID for user client.
It supports kernels with and without the required support.
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
include/seq.h | 1 +
include/sound/asequencer.h | 5 +++--
src/seq/seq.c | 11 +++++++++++
src/seq/seq_hw.c | 8 +++++++-
4 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/seq.h b/include/seq.h
index 9576822..77996e5 100644
--- a/include/seq.h
+++ b/include/seq.h
@@ -143,6 +143,7 @@ snd_seq_client_type_t snd_seq_client_info_get_type(const snd_seq_client_info_t *
const char *snd_seq_client_info_get_name(snd_seq_client_info_t *info);
int snd_seq_client_info_get_broadcast_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info);
+int snd_seq_client_info_get_owner(const snd_seq_client_info_t *info);
const unsigned char *snd_seq_client_info_get_event_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_num_ports(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_event_lost(const snd_seq_client_info_t *info);
diff --git a/include/sound/asequencer.h b/include/sound/asequencer.h
index 09c8a00..7ebf7fd 100644
--- a/include/sound/asequencer.h
+++ b/include/sound/asequencer.h
@@ -24,7 +24,7 @@
/** version of the sequencer */
-#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
+#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
/**
* definition of sequencer event types
@@ -356,7 +356,8 @@ struct snd_seq_client_info {
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
- char reserved[64]; /* for future use */
+ int owner; /* RO: card number[kernel] / PID[user] */
+ char reserved[64 - sizeof(int)]; /* for future use */
};
diff --git a/src/seq/seq.c b/src/seq/seq.c
index 620ca3f..2505293 100644
--- a/src/seq/seq.c
+++ b/src/seq/seq.c
@@ -1522,6 +1522,17 @@ int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info)
}
/**
+ * \brief Get the sound card number (kernel) or owning PID
+ * \param info client_info container
+ * \return card number/PID/-1 if value is not available.
+ */
+int snd_seq_client_info_get_owner(const snd_seq_client_info_t *info)
+{
+ assert(info);
+ return info->owner;
+}
+
+/**
* \brief (DEPRECATED) Get the event filter bitmap of a client_info container
* \param info client_info container
* \return NULL if no event filter, or pointer to event filter bitmap
diff --git a/src/seq/seq_hw.c b/src/seq/seq_hw.c
index d033367..a4c083a 100644
--- a/src/seq/seq_hw.c
+++ b/src/seq/seq_hw.c
@@ -32,10 +32,11 @@ const char *_snd_module_seq_hw = "";
#ifndef DOC_HIDDEN
#define SNDRV_FILE_SEQ ALSA_DEVICE_DIRECTORY "seq"
#define SNDRV_FILE_ALOADSEQ ALOAD_DEVICE_DIRECTORY "aloadSEQ"
-#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 1)
+#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 2)
typedef struct {
int fd;
+ int micro_version;
} snd_seq_hw_t;
#endif /* DOC_HIDDEN */
@@ -100,6 +101,8 @@ static int snd_seq_hw_get_client_info(snd_seq_t *seq, snd_seq_client_info_t * in
/*SYSERR("SNDRV_SEQ_IOCTL_GET_CLIENT_INFO failed");*/
return -errno;
}
+ if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX))
+ info->owner = -1;
return 0;
}
@@ -368,6 +371,8 @@ static int snd_seq_hw_query_next_client(snd_seq_t *seq, snd_seq_client_info_t *i
/*SYSERR("SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT failed");*/
return -errno;
}
+ if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX))
+ info->owner = -1;
return 0;
}
@@ -480,6 +485,7 @@ int snd_seq_hw_open(snd_seq_t **handle, const char *name, int streams, int mode)
return -ENOMEM;
}
hw->fd = fd;
+ hw->micro_version = SNDRV_PROTOCOL_MICRO(ver);
if (streams & SND_SEQ_OPEN_OUTPUT) {
seq->obuf = (char *) malloc(seq->obufsize = SND_SEQ_OBUF_SIZE);
if (!seq->obuf) {
--
2.6.2
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH] Show sequencer sound card numer/PID via aconnect
2016-02-13 13:42 [PATCH] Provide sequencer sound card number / PID via alsa-lib Martin Koegler
@ 2016-02-13 13:42 ` Martin Koegler
2016-02-13 13:42 ` [PATCH] Provide card number / PID via sequencer client info Martin Koegler
2016-02-15 10:39 ` [PATCH] Provide sequencer sound card number / PID via alsa-lib Clemens Ladisch
2 siblings, 0 replies; 21+ messages in thread
From: Martin Koegler @ 2016-02-13 13:42 UTC (permalink / raw)
To: alsa-devel; +Cc: Martin Koegler
From: Martin Koegler <martin.koegler@chello.at>
rawmidi devices expose the card number via IOCTLs, which allows to
find the corresponding device in sysfs.
The sequencer provides no identifing data. Chromium works around this
issue by scanning rawmidi as well as sequencer devices and matching
them by using assumtions, how the kernel register sequencer devices.
This patch adds support for displaying the sound card number/PID to
aconnect.
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
seq/aconnect/aconnect.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/seq/aconnect/aconnect.c b/seq/aconnect/aconnect.c
index 8d6cebb..3508e1b 100644
--- a/seq/aconnect/aconnect.c
+++ b/seq/aconnect/aconnect.c
@@ -166,11 +166,19 @@ static void print_port(snd_seq_t *seq, snd_seq_client_info_t *cinfo,
snd_seq_port_info_t *pinfo, int count)
{
if (! count) {
- printf(_("client %d: '%s' [type=%s]\n"),
+ printf(_("client %d: '%s' [type=%s"),
snd_seq_client_info_get_client(cinfo),
snd_seq_client_info_get_name(cinfo),
(snd_seq_client_info_get_type(cinfo) == SND_SEQ_USER_CLIENT ?
_("user") : _("kernel")));
+ int owner = snd_seq_client_info_get_owner(cinfo);
+ if (owner != -1) {
+ if (snd_seq_client_info_get_type(cinfo) == SND_SEQ_USER_CLIENT)
+ printf(",pid=%d", owner);
+ else
+ printf(",card=%d", owner);
+ }
+ printf("]\n");
}
printf(" %3d '%-16s'\n",
snd_seq_port_info_get_port(pinfo),
--
2.6.2
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH] Provide card number / PID via sequencer client info
2016-02-13 13:42 [PATCH] Provide sequencer sound card number / PID via alsa-lib Martin Koegler
2016-02-13 13:42 ` [PATCH] Show sequencer sound card numer/PID via aconnect Martin Koegler
@ 2016-02-13 13:42 ` Martin Koegler
2016-02-15 10:30 ` Takashi Iwai
2016-02-15 10:39 ` [PATCH] Provide sequencer sound card number / PID via alsa-lib Clemens Ladisch
2 siblings, 1 reply; 21+ messages in thread
From: Martin Koegler @ 2016-02-13 13:42 UTC (permalink / raw)
To: alsa-devel; +Cc: Martin Koegler
From: Martin Koegler <martin.koegler@chello.at>
rawmidi devices expose the card number via IOCTLs, which allows to
find the corresponding device in sysfs.
The sequencer provides no identifing data. Chromium works around this
issue by scanning rawmidi as well as sequencer devices and matching
them by using assumtions, how the kernel register sequencer devices.
This changes adds support for exposing the card number for kernel clients
as well as the PID for user client.
The minor of the API version is changed to distinguish between the zero
initialised reserved field and card number 0.
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
include/uapi/sound/asequencer.h | 5 +++--
sound/core/seq/seq_clientmgr.c | 18 ++++++++++++++++++
sound/core/seq/seq_clientmgr.h | 2 ++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h
index 5a5fa49..4726579 100644
--- a/include/uapi/sound/asequencer.h
+++ b/include/uapi/sound/asequencer.h
@@ -25,7 +25,7 @@
#include <sound/asound.h>
/** version of the sequencer */
-#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
+#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
/**
* definition of sequencer event types
@@ -357,7 +357,8 @@ struct snd_seq_client_info {
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
- char reserved[64]; /* for future use */
+ int owner; /* RO: card number[kernel] / PID[user] */
+ char reserved[64 - sizeof(int)]; /* for future use */
};
diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index 58e79e0..ac07ab7 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -364,6 +364,7 @@ static int snd_seq_open(struct inode *inode, struct file *file)
/* fill client data */
user->file = file;
sprintf(client->name, "Client-%d", c);
+ client->data.user.owner = get_pid(task_pid(current));
/* make others aware this new client */
snd_seq_system_client_ev_client_start(c);
@@ -380,6 +381,7 @@ static int snd_seq_release(struct inode *inode, struct file *file)
seq_free_client(client);
if (client->data.user.fifo)
snd_seq_fifo_delete(&client->data.user.fifo);
+ put_pid(client->data.user.owner);
kfree(client);
}
@@ -1197,6 +1199,21 @@ static void get_client_info(struct snd_seq_client *cptr,
info->event_lost = cptr->event_lost;
memcpy(info->event_filter, cptr->event_filter, 32);
info->num_ports = cptr->num_ports;
+
+ switch (cptr->type) {
+ case USER_CLIENT:
+ info->owner = pid_vnr(cptr->data.user.owner);
+ break;
+
+ case KERNEL_CLIENT:
+ info->owner = cptr->data.kernel.card ? cptr->data.kernel.card->number : -1;
+ break;
+
+ default:
+ info->owner = -1;
+ break;
+ }
+
memset(info->reserved, 0, sizeof(info->reserved));
}
@@ -2271,6 +2288,7 @@ int snd_seq_create_kernel_client(struct snd_card *card, int client_index,
client->accept_input = 1;
client->accept_output = 1;
+ client->data.kernel.card = card;
va_start(args, name_fmt);
vsnprintf(client->name, sizeof(client->name), name_fmt, args);
diff --git a/sound/core/seq/seq_clientmgr.h b/sound/core/seq/seq_clientmgr.h
index 20f0a72..031462e 100644
--- a/sound/core/seq/seq_clientmgr.h
+++ b/sound/core/seq/seq_clientmgr.h
@@ -33,6 +33,7 @@
struct snd_seq_user_client {
struct file *file; /* file struct of client */
/* ... */
+ struct pid* owner;
/* fifo */
struct snd_seq_fifo *fifo; /* queue for incoming events */
@@ -41,6 +42,7 @@ struct snd_seq_user_client {
struct snd_seq_kernel_client {
/* ... */
+ struct snd_card* card;
};
--
2.1.4
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-13 13:42 ` [PATCH] Provide card number / PID via sequencer client info Martin Koegler
@ 2016-02-15 10:30 ` Takashi Iwai
2016-02-15 10:37 ` Clemens Ladisch
2016-02-15 18:32 ` Martin Koegler
0 siblings, 2 replies; 21+ messages in thread
From: Takashi Iwai @ 2016-02-15 10:30 UTC (permalink / raw)
To: Martin Koegler; +Cc: alsa-devel
On Sat, 13 Feb 2016 14:42:17 +0100,
Martin Koegler wrote:
>
> From: Martin Koegler <martin.koegler@chello.at>
>
> rawmidi devices expose the card number via IOCTLs, which allows to
> find the corresponding device in sysfs.
>
> The sequencer provides no identifing data. Chromium works around this
> issue by scanning rawmidi as well as sequencer devices and matching
> them by using assumtions, how the kernel register sequencer devices.
>
> This changes adds support for exposing the card number for kernel clients
> as well as the PID for user client.
>
> The minor of the API version is changed to distinguish between the zero
> initialised reserved field and card number 0.
>
> Signed-off-by: Martin Koegler <martin.koegler@chello.at>
The idea looks good. One remaining question is whether only providing
the card number or pid is sufficient for all cases.
Some review comments below:
> ---
> include/uapi/sound/asequencer.h | 5 +++--
> sound/core/seq/seq_clientmgr.c | 18 ++++++++++++++++++
> sound/core/seq/seq_clientmgr.h | 2 ++
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h
> index 5a5fa49..4726579 100644
> --- a/include/uapi/sound/asequencer.h
> +++ b/include/uapi/sound/asequencer.h
> @@ -25,7 +25,7 @@
> #include <sound/asound.h>
>
> /** version of the sequencer */
> -#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
> +#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
>
> /**
> * definition of sequencer event types
> @@ -357,7 +357,8 @@ struct snd_seq_client_info {
> unsigned char event_filter[32]; /* event filter bitmap */
> int num_ports; /* RO: number of ports */
> int event_lost; /* number of lost events */
> - char reserved[64]; /* for future use */
> + int owner; /* RO: card number[kernel] / PID[user] */
> + char reserved[64 - sizeof(int)]; /* for future use */
The sizeof(int) is always 4. So let's make it explicit.
But, please make sure that this change won't lead to any
incompatibility. Some architectures might align with 64bit long,
although the 32bit int and the rest char[] should be fine on all known
architectures, AFAIK.
> };
>
>
> diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
> index 58e79e0..ac07ab7 100644
> --- a/sound/core/seq/seq_clientmgr.c
> +++ b/sound/core/seq/seq_clientmgr.c
> @@ -364,6 +364,7 @@ static int snd_seq_open(struct inode *inode, struct file *file)
> /* fill client data */
> user->file = file;
> sprintf(client->name, "Client-%d", c);
> + client->data.user.owner = get_pid(task_pid(current));
>
> /* make others aware this new client */
> snd_seq_system_client_ev_client_start(c);
> @@ -380,6 +381,7 @@ static int snd_seq_release(struct inode *inode, struct file *file)
> seq_free_client(client);
> if (client->data.user.fifo)
> snd_seq_fifo_delete(&client->data.user.fifo);
> + put_pid(client->data.user.owner);
> kfree(client);
> }
Shouldn't the counterpart (put_pid()) be called anywhere else?
thanks,
Takashi
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-15 10:30 ` Takashi Iwai
@ 2016-02-15 10:37 ` Clemens Ladisch
2016-02-15 18:32 ` Martin Koegler
1 sibling, 0 replies; 21+ messages in thread
From: Clemens Ladisch @ 2016-02-15 10:37 UTC (permalink / raw)
To: Takashi Iwai, Martin Koegler; +Cc: alsa-devel
Takashi Iwai wrote:
> Martin Koegler wrote:
>> rawmidi devices expose the card number via IOCTLs, which allows to
>> find the corresponding device in sysfs.
>>
>> The sequencer provides no identifing data. Chromium works around this
>> issue by scanning rawmidi as well as sequencer devices and matching
>> them by using assumtions, how the kernel register sequencer devices.
>>
>> This changes adds support for exposing the card number for kernel clients
>> as well as the PID for user client.
>>
>> The minor of the API version is changed to distinguish between the zero
>> initialised reserved field and card number 0.
>>
>> Signed-off-by: Martin Koegler <martin.koegler@chello.at>
>
>> +++ b/include/uapi/sound/asequencer.h
>> @@ -357,7 +357,8 @@ struct snd_seq_client_info {
>> - char reserved[64]; /* for future use */
>> + int owner; /* RO: card number[kernel] / PID[user] */
>> + char reserved[64 - sizeof(int)]; /* for future use */
>
> The sizeof(int) is always 4. So let's make it explicit.
>
> But, please make sure that this change won't lead to any
> incompatibility. Some architectures might align with 64bit long,
> although the 32bit int and the rest char[] should be fine on all known
> architectures, AFAIK.
Or just make it two fields, card and pid. The two values are currently
exclusive, but there is no technical reason for this.
Regards,
Clemens
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide sequencer sound card number / PID via alsa-lib
2016-02-13 13:42 [PATCH] Provide sequencer sound card number / PID via alsa-lib Martin Koegler
2016-02-13 13:42 ` [PATCH] Show sequencer sound card numer/PID via aconnect Martin Koegler
2016-02-13 13:42 ` [PATCH] Provide card number / PID via sequencer client info Martin Koegler
@ 2016-02-15 10:39 ` Clemens Ladisch
2 siblings, 0 replies; 21+ messages in thread
From: Clemens Ladisch @ 2016-02-15 10:39 UTC (permalink / raw)
To: Martin Koegler, alsa-devel
Martin Koegler wrote:
> +++ b/src/seq/seq.c
> /**
> + * \brief Get the sound card number (kernel) or owning PID
> + * \param info client_info container
> + * \return card number/PID/-1 if value is not available.
> + */
Please document that card/pid are valid only for clients of type
SND_SEQ_KERNEL/USER_CLIENT.
And I think two functions for card and pid are more appropriate.
Regards,
Clemens
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-15 10:30 ` Takashi Iwai
2016-02-15 10:37 ` Clemens Ladisch
@ 2016-02-15 18:32 ` Martin Koegler
2016-02-15 19:08 ` Takashi Iwai
1 sibling, 1 reply; 21+ messages in thread
From: Martin Koegler @ 2016-02-15 18:32 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Martin Koegler
On Mon, Feb 15, 2016 at 11:30:15AM +0100, Takashi Iwai wrote:
> The idea looks good. One remaining question is whether only providing
> the card number or pid is sufficient for all cases.
I only care about the kernel client.
> > @@ -357,7 +357,8 @@ struct snd_seq_client_info {
> > unsigned char event_filter[32]; /* event filter bitmap */
> > int num_ports; /* RO: number of ports */
> > int event_lost; /* number of lost events */
> > - char reserved[64]; /* for future use */
> > + int owner; /* RO: card number[kernel] / PID[user] */
> > + char reserved[64 - sizeof(int)]; /* for future use */
>
> The sizeof(int) is always 4. So let's make it explicit.
>
> But, please make sure that this change won't lead to any
> incompatibility. Some architectures might align with 64bit long,
> although the 32bit int and the rest char[] should be fine on all known
> architectures, AFAIK.
Sorry, I don't have access to the various non x86-architectures, so I can't test.
I will change to
int card;
int pid;
char reserve[56];
More safety would just provide a much more complex (ugly?) structure:
struct _int_snd_seq_client_info_old {
int client; /* client number to inquire */
snd_seq_client_type_t type; /* client type */
char name[64]; /* client name */
unsigned int filter; /* filter flags */
unsigned char multicast_filter[8]; /* multicast filter bitmap */
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
char reserved[64]; /* for future use */
};
struct _int_snd_seq_client_info_new {
int client; /* client number to inquire */
snd_seq_client_type_t type; /* client type */
char name[64]; /* client name */
unsigned int filter; /* filter flags */
unsigned char multicast_filter[8]; /* multicast filter bitmap */
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
int card;
int pid;
char reserved[64]; /* for future use */
};
struct snd_seq_client_info {
int client; /* client number to inquire */
snd_seq_client_type_t type; /* client type */
char name[64]; /* client name */
unsigned int filter; /* filter flags */
unsigned char multicast_filter[8]; /* multicast filter bitmap */
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
int card;
int pid;
char reserved[64 - sizeof(struct _int_snd_seq_client_info_new) + sizeof(_int_snd_seq_client_info_old)]; /* for future use */
};
This should handle all alignment and type size issues automatically.
If you really want this, I can provide the apropriate patches.
> >
> > diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
> > index 58e79e0..ac07ab7 100644
> > --- a/sound/core/seq/seq_clientmgr.c
> > +++ b/sound/core/seq/seq_clientmgr.c
> > @@ -364,6 +364,7 @@ static int snd_seq_open(struct inode *inode, struct file *file)
> > /* fill client data */
> > user->file = file;
> > sprintf(client->name, "Client-%d", c);
> > + client->data.user.owner = get_pid(task_pid(current));
> >
> > /* make others aware this new client */
> > snd_seq_system_client_ev_client_start(c);
> > @@ -380,6 +381,7 @@ static int snd_seq_release(struct inode *inode, struct file *file)
> > seq_free_client(client);
> > if (client->data.user.fifo)
> > snd_seq_fifo_delete(&client->data.user.fifo);
> > + put_pid(client->data.user.owner);
> > kfree(client);
> > }
>
> Shouldn't the counterpart (put_pid()) be called anywhere else?
The only way to free a client structure is seq_free_client1 (static).
This is called by snd_seq_open before get_pid [=> irelevant] and
seq_free_client (static).
seq_free_client is called by snd_seq_release, which calls put_pid and
snd_seq_delete_kernel_client, which destroys a kernel client.
Are I'm missing a code path?
Regards,
Martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-15 18:32 ` Martin Koegler
@ 2016-02-15 19:08 ` Takashi Iwai
2016-02-15 21:44 ` Martin Koegler
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2016-02-15 19:08 UTC (permalink / raw)
To: Martin Koegler; +Cc: alsa-devel
On Mon, 15 Feb 2016 19:32:43 +0100,
Martin Koegler wrote:
>
> On Mon, Feb 15, 2016 at 11:30:15AM +0100, Takashi Iwai wrote:
> > The idea looks good. One remaining question is whether only providing
> > the card number or pid is sufficient for all cases.
>
> I only care about the kernel client.
Well, the question is whether only card number is enough. What if
cards provide multiple rawmidi devices?
> > > @@ -357,7 +357,8 @@ struct snd_seq_client_info {
> > > unsigned char event_filter[32]; /* event filter bitmap */
> > > int num_ports; /* RO: number of ports */
> > > int event_lost; /* number of lost events */
> > > - char reserved[64]; /* for future use */
> > > + int owner; /* RO: card number[kernel] / PID[user] */
> > > + char reserved[64 - sizeof(int)]; /* for future use */
> >
> > The sizeof(int) is always 4. So let's make it explicit.
> >
> > But, please make sure that this change won't lead to any
> > incompatibility. Some architectures might align with 64bit long,
> > although the 32bit int and the rest char[] should be fine on all known
> > architectures, AFAIK.
>
> Sorry, I don't have access to the various non x86-architectures, so I can't test.
Usually it's tested by cross-compiling, so everyone can do it.
>
> I will change to
> int card;
> int pid;
> char reserve[56];
Yes, this would be better.
> More safety would just provide a much more complex (ugly?) structure:
>
> struct _int_snd_seq_client_info_old {
> int client; /* client number to inquire */
> snd_seq_client_type_t type; /* client type */
> char name[64]; /* client name */
> unsigned int filter; /* filter flags */
> unsigned char multicast_filter[8]; /* multicast filter bitmap */
> unsigned char event_filter[32]; /* event filter bitmap */
> int num_ports; /* RO: number of ports */
> int event_lost; /* number of lost events */
> char reserved[64]; /* for future use */
> };
>
> struct _int_snd_seq_client_info_new {
> int client; /* client number to inquire */
> snd_seq_client_type_t type; /* client type */
> char name[64]; /* client name */
> unsigned int filter; /* filter flags */
> unsigned char multicast_filter[8]; /* multicast filter bitmap */
> unsigned char event_filter[32]; /* event filter bitmap */
> int num_ports; /* RO: number of ports */
> int event_lost; /* number of lost events */
> int card;
> int pid;
> char reserved[64]; /* for future use */
> };
>
> struct snd_seq_client_info {
> int client; /* client number to inquire */
> snd_seq_client_type_t type; /* client type */
> char name[64]; /* client name */
> unsigned int filter; /* filter flags */
> unsigned char multicast_filter[8]; /* multicast filter bitmap */
> unsigned char event_filter[32]; /* event filter bitmap */
> int num_ports; /* RO: number of ports */
> int event_lost; /* number of lost events */
> int card;
> int pid;
> char reserved[64 - sizeof(struct _int_snd_seq_client_info_new) + sizeof(_int_snd_seq_client_info_old)]; /* for future use */
> };
>
> This should handle all alignment and type size issues automatically.
You'd need to define old and new structs without reserved field.
The calculation still works but it's bogus.
> If you really want this, I can provide the apropriate patches.
No, I never want such a thing :)
> > >
> > > diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
> > > index 58e79e0..ac07ab7 100644
> > > --- a/sound/core/seq/seq_clientmgr.c
> > > +++ b/sound/core/seq/seq_clientmgr.c
> > > @@ -364,6 +364,7 @@ static int snd_seq_open(struct inode *inode, struct file *file)
> > > /* fill client data */
> > > user->file = file;
> > > sprintf(client->name, "Client-%d", c);
> > > + client->data.user.owner = get_pid(task_pid(current));
> > >
> > > /* make others aware this new client */
> > > snd_seq_system_client_ev_client_start(c);
> > > @@ -380,6 +381,7 @@ static int snd_seq_release(struct inode *inode, struct file *file)
> > > seq_free_client(client);
> > > if (client->data.user.fifo)
> > > snd_seq_fifo_delete(&client->data.user.fifo);
> > > + put_pid(client->data.user.owner);
> > > kfree(client);
> > > }
> >
> > Shouldn't the counterpart (put_pid()) be called anywhere else?
>
> The only way to free a client structure is seq_free_client1 (static).
> This is called by snd_seq_open before get_pid [=> irelevant] and
> seq_free_client (static).
> seq_free_client is called by snd_seq_release, which calls put_pid and
> snd_seq_delete_kernel_client, which destroys a kernel client.
OK, I misread the patch where to place the code. Then this should be
fine.
Takashi
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-15 19:08 ` Takashi Iwai
@ 2016-02-15 21:44 ` Martin Koegler
2016-02-15 22:34 ` Takashi Iwai
0 siblings, 1 reply; 21+ messages in thread
From: Martin Koegler @ 2016-02-15 21:44 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Martin Koegler
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
On Mon, Feb 15, 2016 at 08:08:12PM +0100, Takashi Iwai wrote:
> On Mon, 15 Feb 2016 19:32:43 +0100,
> Martin Koegler wrote:
> >
> > On Mon, Feb 15, 2016 at 11:30:15AM +0100, Takashi Iwai wrote:
> > > The idea looks good. One remaining question is whether only providing
> > > the card number or pid is sufficient for all cases.
> >
> > I only care about the kernel client.
>
> Well, the question is whether only card number is enough. What if
> cards provide multiple rawmidi devices?
Aren't they currently ports?
seq_midi.c creates just one sequencer device per card number.
Regards,
Martin
[-- Attachment #2: 0001-Show-sequencer-sound-card-numer-PID-via-aconnect.patch --]
[-- Type: text/x-diff, Size: 1688 bytes --]
>From 797b71aeb533d1111b8aada6b7e0ad8e2b133325 Mon Sep 17 00:00:00 2001
From: Martin Koegler <martin.koegler@chello.at>
Date: Fri, 12 Feb 2016 19:53:32 +0100
Subject: [PATCH] Show sequencer sound card numer/PID via aconnect
rawmidi devices expose the card number via IOCTLs, which allows to
find the corresponding device in sysfs.
The sequencer provides no identifing data. Chromium works around this
issue by scanning rawmidi as well as sequencer devices and matching
them by using assumtions, how the kernel register sequencer devices.
This patch adds support for displaying the sound card number/PID to
aconnect.
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
seq/aconnect/aconnect.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/seq/aconnect/aconnect.c b/seq/aconnect/aconnect.c
index 8d6cebb..d299f5c 100644
--- a/seq/aconnect/aconnect.c
+++ b/seq/aconnect/aconnect.c
@@ -166,11 +166,22 @@ static void print_port(snd_seq_t *seq, snd_seq_client_info_t *cinfo,
snd_seq_port_info_t *pinfo, int count)
{
if (! count) {
- printf(_("client %d: '%s' [type=%s]\n"),
+ int card, pid;
+
+ printf(_("client %d: '%s' [type=%s"),
snd_seq_client_info_get_client(cinfo),
snd_seq_client_info_get_name(cinfo),
(snd_seq_client_info_get_type(cinfo) == SND_SEQ_USER_CLIENT ?
_("user") : _("kernel")));
+
+ card = snd_seq_client_info_get_card(cinfo);
+ if (card != -1)
+ printf(",card=%d", card);
+
+ pid = snd_seq_client_info_get_pid(cinfo);
+ if (pid != -1)
+ printf(",pid=%d", pid);
+ printf("]\n");
}
printf(" %3d '%-16s'\n",
snd_seq_port_info_get_port(pinfo),
--
2.1.4
[-- Attachment #3: 0001-Provide-sequencer-sound-card-number-PID-via-alsa-lib.patch --]
[-- Type: text/x-diff, Size: 5120 bytes --]
>From aabf924538588a65cbbdb2d702712338279fd9c1 Mon Sep 17 00:00:00 2001
From: Martin Koegler <martin.koegler@chello.at>
Date: Fri, 12 Feb 2016 19:54:15 +0100
Subject: [PATCH] Provide sequencer sound card number / PID via alsa-lib
rawmidi devices expose the card number via IOCTLs, which allows to
find the corresponding device in sysfs.
The sequencer provides no identifing data. Chromium works around this
issue by scanning rawmidi as well as sequencer devices and matching
them by using assumtions, how the kernel register sequencer devices.
This changes adds support for exposing the card number for kernel clients
as well as the PID for user client.
It supports kernels with and without the required support.
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
include/seq.h | 2 ++
include/sound/asequencer.h | 6 ++++--
src/seq/seq.c | 26 ++++++++++++++++++++++++++
src/seq/seq_hw.c | 12 +++++++++++-
4 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/include/seq.h b/include/seq.h
index 9576822..d05940e 100644
--- a/include/seq.h
+++ b/include/seq.h
@@ -143,6 +143,8 @@ snd_seq_client_type_t snd_seq_client_info_get_type(const snd_seq_client_info_t *
const char *snd_seq_client_info_get_name(snd_seq_client_info_t *info);
int snd_seq_client_info_get_broadcast_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info);
+int snd_seq_client_info_get_card(const snd_seq_client_info_t *info);
+int snd_seq_client_info_get_pid(const snd_seq_client_info_t *info);
const unsigned char *snd_seq_client_info_get_event_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_num_ports(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_event_lost(const snd_seq_client_info_t *info);
diff --git a/include/sound/asequencer.h b/include/sound/asequencer.h
index 09c8a00..3ac70fd 100644
--- a/include/sound/asequencer.h
+++ b/include/sound/asequencer.h
@@ -24,7 +24,7 @@
/** version of the sequencer */
-#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
+#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
/**
* definition of sequencer event types
@@ -356,7 +356,9 @@ struct snd_seq_client_info {
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
- char reserved[64]; /* for future use */
+ int card; /* RO: card number[kernel] */
+ int pid; /* RO: pid[user] */
+ char reserved[56]; /* for future use */
};
diff --git a/src/seq/seq.c b/src/seq/seq.c
index 620ca3f..4405e68 100644
--- a/src/seq/seq.c
+++ b/src/seq/seq.c
@@ -1522,6 +1522,32 @@ int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info)
}
/**
+ * \brief Get the sound card number.
+ * \param info client_info container
+ * \return card number or -1 if value is not available.
+ *
+ * Only available for SND_SEQ_KERNEL_CLIENT clients.
+ */
+int snd_seq_client_info_get_card(const snd_seq_client_info_t *info)
+{
+ assert(info);
+ return info->card;
+}
+
+/**
+ * \brief Get the owning PID.
+ * \param info client_info container
+ * \return pid or -1 if value is not available.
+ *
+ * Only available for SND_SEQ_USER_CLIENT clients.
+ */
+int snd_seq_client_info_get_pid(const snd_seq_client_info_t *info)
+{
+ assert(info);
+ return info->pid;
+}
+
+/**
* \brief (DEPRECATED) Get the event filter bitmap of a client_info container
* \param info client_info container
* \return NULL if no event filter, or pointer to event filter bitmap
diff --git a/src/seq/seq_hw.c b/src/seq/seq_hw.c
index d033367..24350b6 100644
--- a/src/seq/seq_hw.c
+++ b/src/seq/seq_hw.c
@@ -32,10 +32,11 @@ const char *_snd_module_seq_hw = "";
#ifndef DOC_HIDDEN
#define SNDRV_FILE_SEQ ALSA_DEVICE_DIRECTORY "seq"
#define SNDRV_FILE_ALOADSEQ ALOAD_DEVICE_DIRECTORY "aloadSEQ"
-#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 1)
+#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 2)
typedef struct {
int fd;
+ int micro_version;
} snd_seq_hw_t;
#endif /* DOC_HIDDEN */
@@ -100,6 +101,10 @@ static int snd_seq_hw_get_client_info(snd_seq_t *seq, snd_seq_client_info_t * in
/*SYSERR("SNDRV_SEQ_IOCTL_GET_CLIENT_INFO failed");*/
return -errno;
}
+ if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX)) {
+ info->card = -1;
+ info->pid = -1;
+ }
return 0;
}
@@ -368,6 +373,10 @@ static int snd_seq_hw_query_next_client(snd_seq_t *seq, snd_seq_client_info_t *i
/*SYSERR("SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT failed");*/
return -errno;
}
+ if (hw->micro_version < SNDRV_PROTOCOL_MICRO(SNDRV_SEQ_VERSION_MAX)) {
+ info->card = -1;
+ info->pid = -1;
+ }
return 0;
}
@@ -480,6 +489,7 @@ int snd_seq_hw_open(snd_seq_t **handle, const char *name, int streams, int mode)
return -ENOMEM;
}
hw->fd = fd;
+ hw->micro_version = SNDRV_PROTOCOL_MICRO(ver);
if (streams & SND_SEQ_OPEN_OUTPUT) {
seq->obuf = (char *) malloc(seq->obufsize = SND_SEQ_OBUF_SIZE);
if (!seq->obuf) {
--
2.1.4
[-- Attachment #4: 0001-Provide-card-number-PID-via-sequencer-client-info.patch --]
[-- Type: text/x-diff, Size: 3916 bytes --]
>From 133a8b3e059a09bf50ce62ae9960472dc09e71d2 Mon Sep 17 00:00:00 2001
From: Martin Koegler <martin.koegler@chello.at>
Date: Thu, 11 Feb 2016 20:07:20 +0100
Subject: [PATCH] Provide card number / PID via sequencer client info
rawmidi devices expose the card number via IOCTLs, which allows to
find the corresponding device in sysfs.
The sequencer provides no identifing data. Chromium works around this
issue by scanning rawmidi as well as sequencer devices and matching
them by using assumtions, how the kernel register sequencer devices.
This changes adds support for exposing the card number for kernel clients
as well as the PID for user client.
The minor of the API version is changed to distinguish between the zero
initialised reserved field and card number 0.
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
include/uapi/sound/asequencer.h | 6 ++++--
sound/core/seq/seq_clientmgr.c | 14 ++++++++++++++
sound/core/seq/seq_clientmgr.h | 2 ++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/uapi/sound/asequencer.h b/include/uapi/sound/asequencer.h
index 5a5fa49..8c7da5a 100644
--- a/include/uapi/sound/asequencer.h
+++ b/include/uapi/sound/asequencer.h
@@ -25,7 +25,7 @@
#include <sound/asound.h>
/** version of the sequencer */
-#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
+#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
/**
* definition of sequencer event types
@@ -357,7 +357,9 @@ struct snd_seq_client_info {
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
- char reserved[64]; /* for future use */
+ int card; /* RO: card number[kernel] */
+ int pid; /* RO: pid[user] */
+ char reserved[56]; /* for future use */
};
diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index 58e79e0..d6d9419 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -364,6 +364,7 @@ static int snd_seq_open(struct inode *inode, struct file *file)
/* fill client data */
user->file = file;
sprintf(client->name, "Client-%d", c);
+ client->data.user.owner = get_pid(task_pid(current));
/* make others aware this new client */
snd_seq_system_client_ev_client_start(c);
@@ -380,6 +381,7 @@ static int snd_seq_release(struct inode *inode, struct file *file)
seq_free_client(client);
if (client->data.user.fifo)
snd_seq_fifo_delete(&client->data.user.fifo);
+ put_pid(client->data.user.owner);
kfree(client);
}
@@ -1197,6 +1199,17 @@ static void get_client_info(struct snd_seq_client *cptr,
info->event_lost = cptr->event_lost;
memcpy(info->event_filter, cptr->event_filter, 32);
info->num_ports = cptr->num_ports;
+
+ if (cptr->type == USER_CLIENT)
+ info->pid = pid_vnr(cptr->data.user.owner);
+ else
+ info->pid = -1;
+
+ if (cptr->type == KERNEL_CLIENT)
+ info->card = cptr->data.kernel.card ? cptr->data.kernel.card->number : -1;
+ else
+ info->card = -1;
+
memset(info->reserved, 0, sizeof(info->reserved));
}
@@ -2271,6 +2284,7 @@ int snd_seq_create_kernel_client(struct snd_card *card, int client_index,
client->accept_input = 1;
client->accept_output = 1;
+ client->data.kernel.card = card;
va_start(args, name_fmt);
vsnprintf(client->name, sizeof(client->name), name_fmt, args);
diff --git a/sound/core/seq/seq_clientmgr.h b/sound/core/seq/seq_clientmgr.h
index 20f0a72..031462e 100644
--- a/sound/core/seq/seq_clientmgr.h
+++ b/sound/core/seq/seq_clientmgr.h
@@ -33,6 +33,7 @@
struct snd_seq_user_client {
struct file *file; /* file struct of client */
/* ... */
+ struct pid* owner;
/* fifo */
struct snd_seq_fifo *fifo; /* queue for incoming events */
@@ -41,6 +42,7 @@ struct snd_seq_user_client {
struct snd_seq_kernel_client {
/* ... */
+ struct snd_card* card;
};
--
2.1.4
[-- Attachment #5: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-15 21:44 ` Martin Koegler
@ 2016-02-15 22:34 ` Takashi Iwai
2016-02-16 8:03 ` Martin Koegler
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2016-02-15 22:34 UTC (permalink / raw)
To: Martin Koegler; +Cc: alsa-devel
On Mon, 15 Feb 2016 22:44:54 +0100,
Martin Koegler wrote:
>
> On Mon, Feb 15, 2016 at 08:08:12PM +0100, Takashi Iwai wrote:
> > On Mon, 15 Feb 2016 19:32:43 +0100,
> > Martin Koegler wrote:
> > >
> > > On Mon, Feb 15, 2016 at 11:30:15AM +0100, Takashi Iwai wrote:
> > > > The idea looks good. One remaining question is whether only providing
> > > > the card number or pid is sufficient for all cases.
> > >
> > > I only care about the kernel client.
> >
> > Well, the question is whether only card number is enough. What if
> > cards provide multiple rawmidi devices?
>
> Aren't they currently ports?
> seq_midi.c creates just one sequencer device per card number.
Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
Takashi
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-15 22:34 ` Takashi Iwai
@ 2016-02-16 8:03 ` Martin Koegler
2016-02-16 8:41 ` Takashi Iwai
0 siblings, 1 reply; 21+ messages in thread
From: Martin Koegler @ 2016-02-16 8:03 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Martin Koegler
On Mon, Feb 15, 2016 at 11:34:09PM +0100, Takashi Iwai wrote:
> > On Mon, Feb 15, 2016 at 08:08:12PM +0100, Takashi Iwai wrote:
> > > On Mon, 15 Feb 2016 19:32:43 +0100,
> > > Martin Koegler wrote:
> > > >
> > > > On Mon, Feb 15, 2016 at 11:30:15AM +0100, Takashi Iwai wrote:
> > > > > The idea looks good. One remaining question is whether only providing
> > > > > the card number or pid is sufficient for all cases.
> > > >
> > > > I only care about the kernel client.
> > >
> > > Well, the question is whether only card number is enough. What if
> > > cards provide multiple rawmidi devices?
> >
> > Aren't they currently ports?
> > seq_midi.c creates just one sequencer device per card number.
>
> Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
Should I export the client_index parameter of snd_seq_create_kernel_client too?
Regards,
Martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-16 8:03 ` Martin Koegler
@ 2016-02-16 8:41 ` Takashi Iwai
2016-02-16 8:59 ` Clemens Ladisch
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2016-02-16 8:41 UTC (permalink / raw)
To: Martin Koegler; +Cc: alsa-devel
On Tue, 16 Feb 2016 09:03:34 +0100,
Martin Koegler wrote:
>
> On Mon, Feb 15, 2016 at 11:34:09PM +0100, Takashi Iwai wrote:
> > > On Mon, Feb 15, 2016 at 08:08:12PM +0100, Takashi Iwai wrote:
> > > > On Mon, 15 Feb 2016 19:32:43 +0100,
> > > > Martin Koegler wrote:
> > > > >
> > > > > On Mon, Feb 15, 2016 at 11:30:15AM +0100, Takashi Iwai wrote:
> > > > > > The idea looks good. One remaining question is whether only providing
> > > > > > the card number or pid is sufficient for all cases.
> > > > >
> > > > > I only care about the kernel client.
> > > >
> > > > Well, the question is whether only card number is enough. What if
> > > > cards provide multiple rawmidi devices?
> > >
> > > Aren't they currently ports?
> > > seq_midi.c creates just one sequencer device per card number.
> >
> > Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
>
> Should I export the client_index parameter of snd_seq_create_kernel_client too?
Well, I'd rather ask what are the requirements -- in wide ranges.
As you already noticed, multiple rawmidi devices and rawmidi
subdevices are mapped into a single client with various ports. But we
have no exact mapping information there, too. So, if you want to have
an exact mapping between sequencer and rawmidi, wouldn't you need the
similar information in snd_seq_port_info, too?
And, as mentioned, some cards provide indeed multiple clients. How do
you identify which client is for what? So far, it's identified only
from the name string and the type bits of each port. Isn't it enough?
If not, what have to be provided?
Takashi
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-16 8:41 ` Takashi Iwai
@ 2016-02-16 8:59 ` Clemens Ladisch
2016-02-16 9:27 ` Takashi Iwai
0 siblings, 1 reply; 21+ messages in thread
From: Clemens Ladisch @ 2016-02-16 8:59 UTC (permalink / raw)
To: Takashi Iwai, Martin Koegler; +Cc: alsa-devel
Takashi Iwai wrote:
> Martin Koegler wrote:
>> On Mon, Feb 15, 2016 at 11:34:09PM +0100, Takashi Iwai wrote:
>>>> On Mon, Feb 15, 2016 at 08:08:12PM +0100, Takashi Iwai wrote:
>>>>> Well, the question is whether only card number is enough. What if
>>>>> cards provide multiple rawmidi devices?
>>>>
>>>> Aren't they currently ports?
>>>> seq_midi.c creates just one sequencer device per card number.
>>>
>>> Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
Or snd-virmidi.
>> Should I export the client_index parameter of snd_seq_create_kernel_client too?
>
> Well, I'd rather ask what are the requirements -- in wide ranges.
The original requirement was just the ability to get the card name.
> As you already noticed, multiple rawmidi devices and rawmidi
> subdevices are mapped into a single client with various ports.
Actually, multiple devices get multiple clients.
> And, as mentioned, some cards provide indeed multiple clients. How do
> you identify which client is for what? So far, it's identified only
> from the name string and the type bits of each port. Isn't it enough?
> If not, what have to be provided?
This patch is about the card. If we really need a method to identify
the device, we can still add it later -- this patch does not obstruct
such an extension.
Regards,
Clemens
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-16 8:59 ` Clemens Ladisch
@ 2016-02-16 9:27 ` Takashi Iwai
2016-02-16 18:21 ` Martin Koegler
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2016-02-16 9:27 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel, Martin Koegler
On Tue, 16 Feb 2016 09:59:37 +0100,
Clemens Ladisch wrote:
>
> Takashi Iwai wrote:
> > Martin Koegler wrote:
> >> On Mon, Feb 15, 2016 at 11:34:09PM +0100, Takashi Iwai wrote:
> >>>> On Mon, Feb 15, 2016 at 08:08:12PM +0100, Takashi Iwai wrote:
> >>>>> Well, the question is whether only card number is enough. What if
> >>>>> cards provide multiple rawmidi devices?
> >>>>
> >>>> Aren't they currently ports?
> >>>> seq_midi.c creates just one sequencer device per card number.
> >>>
> >>> Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
>
> Or snd-virmidi.
>
> >> Should I export the client_index parameter of snd_seq_create_kernel_client too?
> >
> > Well, I'd rather ask what are the requirements -- in wide ranges.
>
> The original requirement was just the ability to get the card name.
Yep. And it's the assumption of only rawmidi, I suppose. How would
it differentiate from synth?
> > As you already noticed, multiple rawmidi devices and rawmidi
> > subdevices are mapped into a single client with various ports.
>
> Actually, multiple devices get multiple clients.
I thought of so, but reading back seq_midi.c, it looks different...
> > And, as mentioned, some cards provide indeed multiple clients. How do
> > you identify which client is for what? So far, it's identified only
> > from the name string and the type bits of each port. Isn't it enough?
> > If not, what have to be provided?
>
> This patch is about the card. If we really need a method to identify
> the device, we can still add it later -- this patch does not obstruct
> such an extension.
Sure, it won't conflict. But, the question is (back to square)
whether it's enough.
If we know that we shall change the API again, it's better to consider
the design well from the beginning. A short-living API version bump
is the thing we should avoid as much as possible. It's nothing but a
needless stress for maintainers :)
That said, I'm not particularly against the currently proposed change.
My only concern is whether we need any further change in (near)
future.
Takashi
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-16 9:27 ` Takashi Iwai
@ 2016-02-16 18:21 ` Martin Koegler
2016-02-17 14:07 ` Takashi Iwai
0 siblings, 1 reply; 21+ messages in thread
From: Martin Koegler @ 2016-02-16 18:21 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Clemens Ladisch, Martin Koegler
On Tue, Feb 16, 2016 at 10:27:20AM +0100, Takashi Iwai wrote:
> On Tue, 16 Feb 2016 09:59:37 +0100,
> > >>>> Aren't they currently ports?
> > >>>> seq_midi.c creates just one sequencer device per card number.
> > >>>
> > >>> Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
> >
> > Or snd-virmidi.
> >
> > >> Should I export the client_index parameter of snd_seq_create_kernel_client too?
> > >
> > > Well, I'd rather ask what are the requirements -- in wide ranges.
> >
> > The original requirement was just the ability to get the card name.
>
> Yep. And it's the assumption of only rawmidi, I suppose. How would
> it differentiate from synth?
My users are using a few identical USB MIDI keyboards [or USB MIDI interfaces] and
I need to recognize the devices even after reboot.
=> I want a stable, unique (composite) device ID for kernel sequencer clients+ports.
My current ID is: client name, sysfs-path and port number.
The sound card number allows to find the device in sysfs and determine the used USB port as stable identifier.
I hope, that the registration order for the ports of one USB MIDI device [or sound card] will always be the same.
see my prototype: https://build.opensuse.org/package/view_file/home:e9925248:branches:openSUSE:Leap:42.1:Update/grandorgue/0001-Add-support-for-unique-device-IDs.patch?expand=1
OPL3/4 + emuXXX synth register with a different name, so they should be distinct.
> > > And, as mentioned, some cards provide indeed multiple clients. How do
> > > you identify which client is for what? So far, it's identified only
> > > from the name string and the type bits of each port. Isn't it enough?
> > > If not, what have to be provided?
> >
> > This patch is about the card. If we really need a method to identify
> > the device, we can still add it later -- this patch does not obstruct
> > such an extension.
>
> Sure, it won't conflict. But, the question is (back to square)
> whether it's enough.
>
> If we know that we shall change the API again, it's better to consider
> the design well from the beginning. A short-living API version bump
> is the thing we should avoid as much as possible. It's nothing but a
> needless stress for maintainers :)
>
> That said, I'm not particularly against the currently proposed change.
> My only concern is whether we need any further change in (near)
> future.
+1
I just ask myself, if the device index would provide any useful information.
I don't know, how to map it to a anything below the soundcard in sysfs.
Is the device ID dymanic? [= Are they depending, if I first load the rawmidi module and then the synth module or the other way around].
Regards,
Martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-16 18:21 ` Martin Koegler
@ 2016-02-17 14:07 ` Takashi Iwai
2016-02-17 21:30 ` Martin Koegler
0 siblings, 1 reply; 21+ messages in thread
From: Takashi Iwai @ 2016-02-17 14:07 UTC (permalink / raw)
To: Martin Koegler; +Cc: alsa-devel, Clemens Ladisch
On Tue, 16 Feb 2016 19:21:37 +0100,
Martin Koegler wrote:
>
> On Tue, Feb 16, 2016 at 10:27:20AM +0100, Takashi Iwai wrote:
> > On Tue, 16 Feb 2016 09:59:37 +0100,
> > > >>>> Aren't they currently ports?
> > > >>>> seq_midi.c creates just one sequencer device per card number.
> > > >>>
> > > >>> Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4.
> > >
> > > Or snd-virmidi.
> > >
> > > >> Should I export the client_index parameter of snd_seq_create_kernel_client too?
> > > >
> > > > Well, I'd rather ask what are the requirements -- in wide ranges.
> > >
> > > The original requirement was just the ability to get the card name.
> >
> > Yep. And it's the assumption of only rawmidi, I suppose. How would
> > it differentiate from synth?
>
> My users are using a few identical USB MIDI keyboards [or USB MIDI interfaces] and
> I need to recognize the devices even after reboot.
>
> => I want a stable, unique (composite) device ID for kernel sequencer clients+ports.
>
> My current ID is: client name, sysfs-path and port number.
>
> The sound card number allows to find the device in sysfs and determine the used USB port as stable identifier.
> I hope, that the registration order for the ports of one USB MIDI device [or sound card] will always be the same.
>
> see my prototype: https://build.opensuse.org/package/view_file/home:e9925248:branches:openSUSE:Leap:42.1:Update/grandorgue/0001-Add-support-for-unique-device-IDs.patch?expand=1
>
> OPL3/4 + emuXXX synth register with a different name, so they should be distinct.
Yeah, there is a difference, of course. But the identifying by the
name string suffices? In other words, how would user-space identify
the client at best? Passing another attribute to client_info like
port type?
> > > > And, as mentioned, some cards provide indeed multiple clients. How do
> > > > you identify which client is for what? So far, it's identified only
> > > > from the name string and the type bits of each port. Isn't it enough?
> > > > If not, what have to be provided?
> > >
> > > This patch is about the card. If we really need a method to identify
> > > the device, we can still add it later -- this patch does not obstruct
> > > such an extension.
> >
> > Sure, it won't conflict. But, the question is (back to square)
> > whether it's enough.
> >
> > If we know that we shall change the API again, it's better to consider
> > the design well from the beginning. A short-living API version bump
> > is the thing we should avoid as much as possible. It's nothing but a
> > needless stress for maintainers :)
> >
> > That said, I'm not particularly against the currently proposed change.
> > My only concern is whether we need any further change in (near)
> > future.
>
> +1
>
> I just ask myself, if the device index would provide any useful information.
Which "device index" do you mean? The index passed at created
snd_seq_create_kerne_client()?
> I don't know, how to map it to a anything below the soundcard in sysfs.
> Is the device ID dymanic? [= Are they depending, if I first load the rawmidi module and then the synth module or the other way around].
If you mean about the client index offset, then usually they are fixed
by each driver. And even the client id number is fixed (up to 4
clients per card):
client = 16 + card * 4 + index.
So, in most case, the card number can be calculated even without the
new information. But, this is rather heuristic, and a clear mapping
would be better, of course.
Takashi
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] Provide card number / PID via sequencer client info
2016-02-17 14:07 ` Takashi Iwai
@ 2016-02-17 21:30 ` Martin Koegler
0 siblings, 0 replies; 21+ messages in thread
From: Martin Koegler @ 2016-02-17 21:30 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Clemens Ladisch, Martin Koegler
On Wed, Feb 17, 2016 at 03:07:25PM +0100, Takashi Iwai wrote:
> > My users are using a few identical USB MIDI keyboards [or USB MIDI interfaces] and
> > I need to recognize the devices even after reboot.
> >
> > => I want a stable, unique (composite) device ID for kernel sequencer clients+ports.
> >
> > My current ID is: client name, sysfs-path and port number.
> >
> > The sound card number allows to find the device in sysfs and determine the used USB port as stable identifier.
> > I hope, that the registration order for the ports of one USB MIDI device [or sound card] will always be the same.
> >
> > see my prototype: https://build.opensuse.org/package/view_file/home:e9925248:branches:openSUSE:Leap:42.1:Update/grandorgue/0001-Add-support-for-unique-device-IDs.patch?expand=1
> >
> > OPL3/4 + emuXXX synth register with a different name, so they should be distinct.
>
> Yeah, there is a difference, of course. But the identifying by the
> name string suffices? In other words, how would user-space identify
> the client at best? Passing another attribute to client_info like
> port type?
port type is not property of struct snd_seq_client - so it is better reported via port info.
It already has SND_SEQ_PORT_TYPE_SYNTHESIZER and SND_SEQ_PORT_TYPE_PORT.
For my usecase, I don't care about the type.
Either the user select it from a drop-down or uses auto-detection: He triggers at request
a MIDI event and the port with activity is selected - If you want to see it in action: https://www.youtube.com/watch?v=3g7H1W4x2cg [at 1:20]
> > I just ask myself, if the device index would provide any useful information.
>
> Which "device index" do you mean? The index passed at created
> snd_seq_create_kerne_client()?
Yes.
> > I don't know, how to map it to a anything below the soundcard in sysfs.
> > Is the device ID dymanic? [= Are they depending, if I first load the rawmidi module and then the synth module or the other way around].
>
> If you mean about the client index offset, then usually they are fixed
> by each driver. And even the client id number is fixed (up to 4
> clients per card):
> client = 16 + card * 4 + index.
>
> So, in most case, the card number can be calculated even without the
> new information. But, this is rather heuristic, and a clear mapping
> would be better, of course.
The key word is "usually". Its only suitable for an interface, if it is "always" fixed or can be used as an pointer on sysfs.
Regards,
Martin
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] Provide sequencer sound card number / PID via alsa-lib
@ 2016-03-03 21:39 Martin Koegler
0 siblings, 0 replies; 21+ messages in thread
From: Martin Koegler @ 2016-03-03 21:39 UTC (permalink / raw)
To: alsa-devel; +Cc: Martin Koegler
From: Martin Koegler <martin.koegler@chello.at>
rawmidi devices expose the card number via IOCTLs, which allows to
find the corresponding device in sysfs.
The sequencer provides no identifing data. Chromium works around this
issue by scanning rawmidi as well as sequencer devices and matching
them by using assumtions, how the kernel register sequencer devices.
This changes adds support for exposing the card number for kernel clients
as well as the PID for user client.
It supports kernels with and without the required support.
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
---
include/seq.h | 2 ++
include/sound/asequencer.h | 6 ++++--
src/seq/seq.c | 26 ++++++++++++++++++++++++++
src/seq/seq_hw.c | 12 +++++++++++-
4 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/include/seq.h b/include/seq.h
index 9576822..d05940e 100644
--- a/include/seq.h
+++ b/include/seq.h
@@ -143,6 +143,8 @@ snd_seq_client_type_t snd_seq_client_info_get_type(const snd_seq_client_info_t *
const char *snd_seq_client_info_get_name(snd_seq_client_info_t *info);
int snd_seq_client_info_get_broadcast_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info);
+int snd_seq_client_info_get_card(const snd_seq_client_info_t *info);
+int snd_seq_client_info_get_pid(const snd_seq_client_info_t *info);
const unsigned char *snd_seq_client_info_get_event_filter(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_num_ports(const snd_seq_client_info_t *info);
int snd_seq_client_info_get_event_lost(const snd_seq_client_info_t *info);
diff --git a/include/sound/asequencer.h b/include/sound/asequencer.h
index 09c8a00..3ac70fd 100644
--- a/include/sound/asequencer.h
+++ b/include/sound/asequencer.h
@@ -24,7 +24,7 @@
/** version of the sequencer */
-#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 1)
+#define SNDRV_SEQ_VERSION SNDRV_PROTOCOL_VERSION (1, 0, 2)
/**
* definition of sequencer event types
@@ -356,7 +356,9 @@ struct snd_seq_client_info {
unsigned char event_filter[32]; /* event filter bitmap */
int num_ports; /* RO: number of ports */
int event_lost; /* number of lost events */
- char reserved[64]; /* for future use */
+ int card; /* RO: card number[kernel] */
+ int pid; /* RO: pid[user] */
+ char reserved[56]; /* for future use */
};
diff --git a/src/seq/seq.c b/src/seq/seq.c
index 620ca3f..4405e68 100644
--- a/src/seq/seq.c
+++ b/src/seq/seq.c
@@ -1522,6 +1522,32 @@ int snd_seq_client_info_get_error_bounce(const snd_seq_client_info_t *info)
}
/**
+ * \brief Get the sound card number.
+ * \param info client_info container
+ * \return card number or -1 if value is not available.
+ *
+ * Only available for SND_SEQ_KERNEL_CLIENT clients.
+ */
+int snd_seq_client_info_get_card(const snd_seq_client_info_t *info)
+{
+ assert(info);
+ return info->card;
+}
+
+/**
+ * \brief Get the owning PID.
+ * \param info client_info container
+ * \return pid or -1 if value is not available.
+ *
+ * Only available for SND_SEQ_USER_CLIENT clients.
+ */
+int snd_seq_client_info_get_pid(const snd_seq_client_info_t *info)
+{
+ assert(info);
+ return info->pid;
+}
+
+/**
* \brief (DEPRECATED) Get the event filter bitmap of a client_info container
* \param info client_info container
* \return NULL if no event filter, or pointer to event filter bitmap
diff --git a/src/seq/seq_hw.c b/src/seq/seq_hw.c
index d033367..578ef12 100644
--- a/src/seq/seq_hw.c
+++ b/src/seq/seq_hw.c
@@ -32,10 +32,11 @@ const char *_snd_module_seq_hw = "";
#ifndef DOC_HIDDEN
#define SNDRV_FILE_SEQ ALSA_DEVICE_DIRECTORY "seq"
#define SNDRV_FILE_ALOADSEQ ALOAD_DEVICE_DIRECTORY "aloadSEQ"
-#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 1)
+#define SNDRV_SEQ_VERSION_MAX SNDRV_PROTOCOL_VERSION(1, 0, 2)
typedef struct {
int fd;
+ int version;
} snd_seq_hw_t;
#endif /* DOC_HIDDEN */
@@ -100,6 +101,10 @@ static int snd_seq_hw_get_client_info(snd_seq_t *seq, snd_seq_client_info_t * in
/*SYSERR("SNDRV_SEQ_IOCTL_GET_CLIENT_INFO failed");*/
return -errno;
}
+ if (hw->version < SNDRV_PROTOCOL_VERSION(1, 0, 2)) {
+ info->card = -1;
+ info->pid = -1;
+ }
return 0;
}
@@ -368,6 +373,10 @@ static int snd_seq_hw_query_next_client(snd_seq_t *seq, snd_seq_client_info_t *i
/*SYSERR("SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT failed");*/
return -errno;
}
+ if (hw->version < SNDRV_PROTOCOL_VERSION(1, 0, 2)) {
+ info->card = -1;
+ info->pid = -1;
+ }
return 0;
}
@@ -480,6 +489,7 @@ int snd_seq_hw_open(snd_seq_t **handle, const char *name, int streams, int mode)
return -ENOMEM;
}
hw->fd = fd;
+ hw->version = ver;
if (streams & SND_SEQ_OPEN_OUTPUT) {
seq->obuf = (char *) malloc(seq->obufsize = SND_SEQ_OBUF_SIZE);
if (!seq->obuf) {
--
2.1.4
^ permalink raw reply related [flat|nested] 21+ messages in thread
end of thread, other threads:[~2016-03-04 7:28 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-13 13:42 [PATCH] Provide sequencer sound card number / PID via alsa-lib Martin Koegler
2016-02-13 13:42 ` [PATCH] Show sequencer sound card numer/PID via aconnect Martin Koegler
2016-02-13 13:42 ` [PATCH] Provide card number / PID via sequencer client info Martin Koegler
2016-02-15 10:30 ` Takashi Iwai
2016-02-15 10:37 ` Clemens Ladisch
2016-02-15 18:32 ` Martin Koegler
2016-02-15 19:08 ` Takashi Iwai
2016-02-15 21:44 ` Martin Koegler
2016-02-15 22:34 ` Takashi Iwai
2016-02-16 8:03 ` Martin Koegler
2016-02-16 8:41 ` Takashi Iwai
2016-02-16 8:59 ` Clemens Ladisch
2016-02-16 9:27 ` Takashi Iwai
2016-02-16 18:21 ` Martin Koegler
2016-02-17 14:07 ` Takashi Iwai
2016-02-17 21:30 ` Martin Koegler
2016-02-15 10:39 ` [PATCH] Provide sequencer sound card number / PID via alsa-lib Clemens Ladisch
-- strict thread matches above, loose matches on Subject: below --
2016-03-03 21:39 Martin Koegler
2016-02-12 18:57 Martin Koegler
2016-02-13 12:36 ` Takashi Sakamoto
2016-02-13 12:45 ` Martin Koegler
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).