At Thu, 17 Jan 2008 09:11:00 -0800, Tobin Davis wrote: > > On Thu, 2008-01-17 at 17:58 +0100, Takashi Iwai wrote: > > At Thu, 17 Jan 2008 09:46:06 -0400, > Andrew Paprocki wrote: > > > > This adds additional pincaps which were not previously output. Also, Vref > > capabilities are output per-pin along with the current Vref pinctl setting > > if the NID supports Vref. Also added: processing widgets and proccaps, as > > well as processing coefficient and coefficient index from the Realtek Define > > Registers per the ALC883 datasheet. > > > > Signed-off-by: Andrew Paprocki <andrew@xxxxxxxxxxx> > > Did you check whether this doesn't break Claudio's codecgraph parser? > If it's OK, I'd like to apply it, of course... > > Takashi > > You're kidding, right? Adding more details about a codec is more useful at this > point than making sure a non-essential script (that can be easily modified) > isn't broken. Well, now we have some parser program, then it's the high time to think about the proc output consistent in a certain level. So far, it's just written to be readable for human being. But, now we'd need to make it also easily readable by dumb programs, too. > What I want to know is if we can add even more to /proc, like EAPD status (not > just capabilities), jack sense, etc. These are useful bits of information, not > only for driver development, but also could be useful for userspace tools that > can monitor these. Imagine having your system auto adjust from 5.1 surround > settings to optimal headphone settings (not just automute) when you plug in your > headphones. The jack-sense is a bit problem. I once had a laptop that causes codec errors when issuing a jack-sense command without unsolicited events. So, I'd say, let's be as conservative as possible for the proc. Moreover, we can read any commands via hwdep ioctl easily now... Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
