On Fri, Apr 8, 2016 at 9:10 AM, Takashi Iwai tiwai@suse.de wrote:
On Fri, 08 Apr 2016 14:56:28 +0200, Jaroslav Kysela wrote:
Dne 8.4.2016 v 12:24 Takashi Iwai napsal(a):
On Thu, 07 Apr 2016 22:10:41 +0200, Martin Koegler wrote:
On Thu, Apr 07, 2016 at 03:23:01PM -0400, Adam Goode wrote:
Have you heard any objections?
Also, would you plan to do a 1.1.2 release soon after accepting
this, to
get this functionality out quickly?
Distributions already start to pick 1.1.1 up: https://build.opensuse.org/request/show/382608 https://build.opensuse.org/request/show/382611
I would object merging that patch, if there is no immediate patched
1.1.2 release available,
as otherwise 1.1.1 with a different API will get used by the mass.
I have no strong opinion on this, so far. Either way (a quick 1.1.2 fix release, or introducing a new function in 1.1.2) isn't a big deal. Maybe the former is easier, but the latter is safer.
Jaroslav, what's your take? (And no, let's not use the versioned symbols again :)
What about 1.1.1.2 ?
Do you mean 1.1.1.1? It's already confusing, as you see :)
This + "pcm_plugin: fix appl pointer not correct when mmap_commit() return error" patch ?
If you don't mind a quick release, we may do it, yes, no matter which version number is.
But, meanwhile, I thought of the change again, and now wonder whether it's really right to return an error *and* -1. -1 conflicts with EPERM. And I thought there is no POSIX definition of error numbers, so in theory, -ENOSYS may be -1.
I agree now that -ENOSYS is probably wrong here. I think changing the function's behavior at this point is now too late.
So there are 2 alternatives I can think of:
option 1: introduce snd_seq_client_info_get_pid_2() and leave the existing function alone. This new function can return a new constant, SND_SEQ_CLIENT_INFO_PID_UNKNOWN for missing kernel support. Same for card. option 2: introduce snd_seq_client_info_pid_known() that returns a bool if there is kernel support. Same for card.
Thoughts? Alternatives?
Thanks,
Adam
thanks,
Takashi