Hi, On Wednesday 26 of February 2014 12:34:29 Andrzej Kaczmarek wrote: > Hi Marcel, > > On 26 February 2014 09:51, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > > Hi Jakub, > > > >> Add missing Listen and Set Advertising Data opcodes and reorder them as > >> they appear in HAL's headers. > > > > I left this out originally since they are only useful for when we are a peripheral. Curious to know if Android APIs actually support this. > > It does, but not as public API - internal apps can still use them but > only if platform has config_bluetooth_le_peripheral_mode_supported > flag set, so perhaps this is for some gadgets running Android. > > > GATT client and server are valid for central role. And the connect/disconnect need to be turned into being one pair of commands. No point in duplicating them. There is really no difference between a GATT client and server connect. The central will connect to the peripheral. Unless Android got fully confused and uses the APIs wrongly. > > These commands are separated for client and server since they have > either client or server app id as parameter which is later used to > dispatch callbacks to proper application. So using one pair of > commands (and single notification) we can still figure out which > callback to use in HAL as long as we have 'type' parameter for app id. I'd keep our IPC as close to HAL API as possible and go with separate commands and notifications. Especially since otherwise we need to add type field as pointed by Andrzej. -- Best regards, Szymon Janc -- 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
