Return-Path: Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] gatt-server: Implement NegotiatedMTU property on Device1 From: Jonah Petri In-Reply-To: <1A61FCA4-F476-456F-AAAE-3C7753885BD4@holtmann.org> Date: Mon, 17 Jul 2017 16:50:26 -0400 Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" Message-Id: References: <8E72D5C7-FA44-4B06-82D7-2FCB22E26778@holtmann.org> <1A61FCA4-F476-456F-AAAE-3C7753885BD4@holtmann.org> To: Marcel Holtmann List-ID: Hi Marcel, > On Jul 17, 2017, at 2:08 PM, Marcel Holtmann = wrote: >=20 >>> I think that exposing max payload is a better idea. >>=20 >> I am fine with the revised naming, and revising the exposed device = attribute to represent the max ATT payload. However, how can a dbus = client know whether the MTU negotiation has occurred or not? The point = of the patch is to allow for clients to take advantage of a larger = negotiated MTU. >>=20 >> The negotiation of the MTU can be a significant event to the client = interacting via dbus, so how should the completion of that negotiation = be exposed, if not via an attribute as I proposed above? Some boolean = "MaxPayloadNegotiationCompleted" method? >=20 > there will be PropertiesChanged signal once the MTU has been altered. = Otherwise it will start out with 23 in case of LE or the minimum of = whatever L2CAP has configured for BR/EDR. We do the same for RFCOMM btw. = where it takes the minimum value from the two MTUs. >=20 I understand. However, there is no way for a dbus client to tell the = difference between these two scenarios: 1) The MTU has been negotiated to 23 (in the case of LE) 2) The MTU negotiation has not been completed I expect many clients making use of this information will want to wait = until the MTU negotiation is complete, and then begin normal operation. = A single attribute representing the current MTU seems to not be = sufficient to implement such a dbus client. Jonah=