Hi Vinicius,
Both the NewConnection() (including the authorization of the incoming
L2CAP/RFCOMM connect request) and the Paired property would even then be
delayed until our side has completed its full service discovery.
So should we be reverting commit 456b8c9723b9b73c3ea4cadc8c6f84ca90675f9
Hi Denis,
On 03:27 Thu 25 Apr, Denis Kenzior wrote:
> Hi Johan, Vinicius,
>
> On 04/25/2013 04:37 AM, Johan Hedberg wrote:
> >Hi Mikel,
> >
> >On Thu, Apr 25, 2013, Mikel Astiz wrote:
> >>On Tue, Apr 23, 2013 at 7:28 PM, Johan Hedberg
> >>wrote:
> >>>Hi Marcel,
> >>>
> >>>On Tue, Apr 23, 2013,
Hi Johan, Vinicius,
On 04/25/2013 04:37 AM, Johan Hedberg wrote:
Hi Mikel,
On Thu, Apr 25, 2013, Mikel Astiz wrote:
On Tue, Apr 23, 2013 at 7:28 PM, Johan Hedberg wrote:
Hi Marcel,
On Tue, Apr 23, 2013, Marcel Holtmann wrote:
I don't completely understand the rationale of wanting to make B
Hi Mikel,
On Thu, Apr 25, 2013, Mikel Astiz wrote:
> On Tue, Apr 23, 2013 at 7:28 PM, Johan Hedberg
> wrote:
> > Hi Marcel,
> >
> > On Tue, Apr 23, 2013, Marcel Holtmann wrote:
> >> > I don't completely understand the rationale of wanting to make BlueZ's
> >> > clients so fragile. You could in t
Hi Johan, Marcel,
On Tue, Apr 23, 2013 at 7:28 PM, Johan Hedberg wrote:
> Hi Marcel,
>
> On Tue, Apr 23, 2013, Marcel Holtmann wrote:
>> > I don't completely understand the rationale of wanting to make BlueZ's
>> > clients so fragile. You could in theory get new services way after
>> > pairing if
Hi,
On 20:28 Tue 23 Apr, Johan Hedberg wrote:
> Hi Marcel,
>
> On Tue, Apr 23, 2013, Marcel Holtmann wrote:
> > > I don't completely understand the rationale of wanting to make BlueZ's
> > > clients so fragile. You could in theory get new services way after
> > > pairing if this is configurable o
Hi Marcel,
On Tue, Apr 23, 2013, Marcel Holtmann wrote:
> > I don't completely understand the rationale of wanting to make BlueZ's
> > clients so fragile. You could in theory get new services way after
> > pairing if this is configurable on the remote side. You could also get
> > the result of cal
Hi Johan,
> Even for outgoing pairing requests we may receive the UUIDs property
> changed after the device is paired and try to register it twice.
>
> The easiest way to reproduce this is when Extended Inquiry Response is
> supported.
>
> When the device is paired, w
Hi Marcel,
On Tue, Apr 23, 2013, Marcel Holtmann wrote:
> >>> Even for outgoing pairing requests we may receive the UUIDs property
> >>> changed after the device is paired and try to register it twice.
> >>>
> >>> The easiest way to reproduce this is when Extended Inquiry Response is
> >>> suppor
Hi Johan,
>>> Even for outgoing pairing requests we may receive the UUIDs property
>>> changed after the device is paired and try to register it twice.
>>>
>>> The easiest way to reproduce this is when Extended Inquiry Response is
>>> supported.
>>>
>>> When the device is paired, we receive the
Hi Denis,
On Tue, Apr 23, 2013, Denis Kenzior wrote:
> On 04/22/2013 05:53 PM, Vinicius Costa Gomes wrote:
> >Even for outgoing pairing requests we may receive the UUIDs property
> >changed after the device is paired and try to register it twice.
> >
> >The easiest way to reproduce this is when Ex
Hi Vinicius,
On 04/22/2013 05:53 PM, Vinicius Costa Gomes wrote:
Even for outgoing pairing requests we may receive the UUIDs property
changed after the device is paired and try to register it twice.
The easiest way to reproduce this is when Extended Inquiry Response is
supported.
When the devi
Even for outgoing pairing requests we may receive the UUIDs property
changed after the device is paired and try to register it twice.
The easiest way to reproduce this is when Extended Inquiry Response is
supported.
When the device is paired, we receive the "Paired" PropertyChanged,
inside modem_
13 matches
Mail list logo
