Hi Mat, On Mon, Jan 16, 2012, Mat Martineau wrote: > >>>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. If something like that is really needed then I think some sort of a socket option might make more sense, i.e. the application could call getsockopt (or some higher level wrapper like BtIO) to figure this out. In any case it's not enough for the remote device to support EDR if the local device isn't capable of it. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
