From: Marcel Holtmann <marcel@holtmann.org>
To: Nick Pelly <npelly@google.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: What is the motivation for conn->power_save
Date: Fri, 13 Nov 2009 04:14:58 +0100 [thread overview]
Message-ID: <1258082098.7715.7.camel@violet> (raw)
In-Reply-To: <35c90d960911121639o8b0b0bfxde880af69adc9f95@mail.gmail.com>
Hi Nick,
> If I understand correctly, conn->power_save prevents the host stack
> from requesting active mode if it was not the host stack that
> requested sniff mode.
>
> I don't understand the motivation for this. If we have ACL data to
> send, then it seems like a good idea for the host stack to explicitly
> request active mode, regardless of the reason that we entered sniff
> mode.
>
> We want to enter active mode more aggressively when setting up SCO
> connections, to avoid a 5 second delay with certain sniff modes. But
> the conn->power_save code is getting in the way and doesn't appear to
> be useful in the first place.
we have discussed this a few times. And if you lock through the code
history then you see that initially we just took devices out of sniff
mode if we had to send data. However with HID devices this falls flat on
its face. They need to stay in control of sniff mode if they initiated
it. Some of them crash and others just drain the battery. With sniff
mode you can send small amounts of data even while in sniff and for HID
that is sometimes used. So the remote side better not interfere.
What we really need is a socket option where we can control this on a
per socket basis if we take devices out of sniff mode. And one extra
case might be when we try to establish a SCO channel, because then it is
clearly not an HID device. However even A2DP has this sort of problems
sometimes where the stream setup takes time.
Not sure if we have to make SCO setup special. The only reason would be
if there is a case where we don't get an AT command before SCO needs to
be established.
Regards
Marcel
next prev parent reply other threads:[~2009-11-13 3:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-13 0:39 What is the motivation for conn->power_save Nick Pelly
2009-11-13 3:14 ` Marcel Holtmann [this message]
2009-11-13 3:31 ` Nick Pelly
2009-11-13 3:52 ` Marcel Holtmann
2009-11-16 18:55 ` Nick Pelly
2010-02-03 2:15 ` Nick Pelly
2010-02-03 20:20 ` Marcel Holtmann
2010-02-04 0:59 ` Nick Pelly
2010-02-04 3:13 ` Marcel Holtmann
[not found] ` <35c90d960911131445w16076c70sa0473e9b459d7d15@mail.gmail.com>
2010-01-13 4:46 ` Nick Pelly
2010-01-13 7:04 ` Marcel Holtmann
2010-07-08 15:07 ` Andrei Emeltchenko
2010-07-08 18:37 ` Nick Pelly
2010-08-03 9:31 ` Liang Bao
2010-08-03 16:16 ` Nick Pelly
2010-08-03 16:20 ` Nick Pelly
2010-08-03 9:32 ` Liang Bao
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=1258082098.7715.7.camel@violet \
--to=marcel@holtmann.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=npelly@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox