HAL, sound cards and laptops

[Lennart Poettering]

On Mon, 07.08.06 12:01, David Zeuthen (david at fubar.dk) wrote:

> > We're currently working on adding HAL support to PulseAudio. While
> > working on it I noticed a few things:
> 
> This sounds great!

It literally does. ;-)

> > - 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
> >   write.
> > 
> >   Would you accept such a patch?
> 
> Yup, this sounds like a nice thing!

Do you prefer it as a new property or as capability?

I'd vote for a property "alsa.class".

> >   (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?

The current HAL OSS code uses strncmp() on the device name a lot. It's
trivial to modify the current code to ignore /dev/adsp entirely.

I wil cook up a patch.

> > - 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
> proposing?
> 
> 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?

AFAIK the kernel guys have a policy of doing things that can easily
be done in userspace in userspace. Hence i think HAL is the place for
doing it.

The property I suggest is purely optional and would only be set on
laptops where the value is known. 

This particular item is very low priority right now for me, because
PulseAudio opens audio devices in stereo only as default, to minimize
CPU load.

> > 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.

Hmpf. I don't know if I really like that. Because on my laptop the
only interface to the RFILL button is the normal keyboard
controller. The events are already exposed to userspace as (special)
key presses through /dev/input/event0, intermixed with normal
keypresses. To support the in-kernel solution properly this would mean
that a kernel driver would need to hook into the current keyboard
processing and forward the special events to the rfkill subsystem. 

> > - 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
> 
>  http://gitweb.freedesktop.org/?p=hal;a=blob;h=8d235274b9cf555b8878401e70f3134113e63e46;hb=602bbb270d0851047a0bebc442a1fdc92a4f91c7;f=hald/linux2/addons/addon-keyboard.c
> 
> and I think g-p-m does the right thing here. I think Richard Hughes
> knows more; what laptop is it?

That keyboard addon goes in the right direction i guess. However, on my
laptop the scancodes for the special keys are not standard. Hence
this addon would need some special processing for the scancodes
specific to my laptop.

I will look into this a little bit more.

The laptop is an MSI S270. 

http://0pointer.de/lennart/tchibo.html

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/