All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Anderson Briglia <anderson.briglia@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [RFC 1/3] Bluetooth: Implement Read RSSI command
Date: Wed, 13 Jul 2011 21:47:05 +0200	[thread overview]
Message-ID: <1310586426.21109.100.camel@aeonflux> (raw)
In-Reply-To: <CALJ2SBL=Fdcmrbrs69pQybXxMq1yh4=Gzmx4Xa32_qnFwDe-YA@mail.gmail.com>

Hi Anderson,

> >> This patch implements helper functions to make Read RSSI command
> >> interceptable by MGMT Interface. It adds a new wrapper in HCI layer and
> >> add a hook to call mgmt_read_rssi_complete when MGMT Interface has been
> >> loaded.
> >>
> >> Read RSSI command is defined on Part E, section 7.5.4 of Bluetooth 4.0
> >> Spec.
> >
> > I think that I mentioned this before. This is not something I like to
> > see at all. 1:1 copies of HCI commands is pointless.
> >
> > If you need RSSI results, then something like proper interval and
> > thresholds should be supported. Also with future Bluetooth SIG work on
> > having controller driven notifications in this area.
> 
> Note that even the RSSI and TX Power are implemented, it is not
> possible to userspace request a RSSI or TX Power actively. If
> userspace wants to receive RSSI and TX Power from the kernel, it must
> add to the "monitored commands" and wait for the responses. Read RSSI
> and TX Power Level are not being parsed on mgmt_control().
> Maybe I should change the commit message of this patch and the next one.
> 
> New Management commands were implemented in the last RFC patch to
> monitor selected commands.

no matter what, this needs to be done future proof in conjunction with
where the Bluetooth SIG is going for the controller driven notifications
of RSSI changes.

With older controllers we just have to emulate the behavior via a simple
poll mechanism.

However such monitored commands things seems like a hack as well. Please
use proper interfaces for threshold and interval values. Otherwise this
is all pointless. And you just wake up userspace for no real reason. The
plan is to get away from pointless userspace wakeups.

Regards

Marcel



  reply	other threads:[~2011-07-13 19:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-13 14:06 [RFC 1/3] Bluetooth: Implement Read RSSI command anderson.briglia
2011-07-13 18:12 ` Marcel Holtmann
2011-07-13 18:27   ` Anderson Briglia
2011-07-13 19:47     ` Marcel Holtmann [this message]
2011-07-20 14:48       ` Claudio Takahasi

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1310586426.21109.100.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=anderson.briglia@openbossa.org \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.