Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp314297ybk; Tue, 19 May 2020 23:51:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw2KykPTQ13fLdALuuU+cF8qDHz7+IS6FmaUOZJgNwJPtKU0J0fFxA5wcCoNihMBQFOnsne X-Received: by 2002:aa7:d596:: with SMTP id r22mr2122056edq.379.1589957460847; Tue, 19 May 2020 23:51:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589957460; cv=none; d=google.com; s=arc-20160816; b=XjYL//9EbN6dzqtu5T3NMV7EDOLpg4zRHgT1B3IfxXjnDwNmBvBy/xf5WpVQupcHhn pvODajBQpwggTRvwquIu4BcYJF5SYDpvf8tCkPpsJ+wFVFuO0brUe5Kj5kvJMA4WIWJw sIuED++bFV7JMrXt2up3tOX8lwRAvEm0G5yqgSJ6FZhXPVt7TkycGWZEdFyiaYiDqz5d AV3u1EPSDfOUOft1Ye2JL5ox1U3LaDhXWWciN7oBLmw6YtNoNook5zavGdKjB8uEQp5/ ZInXEzbmzgufAVuN71lpjpsudVlSl4ibdlJ7Tt5gDAYmXvVeXfsgjt+noON31KAgvwaM 4PRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=Wlbq19F4Scn7c2xrIh4S8iFrylHkva0hJOEU5C8cLLI=; b=foeROboHI1FHi2cy4X5clY7h1G+flTSB+2VhxtojLrLiY2S8RQO8PDGC61hRyU1xyi CGqKice6Wb7Lfzxb598dJaCC75JUvFeng2FnKwBjCCqCwYiEdlgLQtzOqQ8gAh0/AIVX wzHt2BANedQyHMNC+FFYYAym66NSufA3iNgahIa/dpPSH2HTzfiBOccg8okBi44b+DvY pk2VKQLNKOQ6fQ57+x2uzOC+vXNehlgm/qQlS1E2wWSbV392Uu1HjtDBkj7L3S1grbE0 6xP1Jldiq0tGhF8oXBm2+6FfUGWxsbHOARbEkMMqWld7RGJoLDgcCNSAC1jzSQ4kuubB h6OA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w8si962153edv.530.2020.05.19.23.50.18; Tue, 19 May 2020 23:51:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726425AbgETGuM convert rfc822-to-8bit (ORCPT + 99 others); Wed, 20 May 2020 02:50:12 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:41991 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725998AbgETGuL (ORCPT ); Wed, 20 May 2020 02:50:11 -0400 Received: from [192.168.1.91] (p4fefc5a7.dip0.t-ipconnect.de [79.239.197.167]) by mail.holtmann.org (Postfix) with ESMTPSA id D95B9CED03; Wed, 20 May 2020 08:59:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [PATCH] device: Add device type property From: Marcel Holtmann In-Reply-To: Date: Wed, 20 May 2020 08:49:40 +0200 Cc: Bluez mailing list , Eric Caruso Content-Transfer-Encoding: 8BIT Message-Id: <6C21A2C1-6224-4FB6-B483-27B1C89864BE@holtmann.org> References: <20200401221320.12105-1-sonnysasaka@chromium.org> <6A574E50-BBF3-4967-9C93-6F4B6DAFB47D@holtmann.org> <68C2E4A8-29E0-44D8-9D2F-F4E2354DE419@holtmann.org> To: Sonny Sasaka X-Mailer: Apple Mail (2.3608.80.23.2.2) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Sonny, > After giving it more thought, I would like to propose that this > additional property corresponds with Device Type as defined in Generic > Access Profile: > > As stated in Bluetooth Core Specification Version 5.2, Vol 3, Part C > (Generic Access Profile): > This profile defines three device types based on the supported Core > Configurations as defined in [Vol 0] Part B, Section 3.1. The device > types are shown in Table 1.1: > * BR/EDR > * LE only > * BR/EDR/LE > > Therefore, to be as close to the spec as possible, I propose that the > property be named GAPDeviceType, and the possible values be "br/edr", > "le-only", "br/edr/le". > > What do you think? Thanks for reviewing this proposal! maybe we should do SupportedTypes = [“le”, “bredr”, “hs”] since that also maps to what we expose in MGMT. And then add a Types = [ .. ] property with the same values. I don’t like using GAP in property names and repeating Device is also not needed since we are already in the Device interface. In addition I have a reservation with spec naming in this area since it has changed over time and there is a chance it might change again in future specs when new features come along. If you know the supported types of the hardware and the selected types, you can easily get to the GAP Device Type from the spec if you actually want to show it. If you wanted to, you could make the Types property writeable as well and users could change their device type via D-Bus. Regards Marcel