At Thu, 12 Nov 2009 11:39:12 +0100, I wrote: > > At Thu, 12 Nov 2009 10:54:02 +0100 (CET), > noreply-git@xxxxxxxxxxxxxxxx wrote: > > > > commit 6739046df36c7adf80c961bcba4870270e66dbf6 > > Author: Jaroslav Kysela <perex@xxxxxxxx> > > AuthorDate: Thu Nov 12 10:15:48 2009 +0100 > > Commit: Jaroslav Kysela <perex@xxxxxxxx> > > CommitDate: Thu Nov 12 10:51:48 2009 +0100 > > > > ALSA: hda - proc - add support for dynamic controls to mixer<->NID mapping > > > > This patch adds support for dynamically created controls to proc codec file > > (Control: lines). > > > > Signed-off-by: Jaroslav Kysela <perex@xxxxxxxx> > > > > commit c45b73bf328cd8ace53cf39994328cf9d6548c4f > > Author: Jaroslav Kysela <perex@xxxxxxxx> > > AuthorDate: Wed Nov 11 13:43:01 2009 +0100 > > Commit: Jaroslav Kysela <perex@xxxxxxxx> > > CommitDate: Thu Nov 12 10:51:16 2009 +0100 > > > > ALSA: hda - proc - introduce Control: lines to show mixer<->NID assignment > > > > This is an initial patch to show universal control<->NID assigment in > > proc codec file. The change helps to debug codec related problems. > > > > Signed-off-by: Jaroslav Kysela <perex@xxxxxxxx> > > I find the second one is the nice hack, but the first (newer) one > isn't good since it abuses the subdevice field of the ctl id. > It is a part of API/ABI, and if we do any changes the semantics, we > should define the changed behavior *beforehand* publicly. BTW, I don't mean that using subdevice is wrong. Instead: if we use it, let's define the proper definition first. For example, define (1 << 31) as the private (driver-specific) field bit in control.h. Actually, using the subdevice can make the change of snd_hda_add_ctl easier, too. Then you don't keep nid in another field but just use snd_kcontrol to retrieve the nid. Of course, we'd need to check the existing apps (at least our own) whether subdevice is really safe to change freely, though. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
