mirror of
https://git.kernel.org/pub/scm/bluetooth/bluez.git
synced 2024-11-26 13:44:23 +08:00
186 lines
6.9 KiB
Plaintext
186 lines
6.9 KiB
Plaintext
Background
|
|
==========
|
|
|
|
- Priority scale: High, Medium and Low
|
|
|
|
- Complexity scale: C1, C2, C4 and C8. The complexity scale is exponential,
|
|
with complexity 1 being the lowest complexity. Complexity is a function
|
|
of both task 'complexity' and task 'scope'.
|
|
|
|
The general rule of thumb is that a complexity 1 task should take 1-2 weeks
|
|
for a person very familiar with BlueZ codebase. Higher complexity tasks
|
|
require more time and have higher uncertainty.
|
|
|
|
Higher complexity tasks should be refined into several lower complexity tasks
|
|
once the task is better understood.
|
|
|
|
General
|
|
==========
|
|
|
|
- Rename glib-helper file to a more convenient name. The ideia is try to keep
|
|
only sdp helpers functions. bt_* prefix shall be also changed.
|
|
|
|
Priority: Low
|
|
Complexity: C1
|
|
|
|
Low Energy
|
|
==========
|
|
|
|
- Advertising management. Adapter interface needs to be changed to manage
|
|
connection modes, adapter type and advertising policy. See Volume 3,
|
|
Part C, section 9.3. If Attribute Server is enabled the LE capable
|
|
adapter shall to start advertising. Further investigation is necessary
|
|
to define which connectable mode needs to be supported: Non-connectable,
|
|
directed connectable and undirected connectable. Basically, two connectable
|
|
scenarios shall be addressed:
|
|
1. GATT client is disconnected, but intends to become a Peripheral to
|
|
receive indications/notifications.
|
|
2. GATT server intends to accept connections.
|
|
|
|
Priority: Medium
|
|
Complexity: C2
|
|
|
|
- Define Auto Connection Establishment Procedure. Some profiles such as
|
|
Proximity requires an active link to identify path lost situation. It is
|
|
necessary to define how to manage connections, it seems that White List
|
|
is appropriated to address auto connections, however is not clear if the
|
|
this procedure shall be a profile specific detail or if the remote device
|
|
object can expose a property "WhiteList", maybe "Trusted" property can be
|
|
also used for this purpose. Another alternative is to define a method to
|
|
allow application to request/register the wanted scanning/connection
|
|
parameters. Before start this task, a RFC/PATCH shall be sent to the ML.
|
|
See Volume 3, Part C, section 9.3.5 for more information.
|
|
|
|
Priority: Medium
|
|
Complexity: C2
|
|
|
|
- Implement a tool(or extend hciconfig) to setup the advertising parameters
|
|
and data. Extend hciconfig passing extra arguments when enabling the
|
|
advertises is not the right approach, it will be almost impossible to
|
|
address all arguments needed in an acceptable way. For testing, we need
|
|
a tool to change easily the AD Flags, the UUIDs and other data that can be
|
|
exported through the advertising data field. Suggestions: 1) extend hciconfig
|
|
passing a config file when enabling advertises; 2) write a ncurses based tool
|
|
|
|
Priority: Medium
|
|
Complexity: C2
|
|
|
|
- Device Name Characteristic is a GAP characteristic for Low Energy. This
|
|
characteristic shall be integrated/used in the discovery procedure. The
|
|
ideia is to report the value of this characteristic using DeviceFound signals.
|
|
Discussion with the community is needed before to start this task. Other GAP
|
|
characteristics for LE needs to follow a similar approach. It is not clear
|
|
if all GAP characteristics can be exposed using properties instead of a primary
|
|
service characteristics.
|
|
See Volume 3, Part C, section 12.1 for more information.
|
|
|
|
Priority: Low
|
|
Complexity: C2
|
|
|
|
ATT/GATT
|
|
========
|
|
|
|
- For BR/EDR, Discover All Primary Services shall be started after SDP if the
|
|
remote device exports a Generic Attribute Profile service record. It is
|
|
applied to CreateDevice and CreatePairedDevice.
|
|
|
|
Priority: Medium
|
|
Complexity: C1
|
|
|
|
- Add ATT/GATT parsing to hcidump
|
|
|
|
Priority: Medium
|
|
Complexity: C2
|
|
|
|
- GATT server: fix MTU exchange
|
|
|
|
Priority: Medium
|
|
Complexity: C2
|
|
|
|
- gatttool: add an interactive command prompt mode. Many LE devices
|
|
expect the connection to stay up a long time and disable advertising
|
|
after a disconnection so it's inconvenient to use gatttool in the
|
|
current "single operation at a time" mode.
|
|
|
|
Priority: Medium
|
|
Complexity: C2
|
|
|
|
- gatttool should have the ability to wait for req responses before
|
|
quitting (some servers require a small sleep even with cmd's). Maybe a
|
|
--delay-exit or --timeout command line switch.
|
|
|
|
Priority: Low
|
|
Complexity: C1
|
|
|
|
- Refactoring of gatt.c functions. Currently, the callbacks of the services
|
|
and characteristics discovery functions return the ATT PDU and the caller
|
|
needs to call again the same function to fetch the remaining data when
|
|
necessary. Investigate if all results can be returned in the callback
|
|
result to avoid repeated code. Before change the code, please analyze
|
|
if this change will not break the GATT/ATT qualification tests. Maybe
|
|
an interactive fetch/query is necessary to pass the tests.
|
|
|
|
Priority: Low
|
|
Complexity: C1
|
|
|
|
- Client needs to export a property in the Device Characteristic hierarchy
|
|
to manage characteristic value changes reports in the remote device.
|
|
Currently, Client Characteristic Configuration attribute is not exposed
|
|
as an object. The user needs to use gatttool to change the value of the
|
|
this attribute to receive notification/indications. Export this attribute
|
|
as a property is a proposal that needs further discussion.
|
|
|
|
Priority: Low
|
|
Complexity: C1
|
|
|
|
- Attribute server should process queued GATT/ATT commands if the
|
|
client disconnects. The client can simply send a command and quit,
|
|
without wait for a response(ex: Write Command). For this scenario
|
|
that the client disconnects the link quickly the queued received
|
|
command is ignored.
|
|
|
|
Priority: Low
|
|
Complecity: C1
|
|
|
|
- Add sdp discovery support to gattool with BR (--sdp, default is 0x1f)
|
|
|
|
Priority: Low
|
|
Complexity: C1
|
|
|
|
- Implement Server characteristic Configuration support in the attribute
|
|
server to manage characteristic value broadcasting. There is a single
|
|
instance of the Server Characteristic Configuration for all clients.
|
|
See Volume 3, Part G, section 3.3.3.4 for more information.
|
|
|
|
Priority: Low
|
|
Complexity: C1
|
|
|
|
- Long reads/writes don't work (consisting of multiple request packets)
|
|
|
|
Priority: Low
|
|
Complexity: C2
|
|
|
|
- Implement Client Characteristic Configuration support in the attribute
|
|
server to manage indications and notications. This is a per client attribute
|
|
to control how the client wants to receive reports of changes in a given
|
|
characteristic value.
|
|
See Volume 3, Part G, section 3.3.3.3 for more information
|
|
|
|
Priority: Low
|
|
Complexity: C2
|
|
|
|
- Define attribute server API. External applications needs to register,
|
|
change attributes and to be notified about changes. Example: Proximity,
|
|
Time and Alert Profiles. "Local Service hierarchy" in the attribute-api
|
|
needs to be proposed and a RFC shall be sent to the ML.
|
|
|
|
Priority: Low
|
|
Complexity: C2
|
|
|
|
- gattrib needs to be extended to handle Attribute Protocol Transactions
|
|
timeout. See Volume 3, Part F, section 3.3.3 and Part G, section 4.14
|
|
for more information.
|
|
|
|
Priority: Low
|
|
Complexity: C2
|