[PATCH 42/56] bluetooth: Get BlueZ 5 device object

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2013-07-25 at 21:41 -0300, Jo?o Paulo Rechi Vita wrote:
> On Mon, Jul 22, 2013 at 11:56 AM, Tanu Kaskinen
> <tanu.kaskinen at linux.intel.com> wrote:
> > If the discovery object was just created, the devices haven't been
> > enumerated yet, so module-bluez5-device doesn't work without loading
> > module-bluez5-discover first. This is nothing new - it looks like the
> > old code did the same thing. I wonder why we even bother to have a
> > separate device module, if it can't be used without the discovery
> > module.
> >
> 
> Bringing the discussion to where it belongs, as I said on 40/56,
> manually loading the device module doesn't work anymore. I don't know
> when it stopped working, but I was never something we cared much
> about, so perhaps we should explicitly not support manually loading
> it. Is there a way to enforce this via PulseAudio's module-loading
> system?

Sorry, I ruined your attempt to have the discussion where it belongs. I
replied to this in the previous mail.

> IIRC was Lennart's suggestion to have this architecture, back in 2008,
> which is similar to how module-detect/module-udev-detect loads audio
> drivers. Even not supporting loading module-bluez5-device without
> loading module-bluez5-discover, it seems to me that there is a better
> separation to have one module for each I/O thread and Bluetooth card
> than having all cards/threads being handled by one module.

In what way is it better? It's entirely possible to keep the code in
separate files without also having a separate module. I don't personally
see the benefit of a separate module.

-- 
Tanu



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux