HAL, sound cards and laptops
danny.kukawka at web.de
Tue Aug 8 05:04:32 PDT 2006
On Monday 07 August 2006 22:46, Lennart Poettering wrote:
> On Mon, 07.08.06 19:22, Danny Kukawka (danny.kukawka at web.de) wrote:
> > No, this could not work, because this is only correct for AC97 devices,
> > but e.g. not for HD-audio PCI device which provide modem and sound device
> > in the same pci device/chip. There is a way to detect if this is a modem
> > or a sound
> I am pretty sure that it is not difficult to write a FDI file to
> tell apart audio and modem for both AC97/MC97 and the HD-audio stuff.
No, IMO not. This is as I already wrote only possible for AC97 and not
HD-audio and other devices. And if this only work for AC97, this info is IMO
useless. But you can also check this in your code if you really need this
info. The only correct way is via ALSA.
> But: This would require opening the audio device just for querying
> this minor information. This is definitely a no-no in my eyes and
> makes it unusable for usage in PulseAudio.
But as I said: this would be the only correct way (or export this via kernel
to sysfs) to detect this. But if this is _really_ needed, we could think
about a extra prober for this.
> I read it like this: /dev/audio is a compatibility kludge for some
> legacy applications. And things like that should not show up in HAL,
> should they?
Why not? Only because this is a historical device? We use e.g. exactly this
device via HAL to set and guarantee the correct device permissions via resmgr
(hal-resmgr) for the user on SUSE. Because of this we need this device in
> What kind of filter would you suggest? If you read my original mail
> closely you'll see that besides doing some strncmp() on
> oss.device_file there is no way to tell these devices apart. And this
> is really ugly.
This is not really ugly. I don't see why a strncmp should be a problem. This
is what many other applications also do if they get a list of devices and
would only use some of them. If the strncmp() is the reason to remove the
device: what happen if the next come and don't want to
display /dev/dsp ? ... ;-)
> Legacy apps which want to use /dev/audio are welcome to do so even if
> that specific device doesn't show up in HAL.
What kind of argument is this?
More information about the hal