Daniel Mack wrote: > On Nov 12, 2007, at 6:26 PM, Clemens Ladisch wrote: > What I would like to achieve is a conventient way of accessing them, > probably from the command line via some procfs or sysfs manner so > users can even use scripts to switch them on and off if they like. The amixer tool can access any control. > > I think the displays could by controlled by mixer controls of type > > "bytes". Usual mixer applications can't handle those, but this is > > quite hardware dependent anway ... > > But is that really where it belongs to? I would think that LEDs and > input functions are not related to audio and thus should be handled > by some other, more appropriate or maybe even proprietary subsystem. > > There are some features which have influcence on the audio > behaviour since they affect the way the signal is processed, but > LEDs are certainly not, are they? The LEDs are part of the device, so it makes sense to use them in some manner related to audio. > Is it ok to attach own, device-specific sysfs entries to device > folders created by ALSA? It's possible, but so far, it hasn't been necessary. > This way, we would have those features releated to the audio device > but wouldn't need to abuse the mixer API. It's actually called the "control API" because it can be used to provide controls of all kinds, not only related to mixing. I'd stronly recommend to use the control API. While it is possible to use sysfs for the same purpose, I don't see any advantage over the control API. Regards, Clemens _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
