HAL, sound cards and laptops

[Danny Kukawka]

On Friday 11 August 2006 14:55, Lennart Poettering wrote:
> On Tue, 08.08.06 14:04, Danny Kukawka (danny.kukawka at web.de) wrote:
> > 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 HAL.
>
> Hmm? I think this is very broken by SUSE.

Why should there be something broken? Why should we not allow a user to use 
_existing_ _valid_ devices?

> But anyway. Would you at least merge a patch which would change the
> "oss.type" to "pcm-solaris-legacy" or something like that?

Maybe 'oss-legacy' or only 'legacy', it's more generic?

> Look, this specific device file might reside in different locations on
> different operating systems. Just think of devfs device paths. Or
> think of someone having a UDEV rule which renames his sound devices
> for him, so that "/dev/audio" becomes "/dev/intel-hda-audio" and so
> on. Or think of MacOSX where the file systems layout is completely
> different from the FHS.

Then match for linux.sysfs_path ... there is no difference.

> > device: what happen if the next come and don't want to
> > display /dev/dsp ? ... ;-)
>
> Oh, come on! Stay reasonable, please!

But this is the same. Why should we remove existing devices from HAL?

> I am just arguing that modern programs which use HAL should not use
> /dev/audio. And legacy applications that do use /dev/audio do not use
> HAL.

This isn't a argument for me, there are maybe also programms which are not 
_modern_, which like to use hal directly or indirectly and they would like to 
use /dev/audio. Sorry, but again: I don't understand what's the problem with 
a strncmp() ... if you do this in your application you can filter what you 
need and we don't lose infos in HAL which maybe needed by other applications.

Danny