From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: Bluetooth HF role
Date: Sat, 20 Aug 2011 21:13:47 -0500 [thread overview]
Message-ID: <4E5069DB.4020006@gmail.com> (raw)
In-Reply-To: <4E5640F2.5010302@bmw-carit.de>
[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]
Hi Mikel,
On 08/25/2011 07:32 AM, Mikel Astiz wrote:
> Hi Denis,
>
> On 08/20/2011 11:00 AM, Denis Kenzior wrote:
>> Hi Mikel,
>>
>> On 08/24/2011 10:28 AM, Mikel Astiz wrote:
>>> Hi all,
>>>
>>> I'm trying to understand the features currently supported by oFono
>>> regarding the handsfree role in Bluetooth/HFP. My first impression
>>> looking at the source code is that some HFP functionality might be
>>> missing, but I would rather have your confirmation.
>>>
>> Correct, in general only features that map 1:1 to existing APIs are
>> exposed. So that means network registration, voicecalls and call-volume
>> interfaces.
>>
>>> Some examples I've found so far are the following:
>>> 1. Response and hold (AT+BTRH=0)
>>> 2. Redial last number (AT+BLDN)
>>> 3. Retrieval of supported Bluetooth features for a certain modem/device
>>> (AT+BRSF)
>>>
>> BRSF is supported and used internally, but the information is not
>> exposed over D-Bus.
>>
>>> Could you clarify which (if any) of these features are currently
>>> supported by oFono?
>> Bluetooth specific features are not supported yet, these will require a
>> separate atom. Roughly this means anything starting with +B.. including:
>> - +BINP
>> - +BLDN
>> - +BVRA
>> - +NREC
>> - +BSIR
>> - +BTRH
>>
>>> In general, is there any documented list of unsupported features?
>>>
>> In general the TODO list is your best source of readily available
>> information. In the case of HFP HF, there is no such documentation ;)
>> Patches adding tasks to the TODO list to support these features are
>> always welcome.
>>
>> Regards
>> -Denis
>
> OK, thanks for the information.
>
> Then I guess the next question is whether you have plans to support this
> in the future, or if you would accept patches in this direction. I'm
> afraid some of them could potentially affect the existing API.
>
Patches are always welcome. I'm not sure why you want to change the
existing API, sounds like most of these features belong to a new atom
interface, however I could be wrong. Go ahead and send your proposal so
we have a starting point for the discussion.
Regards,
-Denis
next prev parent reply other threads:[~2011-08-21 2:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 15:28 Bluetooth HF role Mikel Astiz
2011-08-20 9:00 ` Denis Kenzior
2011-08-25 12:32 ` Mikel Astiz
2011-08-21 2:13 ` Denis Kenzior [this message]
2011-09-08 8:27 ` Mikel Astiz
2011-09-01 8:18 ` Denis Kenzior
2011-09-08 10:03 ` Mikel Astiz
2011-08-24 16:56 ` Gustavo Padovan
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=4E5069DB.4020006@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.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.