Linux-Bluetooth Archive on
 help / Atom feed
From: Emil Lenngren <>
To: Bluez mailing list <>
Subject: Flag for specifying write type to WriteValue in gatt-api.
Date: Thu, 31 Jan 2019 17:15:35 +0100
Message-ID: <> (raw)


I was looking through the quite lengthy discussion at on the
issue that in Web-Bluetooth, only a single "write value" API is
available, causing Web-Bluetooth to decide on its own if Write With
Response or Write Without Response should be used, in case both are
supported by the characteristic.

But in the Bluetooth spec about Write Without Response:

"This sub-procedure is used to write a Characteristic Value to a
server when the client knows the Characteristic Value Handle and the
client does not need an acknowledgement that the write was
successfully performed."

Basically, it says it's up to the client/application to decide if an
acknowledgement is needed or not, and hence it's the app that should
decide if Write With or Without Response should be used. The "client"
can't mean a bluetooth stack here since it can of course not know if
an acknowledgement is needed or not.

I noticed that according to gatt-api.txt, BlueZ has the same
limitation in the WriteValue method, in that the stack chooses the
write type "arbitrarily" if both write types are supported (or really
the Write With Response is chosen, which might cause unwanted
latency). Therefore I suggest that an option should be added to the
WriteValue method, for example "write-without-response" (bool) to
force Write Without Response.

Note how iOS has a write type parameter to the write method, and
Android has a write type property you set before you execute the

I see that it might be possible to achieve the same result with
AcquireWrite -> write to socket -> release but that wouldn't be a good
solution for bluetooth stacks built on top of BlueZ that would like to
differentiate between the two write types (such as Web-Bluetooth)
since AcquireWrite can fail, for example if two apps write the value
at the same time (I guess the lock is exclusive?). It also seems like
unnecessary overhead to open and close sockets.


             reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 16:15 Emil Lenngren [this message]
2019-01-31 17:03 ` Luiz Augusto von Dentz
2019-01-31 17:46   ` Emil Lenngren
2019-01-31 17:55     ` Luiz Augusto von Dentz
2019-01-31 18:09       ` Emil Lenngren

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Bluetooth Archive on

Archives are clonable:
	git clone --mirror linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ \
	public-inbox-index linux-bluetooth

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox