* [BlueZ v2 1/7] doc: Port assigned-numbers.txt to RST
2026-01-20 17:18 [BlueZ v2 0/7] Port text docs to RST Bastien Nocera
@ 2026-01-20 17:18 ` Bastien Nocera
2026-01-20 18:34 ` Port text docs " bluez.test.bot
2026-01-20 17:18 ` [BlueZ v2 2/7] doc: Port thermometer-api.txt " Bastien Nocera
` (5 subsequent siblings)
6 siblings, 1 reply; 10+ messages in thread
From: Bastien Nocera @ 2026-01-20 17:18 UTC (permalink / raw)
To: linux-bluetooth
---
Makefile.am | 2 +-
doc/assigned-numbers.rst | 29 +++++++++++++++++++++++++++++
doc/assigned-numbers.txt | 26 --------------------------
3 files changed, 30 insertions(+), 27 deletions(-)
create mode 100644 doc/assigned-numbers.rst
delete mode 100644 doc/assigned-numbers.txt
diff --git a/Makefile.am b/Makefile.am
index 3adfa6cd51c3..acd28732aa2d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -473,7 +473,7 @@ endif
EXTRA_DIST += $(test_scripts)
-EXTRA_DIST += doc/assigned-numbers.txt doc/supported-features.txt \
+EXTRA_DIST += doc/assigned-numbers.rst doc/supported-features.txt \
doc/test-coverage.txt \
doc/test-runner.rst \
doc/settings-storage.txt
diff --git a/doc/assigned-numbers.rst b/doc/assigned-numbers.rst
new file mode 100644
index 000000000000..e3fcb65b83df
--- /dev/null
+++ b/doc/assigned-numbers.rst
@@ -0,0 +1,29 @@
+===============
+RFCOMM Channels
+===============
+
+Since there are a limited amount of possible RFCOMM channels (1-31)
+they've been pre-allocated for currently known profiles in order to
+avoid conflicts.
+
+.. csv-table::
+ :header: "Profile", "Channel"
+ :widths: auto
+
+ DUN, 1
+ SPP, 3
+ HSP HS, 6
+ HFP HF, 7
+ OPP, 9
+ FTP, 10
+ BIP, 11
+ HSP AG, 12
+ HFP AG, 13
+ SYNCH (IrMC), 14
+ PBAP, 15
+ MAP MAS, 16
+ MAP MNS, 17
+ SyncEvolution, 19
+ PC/Ovi Suite, 24
+ SyncML Client, 25
+ SyncML Server, 26
diff --git a/doc/assigned-numbers.txt b/doc/assigned-numbers.txt
deleted file mode 100644
index cf481c15eb88..000000000000
--- a/doc/assigned-numbers.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-RFCOMM Channels
-===============
-
-Since there are a limited amount of possible RFCOMM channels (1-31)
-they've been pre-allocated for currently known profiles in order to
-avoid conflicts.
-
-Profile Channel
------------------------
-DUN 1
-SPP 3
-HSP HS 6
-HFP HF 7
-OPP 9
-FTP 10
-BIP 11
-HSP AG 12
-HFP AG 13
-SYNCH (IrMC) 14
-PBAP 15
-MAP MAS 16
-MAP MNS 17
-SyncEvolution 19
-PC/Ovi Suite 24
-SyncML Client 25
-SyncML Server 26
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* RE: Port text docs to RST
2026-01-20 17:18 ` [BlueZ v2 1/7] doc: Port assigned-numbers.txt " Bastien Nocera
@ 2026-01-20 18:34 ` bluez.test.bot
0 siblings, 0 replies; 10+ messages in thread
From: bluez.test.bot @ 2026-01-20 18:34 UTC (permalink / raw)
To: linux-bluetooth, hadess
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1044790
---Test result---
Test Summary:
CheckPatch PENDING 0.43 seconds
GitLint PENDING 0.30 seconds
BuildEll PASS 19.81 seconds
BluezMake PASS 624.90 seconds
MakeCheck PASS 18.15 seconds
MakeDistcheck PASS 240.52 seconds
CheckValgrind PASS 291.00 seconds
CheckSmatch PASS 348.67 seconds
bluezmakeextell PASS 180.97 seconds
IncrementalBuild PENDING 0.34 seconds
ScanBuild PASS 1009.27 seconds
Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:
##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:
---
Regards,
Linux Bluetooth
^ permalink raw reply [flat|nested] 10+ messages in thread
* [BlueZ v2 2/7] doc: Port thermometer-api.txt to RST
2026-01-20 17:18 [BlueZ v2 0/7] Port text docs to RST Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 1/7] doc: Port assigned-numbers.txt " Bastien Nocera
@ 2026-01-20 17:18 ` Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 3/7] doc: Port security-bugs.txt " Bastien Nocera
` (4 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Bastien Nocera @ 2026-01-20 17:18 UTC (permalink / raw)
To: linux-bluetooth
---
Makefile.am | 10 ++
doc/org.bluez.Thermometer.rst | 51 ++++++++++
doc/org.bluez.ThermometerManager.rst | 64 +++++++++++++
doc/org.bluez.ThermometerWatcher.rst | 79 ++++++++++++++++
doc/thermometer-api.txt | 134 ---------------------------
5 files changed, 204 insertions(+), 134 deletions(-)
create mode 100644 doc/org.bluez.Thermometer.rst
create mode 100644 doc/org.bluez.ThermometerManager.rst
create mode 100644 doc/org.bluez.ThermometerWatcher.rst
delete mode 100644 doc/thermometer-api.txt
diff --git a/Makefile.am b/Makefile.am
index acd28732aa2d..d80c1250a417 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -399,6 +399,9 @@ man_MANS += doc/org.bluez.obex.Client.5 doc/org.bluez.obex.Session.5 \
doc/org.bluez.obex.AgentManager.5 doc/org.bluez.obex.Agent.5 \
doc/org.bluez.obex.Image.5
man_MANS += doc/org.bluez.Telephony.5 doc/org.bluez.Call.5
+man_MANS += doc/org.bluez.ThermometerManager.5 \
+ doc/org.bluez.Thermometer.5 \
+ doc/org.bluez.ThermometerWatcher.5
endif
manual_pages += src/bluetoothd.8
manual_pages += doc/hci.7 doc/mgmt.7 doc/l2cap.7 doc/rfcomm.7 doc/sco.7 \
@@ -436,6 +439,9 @@ manual_pages += doc/org.bluez.obex.Client.5 doc/org.bluez.obex.Session.5 \
doc/org.bluez.obex.AgentManager.5 doc/org.bluez.obex.Agent.5 \
doc/org.bluez.obex.Image.5
manual_pages += doc/org.bluez.Telephony.5 doc/org.bluez.Call.5
+manual_pages += doc/org.bluez.ThermometerManager.5 \
+ doc/org.bluez.Thermometer.5 \
+ doc/org.bluez.ThermometerWatcher.5
EXTRA_DIST += src/genbuiltin src/bluetooth.conf \
src/main.conf profiles/network/network.conf \
@@ -522,6 +528,10 @@ EXTRA_DIST += doc/org.bluez.obex.Client.rst doc/org.bluez.obex.Session.rst \
EXTRA_DIST += doc/org.bluez.Telephony.rst doc/org.bluez.Call.rst
+EXTRA_DIST += doc/org.bluez.ThermometerManager.rst \
+ doc/org.bluez.Thermometer.rst \
+ doc/org.bluez.ThermometerWatcher.rst
+
EXTRA_DIST += doc/pics-opp.txt doc/pixit-opp.txt \
doc/pts-opp.txt
diff --git a/doc/org.bluez.Thermometer.rst b/doc/org.bluez.Thermometer.rst
new file mode 100644
index 000000000000..cc7e4f8d19c2
--- /dev/null
+++ b/doc/org.bluez.Thermometer.rst
@@ -0,0 +1,51 @@
+=====================
+org.bluez.Thermometer
+=====================
+
+------------------------------------------------
+BlueZ D-Bus Health Thermometer API documentation
+------------------------------------------------
+
+:Version: BlueZ
+:Date: July 2011
+:Author: Santiago Carot-Nemesio <sancane@gmail.com>
+:Manual section: 5
+:Manual group: Linux System Administration
+
+Interface
+=========
+
+:Service: org.bluez
+:Interface: org.bluez.Thermometer1
+:Object path: [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+Properties
+----------
+
+boolean Intermediate [readonly]
+```````````````````````````````
+
+True if the thermometer supports intermediate
+measurement notifications.
+
+uint16 Interval (optional) [readwrite]
+``````````````````````````````````````
+
+The Measurement Interval defines the time (in
+seconds) between measurements. This interval is
+not related to the intermediate measurements and
+must be defined into a valid range. Setting it
+to zero means that no periodic measurements will
+be taken.
+
+uint16 Maximum (optional) [readonly]
+````````````````````````````````````
+
+Defines the maximum value allowed for the interval
+between periodic measurements.
+
+uint16 Minimum (optional) [readonly]
+````````````````````````````````````
+
+Defines the minimum value allowed for the interval
+between periodic measurements.
diff --git a/doc/org.bluez.ThermometerManager.rst b/doc/org.bluez.ThermometerManager.rst
new file mode 100644
index 000000000000..5e46fd54a456
--- /dev/null
+++ b/doc/org.bluez.ThermometerManager.rst
@@ -0,0 +1,64 @@
+============================
+org.bluez.ThermometerManager
+============================
+
+-------------------------------------------------------
+BlueZ D-Bus Health ThermometerManager API documentation
+-------------------------------------------------------
+
+:Version: BlueZ
+:Date: July 2011
+:Author: Santiago Carot-Nemesio <sancane@gmail.com>
+:Manual section: 5
+:Manual group: Linux System Administration
+
+Interface
+=========
+
+:Service: org.bluez
+:Interface: org.bluez.ThermometerManager1
+:Object path: [variable prefix]/{hci0,hci1,...}
+
+Methods
+-------
+
+void RegisterWatcher(object agent)
+``````````````````````````````````
+
+Registers a watcher to monitor scanned measurements.
+This agent will be notified about final temperature
+measurements.
+
+Possible Errors:
+
+:org.bluez.Error.InvalidArguments:
+
+
+void UnregisterWatcher(object agent)
+````````````````````````````````````
+
+Unregisters a watcher.
+
+void EnableIntermediateMeasurement(object agent)
+````````````````````````````````````````````````
+
+Enables intermediate measurement notifications
+for this agent. Intermediate measurements will
+be enabled only for thermometers which support it.
+
+Possible Errors:
+
+:org.bluez.Error.InvalidArguments:
+
+void DisableIntermediateMeasurement(object agent)
+`````````````````````````````````````````````````
+
+Disables intermediate measurement notifications
+for this agent. It will disable notifications in
+thermometers when the last agent removes the
+watcher for intermediate measurements.
+
+Possible Errors:
+
+:org.bluez.Error.InvalidArguments:
+:org.bluez.Error.NotFound:
diff --git a/doc/org.bluez.ThermometerWatcher.rst b/doc/org.bluez.ThermometerWatcher.rst
new file mode 100644
index 000000000000..2f115f66ab94
--- /dev/null
+++ b/doc/org.bluez.ThermometerWatcher.rst
@@ -0,0 +1,79 @@
+============================
+org.bluez.ThermometerWatcher
+============================
+
+--------------------------------------------------------
+BlueZ D-Bus Health Thermometer Watcher API documentation
+--------------------------------------------------------
+
+:Version: BlueZ
+:Date: July 2011
+:Author: Santiago Carot-Nemesio <sancane@gmail.com>
+:Manual section: 5
+:Manual group: Linux System Administration
+
+Interface
+=========
+
+:Service: unique name
+:Interface: org.bluez.ThermometerWatcher1
+:Object path: freely definable
+
+Methods
+-------
+
+void MeasurementReceived(dict measurement)
+``````````````````````````````````````````
+
+This callback gets called when a measurement has been
+scanned in the thermometer.
+
+Possible measurement values:
+
+:int16 Exponent:
+:int32 Mantissa:
+
+ Exponent and Mantissa values as extracted from float value defined by
+ IEEE-11073-20601.
+
+ Measurement value is calculated as
+ (Mantissa) * (10^Exponent)
+
+ For special cases Exponent is
+ set to 0 and Mantissa is set to
+ one of following values:
+
+.. csv-table::
+ :header: "Value", "Description"
+ :widths: auto
+
+ +(2^23 - 1), NaN (invalid or missing data)
+ -(2^23), NRes
+ +(2^23 - 2), +Infinity
+ -(2^23 - 2), -Infinity
+
+:string Unit:
+
+ Possible values: "celsius" or
+ "fahrenheit"
+
+:uint64 Time (optional):
+
+ Time of measurement, if
+ supported by device.
+ Expressed in seconds since epoch.
+
+:string Type (optional):
+
+ Only present if measurement type
+ is known.
+
+ Possible values: "armpit", "body",
+ "ear", "finger", "intestines",
+ "mouth", "rectum", "toe",
+ "tympanum"
+
+:string Measurement:
+
+ Possible values: "final" or "intermediate"
+
diff --git a/doc/thermometer-api.txt b/doc/thermometer-api.txt
deleted file mode 100644
index c7c8a5dadee0..000000000000
--- a/doc/thermometer-api.txt
+++ /dev/null
@@ -1,134 +0,0 @@
-BlueZ D-Bus Thermometer API description
-***************************************
-
- Santiago Carot-Nemesio <sancane@gmail.com>
-
-Health Thermometer Manager hierarchy
-====================================
-
-Service org.bluez
-Interface org.bluez.ThermometerManager1
-Object path [variable prefix]/{hci0,hci1,...}
-
-Methods RegisterWatcher(object agent)
-
- Registers a watcher to monitor scanned measurements.
- This agent will be notified about final temperature
- measurements.
-
- Possible Errors: org.bluez.Error.InvalidArguments
-
- UnregisterWatcher(object agent)
-
- Unregisters a watcher.
-
- EnableIntermediateMeasurement(object agent)
-
- Enables intermediate measurement notifications
- for this agent. Intermediate measurements will
- be enabled only for thermometers which support it.
-
- Possible Errors: org.bluez.Error.InvalidArguments
-
- DisableIntermediateMeasurement(object agent)
-
- Disables intermediate measurement notifications
- for this agent. It will disable notifications in
- thermometers when the last agent removes the
- watcher for intermediate measurements.
-
- Possible Errors: org.bluez.Error.InvalidArguments
- org.bluez.Error.NotFound
-
-Health Thermometer Profile hierarchy
-====================================
-
-Service org.bluez
-Interface org.bluez.Thermometer1
-Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
-
-
-Properties boolean Intermediate [readonly]
-
- True if the thermometer supports intermediate
- measurement notifications.
-
- uint16 Interval (optional) [readwrite]
-
- The Measurement Interval defines the time (in
- seconds) between measurements. This interval is
- not related to the intermediate measurements and
- must be defined into a valid range. Setting it
- to zero means that no periodic measurements will
- be taken.
-
- uint16 Maximum (optional) [readonly]
-
- Defines the maximum value allowed for the interval
- between periodic measurements.
-
- uint16 Minimum (optional) [readonly]
-
- Defines the minimum value allowed for the interval
- between periodic measurements.
-
-
-Health Thermometer Watcher hierarchy
-====================================
-
-Service unique name
-Interface org.bluez.ThermometerWatcher1
-Object path freely definable
-
-Methods void MeasurementReceived(dict measurement)
-
- This callback gets called when a measurement has been
- scanned in the thermometer.
-
- Measurement:
-
- int16 Exponent:
- int32 Mantissa:
-
- Exponent and Mantissa values as
- extracted from float value defined by
- IEEE-11073-20601.
-
- Measurement value is calculated as
- (Mantissa) * (10^Exponent)
-
- For special cases Exponent is
- set to 0 and Mantissa is set to
- one of following values:
-
- +(2^23 - 1) NaN (invalid or
- missing data)
- -(2^23) NRes
- +(2^23 - 2) +Infinity
- -(2^23 - 2) -Infinity
-
- string Unit:
-
- Possible values: "celsius" or
- "fahrenheit"
-
- uint64 Time (optional):
-
- Time of measurement, if
- supported by device.
- Expressed in seconds since epoch.
-
- string Type (optional):
-
- Only present if measurement type
- is known.
-
- Possible values: "armpit", "body",
- "ear", "finger", "intestines",
- "mouth", "rectum", "toe",
- "tympanum"
-
- string Measurement:
-
- Possible values: "final" or
- "intermediate"
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [BlueZ v2 3/7] doc: Port security-bugs.txt to RST
2026-01-20 17:18 [BlueZ v2 0/7] Port text docs to RST Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 1/7] doc: Port assigned-numbers.txt " Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 2/7] doc: Port thermometer-api.txt " Bastien Nocera
@ 2026-01-20 17:18 ` Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 4/7] doc: Port coding-style.txt " Bastien Nocera
` (3 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Bastien Nocera @ 2026-01-20 17:18 UTC (permalink / raw)
To: linux-bluetooth
---
doc/{security-bugs.txt => security-bugs.rst} | 1 +
1 file changed, 1 insertion(+)
rename doc/{security-bugs.txt => security-bugs.rst} (99%)
diff --git a/doc/security-bugs.txt b/doc/security-bugs.rst
similarity index 99%
rename from doc/security-bugs.txt
rename to doc/security-bugs.rst
index bd4b0d68f309..0dcacfbd9eac 100644
--- a/doc/security-bugs.txt
+++ b/doc/security-bugs.rst
@@ -1,3 +1,4 @@
+=============
Security bugs
=============
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [BlueZ v2 4/7] doc: Port coding-style.txt to RST
2026-01-20 17:18 [BlueZ v2 0/7] Port text docs to RST Bastien Nocera
` (2 preceding siblings ...)
2026-01-20 17:18 ` [BlueZ v2 3/7] doc: Port security-bugs.txt " Bastien Nocera
@ 2026-01-20 17:18 ` Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 5/7] doc: Port sap-api.txt " Bastien Nocera
` (2 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Bastien Nocera @ 2026-01-20 17:18 UTC (permalink / raw)
To: linux-bluetooth
---
doc/coding-style.rst | 349 +++++++++++++++++++++++++++++++++++++++++++
doc/coding-style.txt | 279 ----------------------------------
2 files changed, 349 insertions(+), 279 deletions(-)
create mode 100644 doc/coding-style.rst
delete mode 100644 doc/coding-style.txt
diff --git a/doc/coding-style.rst b/doc/coding-style.rst
new file mode 100644
index 000000000000..91250e867f09
--- /dev/null
+++ b/doc/coding-style.rst
@@ -0,0 +1,349 @@
+==================
+BlueZ coding style
+==================
+
+Every project has its coding style, and BlueZ is not an exception. This
+document describes the preferred coding style for BlueZ code, in order to keep
+some level of consistency among developers so that code can be easily
+understood and maintained.
+
+First of all, BlueZ coding style must follow every rule for Linux kernel
+(https://www.kernel.org/doc/Documentation/process/coding-style.rst). There also
+exists a tool named checkpatch.pl to help you check the compliance with it.
+Just type ``checkpatch.pl --no-tree patch_name`` to check your patch. In theory,
+you need to clean up all the warnings and errors except this one: ``ERROR:
+Missing Signed-off-by: line(s)``. BlueZ does not used ``Signed-off-by`` lines, so
+including them is actually an error. In certain circumstances one can ignore
+the 80 character per line limit. This is generally only allowed if the
+alternative would make the code even less readable.
+
+Besides the kernel coding style above, BlueZ has special flavors for its own.
+Some of them are mandatory (marked as ``M``), while some others are optional
+(marked as ``O``), but generally preferred.
+
+M1: Blank line before and after an if/while/do/for statement
+------------------------------------------------------------
+
+There should be a blank line before ``if`` statement unless the ``if`` is nested and
+not preceded by an expression or variable declaration.
+
+Example:
+1)
+
+.. code-block:: C
+
+ a = 1;
+ if (b) { // wrong
+
+2)
+
+.. code-block:: C
+
+ a = 1
+
+ if (b) {
+ }
+ a = 2; // wrong
+
+3)
+
+.. code-block:: C
+
+ if (a) {
+ if (b) // correct
+
+4)
+
+.. code-block:: C
+
+ b = 2;
+
+ if (a) { // correct
+
+ }
+
+ b = 3;
+
+The only exception to this rule applies when a variable is being checked for
+errors as such:
+
+.. code-block:: C
+
+ err = stat(filename, &st);
+ if (err || !S_ISDIR(st.st_mode))
+ return;
+
+M2: Multiple line comment
+-------------------------
+
+If your comment has more than one line, please start it from the second line.
+
+Example:
+
+.. code-block:: C
+
+ /*
+ * first line comment // correct
+ * ...
+ * last line comment
+ */
+
+M3: Space before and after operator
+-----------------------------------
+
+There should be a space before and after each operator.
+
+Example:
+
+.. code-block:: C
+
+ a + b; // correct
+
+
+M4: Wrap long lines
+-------------------
+
+If your condition in ``if``, ``while``, ``for`` statement or a function declaration is too
+long to fit in one line, the new line needs to be indented not aligned with the
+body.
+
+Example:
+1)
+
+.. code-block:: C
+
+ if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
+ !(adapter->current_settings & MGMT_SETTING_SSP)) // wrong
+
+2)
+
+.. code-block:: C
+
+ if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
+ !(adapter->current_settings & MGMT_SETTING_SSP))
+
+3)
+
+.. code-block:: C
+
+ void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
+ btd_adapter_pin_cb_t cb) // wrong
+
+4)
+
+.. code-block:: C
+
+ void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
+ btd_adapter_pin_cb_t cb)
+
+The referred style for line wrapping is to indent as far as possible to the
+right without hitting the 80 columns limit.
+
+M5: Space when doing type casting
+---------------------------------
+
+There should be a space between new type and variable.
+
+Example:
+1)
+
+.. code-block:: C
+
+ a = (int *)b; // wrong
+
+2)
+
+.. code-block:: C
+
+ a = (int *) b; // correct
+
+
+M6: Don't initialize variable unnecessarily
+-------------------------------------------
+
+When declaring a variable, try not to initialize it unless necessary.
+
+Example:
+
+.. code-block:: C
+
+ int i = 1; // wrong
+
+ for (i = 0; i < 3; i++) {
+ }
+
+M7: Follow the order of include header elements
+-----------------------------------------------
+
+When writing an include header the various elements should be in the following
+order:
+
+* ``#include``'s
+* forward declarations
+* ``#define``'s
+* ``enum``'s
+* ``typedef``'s
+* function declarations and inline function definitions
+
+M8: Internal headers must not use include guards
+------------------------------------------------
+
+Any time when creating a new header file with non-public API, that header
+must not contain include guards.
+
+M9: Naming of enums
+-------------------
+
+Enums must have a descriptive name. The enum type should be small caps and
+it should not be ``typedef``'ed. Enum contents should be in CAPITAL letters and
+prefixed by the ``enum`` type name.
+
+Example:
+
+.. code-block:: C
+
+ enum animal_type {
+ ANIMAL_TYPE_FOUR_LEGS,
+ ANIMAL_TYPE_EIGHT_LEGS,
+ ANIMAL_TYPE_TWO_LEGS,
+ };
+
+If the enum contents have values (e.g. from specification) the formatting
+should be as follows:
+
+.. code-block:: C
+
+ enum animal_type {
+ ANIMAL_TYPE_FOUR_LEGS = 4,
+ ANIMAL_TYPE_EIGHT_LEGS = 8,
+ ANIMAL_TYPE_TWO_LEGS = 2,
+ };
+
+M10: Enum as switch variable
+----------------------------
+
+If the variable of a ``switch`` is an enum, you must include all values in
+switch body even if providing ``default``. This is enforced by compiler option
+enabling extra warning in such case. The reason for this is to ensure that if
+later on the enum is modified and one forget to change the ``switch`` accordingly, the
+compiler will complain the new added type hasn't been handled.
+
+Example:
+
+.. code-block:: C
+
+ enum animal_type {
+ ANIMAL_TYPE_FOUR_LEGS = 4,
+ ANIMAL_TYPE_EIGHT_LEGS = 8,
+ ANIMAL_TYPE_TWO_LEGS = 2,
+ };
+
+ enum animal_type t;
+
+ switch (t) { // OK
+ case ANIMAL_TYPE_FOUR_LEGS:
+ ...
+ break;
+ case ANIMAL_TYPE_EIGHT_LEGS:
+ ...
+ break;
+ case ANIMAL_TYPE_TWO_LEGS:
+ ...
+ break;
+ default:
+ break;
+ }
+
+ switch (t) { // Wrong
+ case ANIMAL_TYPE_FOUR_LEGS:
+ ...
+ break;
+ case ANIMAL_TYPE_TWO_LEGS:
+ ...
+ break;
+ default:
+ break;
+ }
+
+However if the enum comes from an external header file outside BlueZ, such as
+Android headers, we cannot make any assumption of how the enum is defined and
+this rule might not apply.
+
+M11: Always use parenthesis with sizeof
+---------------------------------------
+
+The expression argument to the ``sizeof`` operator should always be in
+parenthesis, too.
+
+Example:
+1)
+
+.. code-block:: C
+
+ memset(stuff, 0, sizeof(*stuff));
+
+2)
+
+.. code-block:: C
+
+ memset(stuff, 0, sizeof *stuff); // Wrong
+
+M12: Use void if function has no parameters
+-------------------------------------------
+
+A function with no parameters must use ``void`` in the parameter list.
+
+Example:
+1)
+
+.. code-block:: C
+
+ void foo(void)
+ {
+ }
+
+2)
+
+.. code-block:: C
+
+ void foo() // Wrong
+ {
+ }
+
+O1: Try to avoid complex if body
+--------------------------------
+
+It's better not to have a complicated statement for ``if``. You may judge its
+contrary condition and ``return``, ``break``, ``continue`` or ``goto`` as soon
+as possible.
+
+Example:
+
+1)
+
+.. code-block:: C
+
+ if (device) { // worse
+ memset(&eir_data, 0, sizeof(eir_data));
+ if (eir_len > 0)
+ eir_parse(&eir_data, ev->eir, eir_len);
+ ...
+ } else {
+ error("Unable to get device object for %s", addr);
+ return;
+ }
+
+2)
+
+.. code-block:: C
+
+ if (!device) {
+ error("Unable to get device object for %s", addr);
+ return;
+ }
+
+ memset(&eir_data, 0, sizeof(eir_data));
+ if (eir_len > 0)
+ eir_parse(&eir_data, ev->eir, eir_len);
+ ...
+
diff --git a/doc/coding-style.txt b/doc/coding-style.txt
deleted file mode 100644
index e73158840ff6..000000000000
--- a/doc/coding-style.txt
+++ /dev/null
@@ -1,279 +0,0 @@
-BlueZ coding style
-******************
-
-Every project has its coding style, and BlueZ is not an exception. This
-document describes the preferred coding style for BlueZ code, in order to keep
-some level of consistency among developers so that code can be easily
-understood and maintained.
-
-First of all, BlueZ coding style must follow every rule for Linux kernel
-(https://www.kernel.org/doc/Documentation/process/coding-style.rst). There also
-exists a tool named checkpatch.pl to help you check the compliance with it.
-Just type "checkpatch.pl --no-tree patch_name" to check your patch. In theory,
-you need to clean up all the warnings and errors except this one: "ERROR:
-Missing Signed-off-by: line(s)". BlueZ does not used Signed-Off lines, so
-including them is actually an error. In certain circumstances one can ignore
-the 80 character per line limit. This is generally only allowed if the
-alternative would make the code even less readable.
-
-Besides the kernel coding style above, BlueZ has special flavors for its own.
-Some of them are mandatory (marked as 'M'), while some others are optional
-(marked as 'O'), but generally preferred.
-
-M1: Blank line before and after an if/while/do/for statement
-============================================================
-
-There should be a blank line before if statement unless the if is nested and
-not preceded by an expression or variable declaration.
-
-Example:
-1)
-a = 1;
-if (b) { // wrong
-
-2)
-a = 1
-
-if (b) {
-}
-a = 2; // wrong
-
-3)
-if (a) {
- if (b) // correct
-
-4)
-b = 2;
-
-if (a) { // correct
-
-}
-
-b = 3;
-
-The only exception to this rule applies when a variable is being checked for
-errors as such:
-
-err = stat(filename, &st);
-if (err || !S_ISDIR(st.st_mode))
- return;
-
-M2: Multiple line comment
-=========================
-
-If your comment has more than one line, please start it from the second line.
-
-Example:
-/*
- * first line comment // correct
- * ...
- * last line comment
- */
-
-
-M3: Space before and after operator
-===================================
-
-There should be a space before and after each operator.
-
-Example:
-a + b; // correct
-
-
-M4: Wrap long lines
-===================
-
-If your condition in if, while, for statement or a function declaration is too
-long to fit in one line, the new line needs to be indented not aligned with the
-body.
-
-Example:
-1)
-if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
- !(adapter->current_settings & MGMT_SETTING_SSP)) // wrong
-
-2)
-if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
- !(adapter->current_settings & MGMT_SETTING_SSP))
-
-3)
-void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
- btd_adapter_pin_cb_t cb) // wrong
-
-4)
-void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
- btd_adapter_pin_cb_t cb)
-
-The referred style for line wrapping is to indent as far as possible to the
-right without hitting the 80 columns limit.
-
-M5: Space when doing type casting
-=================================
-
-There should be a space between new type and variable.
-
-Example:
-1)
-a = (int *)b; // wrong
-2)
-a = (int *) b; // correct
-
-
-M6: Don't initialize variable unnecessarily
-===========================================
-
-When declaring a variable, try not to initialize it unless necessary.
-
-Example:
-int i = 1; // wrong
-
-for (i = 0; i < 3; i++) {
-}
-
-M7: Follow the order of include header elements
-===============================================
-
-When writing an include header the various elements should be in the following
-order:
- - #includes
- - forward declarations
- - #defines
- - enums
- - typedefs
- - function declarations and inline function definitions
-
-M8: Internal headers must not use include guards
-================================================
-
-Any time when creating a new header file with non-public API, that header
-must not contain include guards.
-
-M9: Naming of enums
-===================
-
-Enums must have a descriptive name. The enum type should be small caps and
-it should not be typedef-ed. Enum contents should be in CAPITAL letters and
-prefixed by the enum type name.
-
-Example:
-
-enum animal_type {
- ANIMAL_TYPE_FOUR_LEGS,
- ANIMAL_TYPE_EIGHT_LEGS,
- ANIMAL_TYPE_TWO_LEGS,
-};
-
-If the enum contents have values (e.g. from specification) the formatting
-should be as follows:
-
-enum animal_type {
- ANIMAL_TYPE_FOUR_LEGS = 4,
- ANIMAL_TYPE_EIGHT_LEGS = 8,
- ANIMAL_TYPE_TWO_LEGS = 2,
-};
-
-M10: Enum as switch variable
-============================
-
-If the variable of a switch is an enum, you must include all values in
-switch body even if providing default. This is enforced by compiler option
-enabling extra warning in such case. The reason for this is to ensure that if
-later on enum is modified and one forget to change the switch accordingly, the
-compiler will complain the new added type hasn't been handled.
-
-Example:
-
-enum animal_type {
- ANIMAL_TYPE_FOUR_LEGS = 4,
- ANIMAL_TYPE_EIGHT_LEGS = 8,
- ANIMAL_TYPE_TWO_LEGS = 2,
-};
-
-enum animal_type t;
-
-switch (t) { // OK
-case ANIMAL_TYPE_FOUR_LEGS:
- ...
- break;
-case ANIMAL_TYPE_EIGHT_LEGS:
- ...
- break;
-case ANIMAL_TYPE_TWO_LEGS:
- ...
- break;
-default:
- break;
-}
-
-switch (t) { // Wrong
-case ANIMAL_TYPE_FOUR_LEGS:
- ...
- break;
-case ANIMAL_TYPE_TWO_LEGS:
- ...
- break;
-default:
- break;
-}
-
-However if the enum comes from an external header file outside BlueZ, such as
-Android headers, we cannot make any assumption of how the enum is defined and
-this rule might not apply.
-
-M11: Always use parenthesis with sizeof
-=======================================
-
-The expression argument to the sizeof operator should always be in
-parenthesis, too.
-
-Example:
-1)
-memset(stuff, 0, sizeof(*stuff));
-
-2)
-memset(stuff, 0, sizeof *stuff); // Wrong
-
-M12: Use void if function has no parameters
-===========================================
-
-A function with no parameters must use void in the parameter list.
-
-Example:
-1)
-void foo(void)
-{
-}
-
-2)
-void foo() // Wrong
-{
-}
-
-O1: Try to avoid complex if body
-================================
-
-It's better not to have a complicated statement for if. You may judge its
-contrary condition and return | break | continue | goto ASAP.
-
-Example:
-1)
-if (device) { // worse
- memset(&eir_data, 0, sizeof(eir_data));
- if (eir_len > 0)
- eir_parse(&eir_data, ev->eir, eir_len);
- ...
-} else {
- error("Unable to get device object for %s", addr);
- return;
-}
-
-2)
-if (!device) {
- error("Unable to get device object for %s", addr);
- return;
-}
-
-memset(&eir_data, 0, sizeof(eir_data));
-if (eir_len > 0)
- eir_parse(&eir_data, ev->eir, eir_len);
-...
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [BlueZ v2 5/7] doc: Port sap-api.txt to RST
2026-01-20 17:18 [BlueZ v2 0/7] Port text docs to RST Bastien Nocera
` (3 preceding siblings ...)
2026-01-20 17:18 ` [BlueZ v2 4/7] doc: Port coding-style.txt " Bastien Nocera
@ 2026-01-20 17:18 ` Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 6/7] doc: Port maintainer-guidelines.txt " Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 7/7] doc: Port health-api.txt " Bastien Nocera
6 siblings, 0 replies; 10+ messages in thread
From: Bastien Nocera @ 2026-01-20 17:18 UTC (permalink / raw)
To: linux-bluetooth
---
Makefile.am | 8 ++++++--
doc/org.bluez.SimAccess.rst | 40 +++++++++++++++++++++++++++++++++++++
doc/sap-api.txt | 20 -------------------
3 files changed, 46 insertions(+), 22 deletions(-)
create mode 100644 doc/org.bluez.SimAccess.rst
delete mode 100644 doc/sap-api.txt
diff --git a/Makefile.am b/Makefile.am
index d80c1250a417..8396849831f1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -402,6 +402,8 @@ man_MANS += doc/org.bluez.Telephony.5 doc/org.bluez.Call.5
man_MANS += doc/org.bluez.ThermometerManager.5 \
doc/org.bluez.Thermometer.5 \
doc/org.bluez.ThermometerWatcher.5
+man_MANS += doc/org.bluez.SimAccess.5
+
endif
manual_pages += src/bluetoothd.8
manual_pages += doc/hci.7 doc/mgmt.7 doc/l2cap.7 doc/rfcomm.7 doc/sco.7 \
@@ -442,6 +444,7 @@ manual_pages += doc/org.bluez.Telephony.5 doc/org.bluez.Call.5
manual_pages += doc/org.bluez.ThermometerManager.5 \
doc/org.bluez.Thermometer.5 \
doc/org.bluez.ThermometerWatcher.5
+manual_pages += doc/org.bluez.SimAccess.5
EXTRA_DIST += src/genbuiltin src/bluetooth.conf \
src/main.conf profiles/network/network.conf \
@@ -484,8 +487,7 @@ EXTRA_DIST += doc/assigned-numbers.rst doc/supported-features.txt \
doc/test-runner.rst \
doc/settings-storage.txt
-EXTRA_DIST += doc/health-api.txt \
- doc/sap-api.txt
+EXTRA_DIST += doc/health-api.txt
EXTRA_DIST += doc/hci.rst doc/mgmt.rst doc/l2cap.rst doc/rfcomm.rst \
doc/sco.rst doc/iso.rst
@@ -532,6 +534,8 @@ EXTRA_DIST += doc/org.bluez.ThermometerManager.rst \
doc/org.bluez.Thermometer.rst \
doc/org.bluez.ThermometerWatcher.rst
+EXTRA_DIST += doc/org.bluez.SimAccess.rst
+
EXTRA_DIST += doc/pics-opp.txt doc/pixit-opp.txt \
doc/pts-opp.txt
diff --git a/doc/org.bluez.SimAccess.rst b/doc/org.bluez.SimAccess.rst
new file mode 100644
index 000000000000..ac86e7eb220c
--- /dev/null
+++ b/doc/org.bluez.SimAccess.rst
@@ -0,0 +1,40 @@
+===================
+org.bluez.SimAccess
+===================
+
+----------------------------------------
+BlueZ D-Bus Sim Access API documentation
+----------------------------------------
+
+:Version: BlueZ
+:Date: February 2011
+:Author: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
+:Manual section: 5
+:Manual group: Linux System Administration
+
+Interface
+=========
+
+:Service: org.bluez
+:Interface: org.bluez.SimAccess1
+:Object path: [variable prefix]/{hci0,hci1,...}
+
+Methods
+-------
+
+void Disconnect()
+`````````````````
+Disconnects SAP client from the server.
+
+Possible errors:
+
+:org.bluez.Error.Failed:
+
+Properties
+----------
+
+boolean Connected [readonly]
+````````````````````````````
+
+Indicates if SAP client is connected to the server.
+
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
deleted file mode 100644
index b28c4e305964..000000000000
--- a/doc/sap-api.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-BlueZ D-Bus Sim Access API description
-**************************************
-
-
-Sim Access Profile hierarchy
-============================
-
-Service org.bluez
-Interface org.bluez.SimAccess1
-Object path [variable prefix]/{hci0,hci1,...}
-
-Methods void Disconnect()
-
- Disconnects SAP client from the server.
-
- Possible errors: org.bluez.Error.Failed
-
-Properties boolean Connected [readonly]
-
- Indicates if SAP client is connected to the server.
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [BlueZ v2 6/7] doc: Port maintainer-guidelines.txt to RST
2026-01-20 17:18 [BlueZ v2 0/7] Port text docs to RST Bastien Nocera
` (4 preceding siblings ...)
2026-01-20 17:18 ` [BlueZ v2 5/7] doc: Port sap-api.txt " Bastien Nocera
@ 2026-01-20 17:18 ` Bastien Nocera
2026-01-20 17:18 ` [BlueZ v2 7/7] doc: Port health-api.txt " Bastien Nocera
6 siblings, 0 replies; 10+ messages in thread
From: Bastien Nocera @ 2026-01-20 17:18 UTC (permalink / raw)
To: linux-bluetooth
---
...idelines.txt => maintainer-guidelines.rst} | 61 +++++++++++--------
1 file changed, 35 insertions(+), 26 deletions(-)
rename doc/{maintainer-guidelines.txt => maintainer-guidelines.rst} (65%)
diff --git a/doc/maintainer-guidelines.txt b/doc/maintainer-guidelines.rst
similarity index 65%
rename from doc/maintainer-guidelines.txt
rename to doc/maintainer-guidelines.rst
index b875f008258b..a6e756b81c51 100644
--- a/doc/maintainer-guidelines.txt
+++ b/doc/maintainer-guidelines.rst
@@ -1,25 +1,28 @@
+=====================
Maintainer guidelines
-*********************
+=====================
This document is intended for the maintainers of the BlueZ project. It
serves as basic guidelines for handling patch review and commit access.
Rule 1: Keep the GIT tree clean and linear
-==========================================
+------------------------------------------
-The bluetooth.git, bluetooth-next.git and bluez.git trees are not your
+The ``bluetooth.git``, ``bluetooth-next.git`` and ``bluez.git`` trees are not your
private playground. The history is meant to be clean and linear.
- - NO merges
- - NO branches
- - NO tags
+- NO merges
+- NO branches
+- NO tags
If anyone needs testing or work on a feature, clone the tree and do
it in your own copy. The master trees are off limits.
One advise to avoid any accidental errors in this area to set proper
-options in global ~/.gitconfig or local .git/config files.
+options in global ``~/.gitconfig`` or local ``.git/config`` files.
+
+.. code-block::
[merge]
ff = only
@@ -29,7 +32,7 @@ in doubt ask one of the seasoned maintainers.
Rule 2: Enforce clean commit messages
-=====================================
+-------------------------------------
The commit messages are required to be clean and follow style guidelines
to be consistent.
@@ -45,20 +48,22 @@ job to ensure we get proper firstname lastname <email> authorship.
It is also important that the committer itself uses a valid name and
email address when committing patches. So ensure that either the
-global ~/.gitconfig or local .git/config provides proper values.
+global ``~/.gitconfig`` or local ``.git/config`` provides proper values.
+
+.. code-block::
[user]
name = Peter Mustermann
email = peter@mustermann.de
-Commit messages for bluez.git shall not contain Signed-off-by
+Commit messages for ``bluez.git`` shall not contain ``Signed-off-by``
signatures. They are not used in userspace and with that it is the
maintainers job to ensure they do not get committed to the repository.
-For bluetooth.git and bluetooth-next.git The Signed-off-by process is
-used and the signatures are required.
+For ``bluetooth.git`` and ``bluetooth-next.git``, the ``Signed-off-by``
+process is used and the signatures are required.
-Tags like Change-Id generated from Gerrit are never acceptable. It is
+Tags like ``Change-Id`` generated from Gerrit are never acceptable. It is
the maintainers job to ensure that these are not committed into the
repositories.
@@ -67,48 +72,52 @@ reversed. If in doubt ask one of the seasoned maintainers.
Rule 3: Enforce correct coding style
-====================================
+------------------------------------
The coding style follows roughly the kernel coding style with any
-exceptions documented in doc/coding-style.txt.
+exceptions documented in :doc:`coding-style <coding-style>`.
To ensure trivial white-space errors don't get committed, have the
-following in your .gitconfig:
+following in your ``.gitconfig``:
+
+.. code-block::
[apply]
whitespace = error
It can also be helpful to use the checkpatch.pl script coming with the
Linux kernel to do some automated checking. Adding the following to your
-.git/hooks/pre-commit and .git/hooks/pre-applypatch is a simple way to
+``.git/hooks/pre-commit`` and ``.git/hooks/pre-applypatch`` is a simple way to
do this:
+.. code-block::
exec git diff --cached | ~/src/linux/scripts/checkpatch.pl -q \
--no-tree --no-signoff --show-types \
--ignore CAMELCASE,NEW_TYPEDEFS,INITIALISED_STATIC -
-The above assumes that a kernel tree resides in ~/src/linux/.
+The above assumes that a kernel tree resides in ``~/src/linux/``.
Rule 4: Pay extra attention to adding new files to the tree
-===========================================================
+-----------------------------------------------------------
New files that are added to the tree require several things to be
verified first:
- - Check that the names are acceptable with other maintainers
- - Ensure that the file modes are correct
- - Verify that the license & copyright headers are correct
- - If the file is supposed to be part of the release tarball,
- make sure that it gets picked up by 'make dist' (particularly
- important for documentation or other files that are not code)
+- Check that the names are acceptable with other maintainers
+- Ensure that the file modes are correct
+- Verify that the license & copyright headers are correct
+- If the file is supposed to be part of the release tarball,
+ make sure that it gets picked up by 'make dist' (particularly
+ important for documentation or other files that are not code)
Rule 5: Keep the mailing list in sync with the commit process
-=============================================================
+-------------------------------------------------------------
When applying patches, be sure to send a response to the mailing list as
soon as the code has been pushed to the upstream tree. Usually this
means one email per patch, however patch-sets may only have one response
covering the entire set. If applying a subset of a patch-set clearly
state what was applied in your response.
+
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [BlueZ v2 7/7] doc: Port health-api.txt to RST
2026-01-20 17:18 [BlueZ v2 0/7] Port text docs to RST Bastien Nocera
` (5 preceding siblings ...)
2026-01-20 17:18 ` [BlueZ v2 6/7] doc: Port maintainer-guidelines.txt " Bastien Nocera
@ 2026-01-20 17:18 ` Bastien Nocera
6 siblings, 0 replies; 10+ messages in thread
From: Bastien Nocera @ 2026-01-20 17:18 UTC (permalink / raw)
To: linux-bluetooth
---
Makefile.am | 12 ++-
doc/health-api.txt | 152 --------------------------------
doc/org.bluez.HealthChannel.rst | 72 +++++++++++++++
doc/org.bluez.HealthDevice.rst | 94 ++++++++++++++++++++
doc/org.bluez.HealthManager.rst | 68 ++++++++++++++
5 files changed, 244 insertions(+), 154 deletions(-)
delete mode 100644 doc/health-api.txt
create mode 100644 doc/org.bluez.HealthChannel.rst
create mode 100644 doc/org.bluez.HealthDevice.rst
create mode 100644 doc/org.bluez.HealthManager.rst
diff --git a/Makefile.am b/Makefile.am
index 8396849831f1..938b127cd052 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -403,6 +403,9 @@ man_MANS += doc/org.bluez.ThermometerManager.5 \
doc/org.bluez.Thermometer.5 \
doc/org.bluez.ThermometerWatcher.5
man_MANS += doc/org.bluez.SimAccess.5
+man_MANS += doc/org.bluez.HealthChannel.5 \
+ doc/org.bluez.HealthDevice.5 \
+ doc/org.bluez.HealthManager.5
endif
manual_pages += src/bluetoothd.8
@@ -445,6 +448,9 @@ manual_pages += doc/org.bluez.ThermometerManager.5 \
doc/org.bluez.Thermometer.5 \
doc/org.bluez.ThermometerWatcher.5
manual_pages += doc/org.bluez.SimAccess.5
+manual_pages += doc/org.bluez.HealthChannel.5 \
+ doc/org.bluez.HealthDevice.5 \
+ doc/org.bluez.HealthManager.5
EXTRA_DIST += src/genbuiltin src/bluetooth.conf \
src/main.conf profiles/network/network.conf \
@@ -487,8 +493,6 @@ EXTRA_DIST += doc/assigned-numbers.rst doc/supported-features.txt \
doc/test-runner.rst \
doc/settings-storage.txt
-EXTRA_DIST += doc/health-api.txt
-
EXTRA_DIST += doc/hci.rst doc/mgmt.rst doc/l2cap.rst doc/rfcomm.rst \
doc/sco.rst doc/iso.rst
@@ -536,6 +540,10 @@ EXTRA_DIST += doc/org.bluez.ThermometerManager.rst \
EXTRA_DIST += doc/org.bluez.SimAccess.rst
+EXTRA_DIST += doc/org.bluez.HealthChannel.rst \
+ doc/org.bluez.HealthDevice.rst \
+ doc/org.bluez.HealthManager.rst
+
EXTRA_DIST += doc/pics-opp.txt doc/pixit-opp.txt \
doc/pts-opp.txt
diff --git a/doc/health-api.txt b/doc/health-api.txt
deleted file mode 100644
index 2c48ff20449d..000000000000
--- a/doc/health-api.txt
+++ /dev/null
@@ -1,152 +0,0 @@
-BlueZ D-Bus Health API description
-**********************************
-
-
-HealthManager hierarchy
-=======================
-
-Service org.bluez
-Interface org.bluez.HealthManager1
-Object path /org/bluez/
-
-Methods object CreateApplication(dict config)
-
- Returns the path of the new registered application.
- Application will be closed by the call or implicitly
- when the programs leaves the bus.
-
- config:
- uint16 DataType:
-
- Mandatory
-
- string Role:
-
- Mandatory. Possible values: "source",
- "sink"
-
- string Description:
-
- Optional
-
- ChannelType:
-
- Optional, just for sources. Possible
- values: "reliable", "streaming"
-
- Possible Errors: org.bluez.Error.InvalidArguments
-
- void DestroyApplication(object application)
-
- Closes the HDP application identified by the object
- path. Also application will be closed if the process
- that started it leaves the bus. Only the creator of the
- application will be able to destroy it.
-
- Possible errors: org.bluez.Error.InvalidArguments
- org.bluez.Error.NotFound
- org.bluez.Error.NotAllowed
-
-
-HealthDevice hierarchy
-======================
-
-Service org.bluez
-Interface org.bluez.HealthDevice1
-Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
-
-Methods boolean Echo()
-
- Sends an echo petition to the remote service. Returns
- True if response matches with the buffer sent. If some
- error is detected False value is returned.
-
- Possible errors: org.bluez.Error.InvalidArguments
- org.bluez.Error.OutOfRange
-
- object CreateChannel(object application, string configuration)
-
- Creates a new data channel. The configuration should
- indicate the channel quality of service using one of
- this values "reliable", "streaming", "any".
-
- Returns the object path that identifies the data
- channel that is already connected.
-
- Possible errors: org.bluez.Error.InvalidArguments
- org.bluez.Error.HealthError
-
- void DestroyChannel(object channel)
-
- Destroys the data channel object. Only the creator of
- the channel or the creator of the HealthApplication
- that received the data channel will be able to destroy
- it.
-
- Possible errors: org.bluez.Error.InvalidArguments
- org.bluez.Error.NotFound
- org.bluez.Error.NotAllowed
-
-Signals void ChannelConnected(object channel)
-
- This signal is launched when a new data channel is
- created or when a known data channel is reconnected.
-
- void ChannelDeleted(object channel)
-
- This signal is launched when a data channel is deleted.
-
- After this signal the data channel path will not be
- valid and its path can be reused for future data
- channels.
-
-Properties object MainChannel [readonly]
-
- The first reliable channel opened. It is needed by
- upper applications in order to send specific protocol
- data units. The first reliable can change after a
- reconnection.
-
-
-HealthChannel hierarchy
-=======================
-
-Service org.bluez
-Interface org.bluez.HealthChannel1
-Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/chanZZZ
-
-Only the process that created the data channel or the creator of the
-HealthApplication that received it will be able to call these methods.
-
-Methods fd Acquire()
-
- Returns the file descriptor for this data channel. If
- the data channel is not connected it will also
- reconnect.
-
- Possible Errors: org.bluez.Error.NotConnected
- org.bluez.Error.NotAllowed
-
- void Release()
-
- Releases the fd. Application should also need to
- close() it.
-
- Possible Errors: org.bluez.Error.NotAcquired
- org.bluez.Error.NotAllowed
-
-Properties string Type [readonly]
-
- The quality of service of the data channel. ("reliable"
- or "streaming")
-
- object Device [readonly]
-
- Identifies the Remote Device that is connected with.
- Maps with a HealthDevice object.
-
- object Application [readonly]
-
- Identifies the HealthApplication to which this channel
- is related to (which indirectly defines its role and
- data type).
diff --git a/doc/org.bluez.HealthChannel.rst b/doc/org.bluez.HealthChannel.rst
new file mode 100644
index 000000000000..f91a1ff94dc1
--- /dev/null
+++ b/doc/org.bluez.HealthChannel.rst
@@ -0,0 +1,72 @@
+=======================
+org.bluez.HealthChannel
+=======================
+
+----------------------------------
+BlueZ D-Bus Health API description
+----------------------------------
+
+:Version: BlueZ
+:Date: July 2010
+:Author: José Antonio Santos Cadenas <santoscadenas@gmail.com>
+:Manual section: 5
+:Manual group: Linux System Administration
+
+Interface
+=========
+
+:Service: org.bluez
+:Interface: org.bluez.HealthChannel1
+:Object path: [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/chanZZZ
+
+Only the process that created the data channel or the creator of the
+HealthApplication that received it will be able to call these methods.
+
+Methods
+-------
+
+fd Acquire()
+````````````
+
+Returns the file descriptor for this data channel. If
+the data channel is not connected it will also
+reconnect.
+
+Possible Errors:
+
+:org.bluez.Error.NotConnected:
+:org.bluez.Error.NotAllowed:
+
+void Release()
+``````````````
+
+Releases the fd. Application should also need to
+close() it.
+
+Possible Errors:
+
+:org.bluez.Error.NotAcquired:
+:org.bluez.Error.NotAllowed:
+
+Properties
+----------
+
+string Type [readonly]
+``````````````````````
+
+The quality of service of the data channel. ("reliable"
+or "streaming")
+
+object Device [readonly]
+````````````````````````
+
+Identifies the Remote Device that is connected with.
+Maps with a HealthDevice object.
+
+object Application [readonly]
+`````````````````````````````
+
+Identifies the HealthApplication to which this channel
+is related to (which indirectly defines its role and
+data type).
+
diff --git a/doc/org.bluez.HealthDevice.rst b/doc/org.bluez.HealthDevice.rst
new file mode 100644
index 000000000000..568f854b7768
--- /dev/null
+++ b/doc/org.bluez.HealthDevice.rst
@@ -0,0 +1,94 @@
+======================
+org.bluez.HealthDevice
+======================
+
+------------------------------------
+BlueZ D-Bus Health API documentation
+------------------------------------
+
+:Version: BlueZ
+:Date: July 2010
+:Author: José Antonio Santos Cadenas <santoscadenas@gmail.com>
+:Manual section: 5
+:Manual group: Linux System Administration
+
+Interface
+=========
+
+:Service: org.bluez
+:Interface: org.bluez.HealthDevice1
+:Object path: [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+Methods
+-------
+
+boolean Echo()
+``````````````
+
+Sends an echo petition to the remote service. Returns
+True if response matches with the buffer sent. If some
+error is detected False value is returned.
+
+Possible errors:
+
+:org.bluez.Error.InvalidArguments:
+:org.bluez.Error.OutOfRange:
+
+object CreateChannel(object application, string configuration)
+``````````````````````````````````````````````````````````````
+
+Creates a new data channel. The configuration should
+indicate the channel quality of service using one of
+this values "reliable", "streaming", "any".
+
+Returns the object path that identifies the data
+channel that is already connected.
+
+Possible errors:
+
+:org.bluez.Error.InvalidArguments:
+:org.bluez.Error.HealthError:
+
+void DestroyChannel(object channel)
+```````````````````````````````````
+
+Destroys the data channel object. Only the creator of
+the channel or the creator of the HealthApplication
+that received the data channel will be able to destroy
+it.
+
+Possible errors:
+
+:org.bluez.Error.InvalidArguments:
+:org.bluez.Error.NotFound:
+:org.bluez.Error.NotAllowed:
+
+Signals
+-------
+
+void ChannelConnected(object channel)
+`````````````````````````````````````
+
+This signal is launched when a new data channel is
+created or when a known data channel is reconnected.
+
+void ChannelDeleted(object channel)
+```````````````````````````````````
+
+This signal is launched when a data channel is deleted.
+
+After this signal the data channel path will not be
+valid and its path can be reused for future data
+channels.
+
+Properties
+----------
+
+object MainChannel [readonly]
+`````````````````````````````
+
+The first reliable channel opened. It is needed by
+upper applications in order to send specific protocol
+data units. The first reliable can change after a
+reconnection.
+
diff --git a/doc/org.bluez.HealthManager.rst b/doc/org.bluez.HealthManager.rst
new file mode 100644
index 000000000000..1eaaf7935eeb
--- /dev/null
+++ b/doc/org.bluez.HealthManager.rst
@@ -0,0 +1,68 @@
+=======================
+org.bluez.HealthManager
+=======================
+
+------------------------------------
+BlueZ D-Bus Health API documentation
+------------------------------------
+
+:Version: BlueZ
+:Date: July 2010
+:Author: José Antonio Santos Cadenas <santoscadenas@gmail.com>
+:Manual section: 5
+:Manual group: Linux System Administration
+
+Interface
+=========
+
+:Service: org.bluez
+:Interface: org.bluez.HealthManager1
+:Object path: /org/bluez/
+
+Methods
+-------
+
+object CreateApplication(dict config)
+`````````````````````````````````````
+
+Returns the path of the new registered application.
+Application will be closed by the call or implicitly
+when the programs leaves the bus.
+
+Possible config value:
+
+:uint16 DataType:
+
+ Mandatory
+
+:string Role:
+
+ Mandatory. Possible values: "source", "sink"
+
+:string Description:
+
+ Optional
+
+:ChannelType:
+
+ Optional, just for sources. Possible
+ values: "reliable", "streaming"
+
+Possible Errors:
+
+:org.bluez.Error.InvalidArguments:
+
+void DestroyApplication(object application)
+```````````````````````````````````````````
+
+Closes the HDP application identified by the object
+path. Also application will be closed if the process
+that started it leaves the bus. Only the creator of the
+application will be able to destroy it.
+
+Possible errors:
+
+:org.bluez.Error.InvalidArguments:
+:org.bluez.Error.NotFound:
+:org.bluez.Error.NotAllowed:
+
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread