RE: [PATCH v2 9/9] Bluetooth: Support LE-Only discovery procedure

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

 



Johan, 

> -----Original Message-----
> From: Johan Hedberg [mailto:johan.hedberg@xxxxxxxxx]
> Sent: Wednesday, November 30, 2011 1:27 PM
> To: Ganir, Chen
> Cc: Andre Guedes; linux-bluetooth@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v2 9/9] Bluetooth: Support LE-Only discovery
> procedure
> 
> Hi Chen,
> 
> On Wed, Nov 30, 2011, Ganir, Chen wrote:
> > > Firstly you should realize that this is not about functionality
> exposed
> > > to the user or applications, but functionality exposed to
> bluetoothd.
> > > The fact that we have something in the mgmt interface doesn't mean
> that
> > > it'll automatically be exposed in the D-Bus interface or bluetoothd
> > > internal APIs.
> > >
> > > As for this particular case (allowing bluetoothd to restrict device
> > > discovery to LE or BR/EDR) the reason is the concern that when
> doing
> > > discovery for a specific profile which is only applicable for
> BR/EDR or
> > > LE, you really don't want to waste the users time doing the "other"
> > > discovery which will not yield any valuable results. Examples of
> this
> > > could be discovering devices to send a file over Object Push
> (BR/EDR
> > > only) or when running a application for a LE profile which utilizes
> > > features only available though an LE radio.
> > >
> > > I'm not completely sure the need for this will be strong enough for
> > > exposing it in the D-Bus API, but not having it in the kernel
> interface
> > > (mgmt) from the start makes it a lot harder to fix if we do end up
> > > needing it later (as opposed to the D-Bus interface which would
> "only"
> > > mean doing a new major BlueZ version).
> > >
> > > Johan
> >
> > If this is the case, and we know that for now, we have no need for
> > this, why introduce more complexity?
> 
> I really fail to see what you can consider complex about a single extra
> parameter to start_discovery.
> 
> > How will the current GAP device search work?
> 
> Just like it has worked so far.
> 
> > How will interleaved scanning work?
> 
> Just like it would work without the extra parameter. It gets triggered
> when user-space (bluetoothd) says it wants LE + BR/EDR discovery.
> 
> > Will it be triggered from the bluetoothd?
> 
> Yes, just like it would without the extra parameter.
> 
> > Will it be handled by the kernel ?
> 
> Yes, just like it would without the extra parameter.
> 
> Johan

What I meant to ask was who is responsible for asking for dual mode or single mode scan now that the parameters were added ? Does the bluetoothd now needs to know if the controller and host support LE, so it can start a BR/EDR/LE scan ? or will the bluetoothd always ask for BR/EDR/LE scan, and the kernel will execute the supported search according to the LMP flags ?

Chen.

--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux