Hi Johan and Luiz, Johan Hedberg wrote: > Hi Luiz, > > On Mon, Mar 29, 2010, Luiz Augusto von Dentz wrote: >> On Mon, Mar 29, 2010 at 11:29 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: >>> Hi Johan, >>> >>>>> Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message >>>>> to inform that adapter properties changed. >>>>> --- >>>>> src/adapter.c | 75 ++++++++++++++++++++++++++++++++++++++++++++------ >>>>> src/adapter.h | 1 + >>>>> src/sdpd-database.c | 3 ++ >>>>> 3 files changed, 70 insertions(+), 9 deletions(-) >>>> Thanks for the patches. In principle they look good, but I haven't >>>> applied them yet due to one thing that looks a bit strange: both the SDP >>>> server record UUID (0x1000) as well as the public browse group UUID >>>> (0x1001) always show up in the UUIDs list. I wonder if there'd be any >>>> clean way to avoid getting them into the list. Marcel, do you have any >>>> idea about this or is it even a problem that these UUIDs are always in >>>> the list? >>> these UUIDs are always in the server, but not in the public browse group >>> and we skip them on purpose. The only reason why they are always present >>> is that the specification requires it. >> IMO, it should be the same list as we export in extended inquiry >> response, so perhaps we could use the data from >> create_ext_inquiry_response which already filter those away. Perhaps >> some refactoring could also be done since this code seems to be called >> multiple times in case of new services because it also changes class >> which then triggers create_ext_inquiry_response again. I'm not so sure about it but create_ext_inquiry_response list all services to any adapters. Shouldn't it list just services per adapter(access_db)? > > That makes quite a lot sense, and is actually what I was chatting with > Marcel about earlier today on irc. The EIR UUIDs list does have a few > restrictions though that the Adapter UUIDs property doesn't have, such > as a maximum limit on the amount of UUIDs (since EIR data is quite > limited in size), so the lists will not always be exactly the same. > > You can see the creation of the EIR list in the for-loop of the > create_ext_inquiry_response function in sdpd-service.c. The most > important part for the Adapter UUIDs property would be the following > code snippet which also answers the original question I had about how to > best get rid of the unnecessary UUIDs: > > if (rec->svclass.value.uuid16 < 0x1100) > continue; > if (rec->svclass.value.uuid16 == PNP_INFO_SVCLASS_ID) > continue; > > In addition those there's also the duplicate UUID check which I think > the original patch was missing. So, if the same code could somehow be > reused for EIR and the Adapter UUIDs property it'd be great. However, if > it's too messy, the above two filters and the duplicate UUID check > should at least be applied to the Adapter UUIDs property. Great! That's the piece of code I was trying to find. I'll try re-organize this code. Thanks, Alecrim. -- 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
