[PATCH] Fix change state immediately when meet the slash

According to V.250 spec section 5.2.4 Repeating a command line, if the prefix A/ or a/ is received, we should execute the last command immediately. No need to meet \r. --- gatchat/gatserver.c | 20 +--- 1 files changed, 5 insertions(+), 15 deletions(-) diff --git

Re: [RFC] [PATCH 0/2] HFP AG integration with PulseAudio

Hi, 2010/1/29 João Paulo Rechi Vita jprv...@gmail.com: Hi all, I'm trying to add support for the Handsfree Gateway role Gustavo just added to BlueZ and oFono. The BlueZ patches can be found on [1] and [2] and the oFono part was just merged upstream. But when it comes to integrate them with

Re: [PATCH] Fix change state immediately when meet the slash

Hi Zhenhua, According to V.250 spec section 5.2.4 Repeating a command line, if the prefix A/ or a/ is received, we should execute the last command immediately. No need to meet \r. Yes you're right. @@ -214,22 +213,14 @@ static enum ParserResult server_feed(GAtServer *server, i += 1;

FW: FW: [RFC 3/3] STE-plugin: Adding STE plugin

Hi Denis. We have done some testing with the STE modem for call termination, and this is the result: TC |Call #1 | Call #2 | Call #3 | Command | Result ---| 1 |ACTIVE | ACTIVE | .. | ATH | call 1, 2

[PATCH] hfp: create modem for new devices paired on runtime

It listens the Paired property to create a modem to the recently paired devices. It also renames added_watch to adapter_watch, a more proper name. --- plugins/hfp.c | 47 ++- 1 files changed, 42 insertions(+), 5 deletions(-) diff --git

[PATCH 2/2] Remove dead assignments at gatchat

--- gatchat/gatchat.c |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/gatchat/gatchat.c b/gatchat/gatchat.c index 5b0851b..d5362db 100644 --- a/gatchat/gatchat.c +++ b/gatchat/gatchat.c @@ -312,7 +312,6 @@ static gboolean g_at_chat_match_notify(GAtChat *chat, char

[PATCH 2/3] Add PN_GSS code points and debugging

--- Makefile.am |3 +- drivers/isimodem/debug.c | 25 +++ drivers/isimodem/debug.h |5 drivers/isimodem/gss.h | 58 ++ 4 files changed, 90 insertions(+), 1 deletions(-) create mode 100644

[PATCH 3/3] Add isimodem radio access driver

--- Makefile.am |1 + drivers/isimodem/isimodem.c |4 + drivers/isimodem/isimodem.h |3 + drivers/isimodem/radio-access.c | 299 +++ 4 files changed, 307 insertions(+), 0 deletions(-) create mode 100644

[PATCH 1/3] Add radio access atom and driver API

This atom provides access to the modem's radio access properties. It currently includes a single rw property, namely the radio access selection mode setting. This allows the user to query and select the used radio access technology preference. In dual mode, either 2G or 3G is used depending on

Re: [RFC 3/3] STE-plugin: Adding STE plugin

Hi Sjur, Hi Denis. We have done some testing with the STE modem for call termination, and this is the result: TC |Call #1 | Call #2 | Call #3 | Command | Result ---| 1 |ACTIVE | ACTIVE | .. | ATH |

Re: [PATCH 1/3] Add radio access atom and driver API

Hi Aki, This atom provides access to the modem's radio access properties. It currently includes a single rw property, namely the radio access selection mode setting. It might be helpful to include the API documentation too. One thing I don't like is the name RadioAccess. The connotation is

RE: [PATCH 1/3] Add radio access atom and driver API

This atom provides access to the modem's radio access properties. It currently includes a single rw property, namely the radio access selection mode setting. It might be helpful to include the API documentation too. One thing I don't like is the name RadioAccess. The connotation is a

Re: [PATCH 1/3] Add radio access atom and driver API

Hi Waldo, This atom provides access to the modem's radio access properties. It currently includes a single rw property, namely the radio access selection mode setting. It might be helpful to include the API documentation too. One thing I don't like is the name RadioAccess. The

RE: [PATCH 1/3] Add radio access atom and driver API

People on this list keep forgetting two things: 1. We're not designing a kitchen sink API here. Most of the 'radio related settings' will simply never be exposed, nobody really cares what UMTS channel he/she is currently on. 2. We're designing the API to be easy to use for everyone, not