Return-Path: Date: Mon, 16 Jan 2012 08:26:30 -0800 (PST) From: Mat Martineau To: Johan Hedberg cc: Marcel Holtmann , linux-bluetooth@vger.kernel.org, skrovvid@codeaurora.org Subject: Re: As long as we're adding to the Device Connected mgmt event... In-Reply-To: <1326696332.6454.272.camel@aeonflux> Message-ID: References: <20120115110354.GA12977@x220.P-661HNU-F1> <1326696332.6454.272.camel@aeonflux> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Johan - On Mon, 16 Jan 2012, Marcel Holtmann wrote: > Hi Mat, > >>> I noticed your recent bluez.git commit that modifies the Device >>> Connected event. Would it also make sense to add the results of the >>> READ_REMOTE_VERSION command? >>> >>> lmp_ver >>> manufacturer >>> lmp_subver >>> >>> This information was captured in bluetoothd when using hciops, but >>> has so far been missing with mgmtops. >> >> Do you have a real use-case for it? It'd expect that info to be at most >> useful to the kernel side but not so much for user-space. FWIW, we came >> to the conclusion with Marcel that a better approach with this >> mgmt_ev_device_connected is to encode both the class and the name as an >> EIR blob. We'll also do that for the class that's currently as a >> separate parameter in mgmt_ev_device_found. This simplifies the >> structure of both events and also allows for future extensibility. > > in addition, these information are purely debugging details and I think > it would be better to use sysfs or debugfs for it. The use case involves checking the remote LMP version to figure out if the remote device supports EDR, to get a rough estimate of available bandwidth. Lower bandwidth devices can then use different settings at the profile or application layer. -- Mat Martineau Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum