Hi Johan, > > >> 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)? > > It should be per-adapter (or records registered to BDADDR_ANY) since EIR > is also per-adapter, so looks like a possible bug in the current > implementation. > > Btw, another restriction to note with the current EIR UUID list > implementation is that it only supports 16-bit UUIDs. The EIR format > itself would support also 32 and 128 bit formats but probably for > simplicity these have been left out. The Adapter UUIDs list should > however contain all UUIDs (with the exceptions that we already > discussed). it should also contain the UUID-128 ones (the UUID-32 are pointless and with LE they are gone for good). The reason why these were left out is because it is pretty hard to fit them into the limited space of EIR. If you are up for fixing this, then I am more than happy to have this. I think we need to introduce some priority mapping here to decide which UUID list to cut in favor of others. Same as how we can shortcut the device name etc. So in general the DID information and at least a short device name should be present. For the short name, we might need another config file option or some plugin way of retrieving the short name. Also I want to have the TX power information available if the chip supports it. The rest of the space can be used for UUIDs in whatever way fits. The more UUIDs are in the list the better actually. Regards Marcel -- 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
