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