HAL, sound cards and laptops
danny.kukawka at web.de
Fri Aug 11 06:26:39 PDT 2006
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
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.
More information about the hal