HAL, sound cards and laptops
david at fubar.dk
Mon Aug 7 09:01:36 PDT 2006
On Sun, 2006-08-06 at 23:53 +0200, Lennart Poettering wrote:
> We're currently working on adding HAL support to PulseAudio. While
> working on it I noticed a few things:
This sounds great!
> - My laptop has a softmodem which is available as ALSA device on
> Linux. Currently there is no way to tell the difference between a
> real sound card and such a modem in HAL. Therefore I would like to
> suggest adding a new property to HAL for alsa, perhaps called
> "alsa.class" or something which can take the value "modem" or
> "audio". Because the ALSA API doesn't offer a way to query if
> something is a modem or not this property should probably be set by
> an .fdi file. Because the PCI device class is "7" for a modem and
> "5" for a real sound card that .fdi file should be very easy to
> Would you accept such a patch?
Yup, this sounds like a nice thing!
> (The same issue appears with the OSS stuff, hence I'd like to see
> the same for "oss.class")
> I a not sure, however, if instead of adding new properties this
> could be folded into info.capabilities.
> - Currently all OSS devices appear twice in HAL. Once for /dev/audio
> and once for /dev/dsp. Apart from this property "oss.device_file"
> they both have all the same properties. AFAIK the two OSS device files are
> practically identical, except they have a different set of defaults. In
> PulseAudio we want only one of the two devices. Which one is not
> important for us. But we do not want them listed both. Right now we
> cannot tell them apart besides doing some awful
> strncmp(oss.device_file, "/dev/dsp", 8) == 0.
> Therefore I'd like to suggest removing the /dev/audio
> devices from HAL's device tree. Nobody uses them anyway and they are
> fully redundant. If there is a good reason to keep them, then I
> would at least suggest adding some kind of property to tell them
> apart cleanly.
I think we should just remove them, any idea of how to do this without
comparing on device file names? sysfs names?
> - My laptop has a sound card which does 5.1 audio. At least that's
> what ALSA says. In reality however, there are only stereo speakers
> in the machine and the only audio jack is stereo, too. I would like
> to see this information exposed in HAL. Something like
> "alsa.physical_audio_channels" which would be set according to some
> DMI data. I don't know HAL that well, but I am sure that this can be
> done in .fdi files.
Yea, that would make sense. We can't get to this from the hardware? I
wonder how e.g. Windows copes with that. IIRC there's always a sound
card and/or laptop vendor provided control program (that looks very
foreign on the OS), maybe they do something along the lines what you are
I guess keying of the DMI data (specifically smbios.system.product) is
fine, it's just a lot of work maintaining that list. Maybe it's
something to consider doing in the kernel drivers too?
> Something unrelated to sound:
> - Has anybody been looking into exposing information about those "RF
> Kill" buttons in HAL? The HAL spec has a namespace "button" and
> currently defines only "lid", "power" and "sleep" as possible
> types. Maybe it would make sense to add "bluetooth-kill" and
> "wlan-kill" to this list?
I think this may make sense. I remember talking to dcbw (NetworkManager
maintainer) about it but I'm not sure what the conclusion was so I'm
Cc'ing dcbw on this mail. I *think* what the netdev developers wanted
was a way to make the driver catch this in the kernel too.
> - My laptop generates fake keyboard events when the screen brightness
> is changed. These keyboard events can easily be trapped using
> /dev/input/event. Right now the HAL spec doesn't define a DBUS
> signal that is emitted when the brightness is changed. Would you
> accept a patch for adding one for this?
I think we actually do emit ButtonPressed via the addon-keyboard
and I think g-p-m does the right thing here. I think Richard Hughes
knows more; what laptop is it?
More information about the hal