----- Message d'origine -----
> > * AT+CPBR and friends is hooked to the phonebook, which is Qt-based,
> > therefore inadequate inside oFono.
> I am not buying into the AT+CPBR for the local and user specific
> phonebook. That one is inside Tracker anyway and also inside the user
> session. Trying to really support this is a broken idea. CPBR can not
> expose the information of modern contacts storage anyway, so just don't
I can see how AT+CPBW could be problematic, more so than AT+CPBR. But that is not relevant. If a big enough customer wants it badly enough, it has to be done. I do not want to end up with an architecture that forbids satisfying some of my employer's potential major customers.
> If you really care about it then use Bluetooth PBAP via obexd which we
> have enabled already.
> > * At Nokia, we also have some non-standard commands for internal use.
> > * Some operators require some funky AT commands of their own. It might
> not be
> > possible to open-source them, even if we want to.
> And these should be on an engineering mode only USB CDC ACM interface
> with a different backend anyway.
I already mentioned that the same software must run in certification and in user's hands for "whole device" certification to be valid. But anyway, some of those commands were requested as DUN extensions, not as testing stuff. So no no no.
> Only because someone wants to shoehorn this into something nasty,
> doesn't mean we should do it. And I am not going to scarifies the
> simplicity of the oFono D-Bus API for this.
We are talking about the Originated boolean call property?!
----- Message d'origine -----
> do me a favor and try not to break the threading next time.
When I am away from my laptop, I use whatever MUA I can. This is obviously not deliberate a choice.
> I am getting a bit sick of this secrecy. oFono is for all intense and
> purposes open source.
And I am sick of arguing for something as simple and obvious as exposing the call direction in the calls list.
> So if you want a proper discussion here then
> please list the AT command in question.
Operator requirements are typically confidential. Since they are copyighted by their originator, not by me or my employer, I cannot fix that. Or rather, I can try (it is ongoing) but I cannot promise anything.
But this is only a side issue. We have a working AT commands DCE implementation that supports both cellular/oFono stuff and all the other that we need. Open-sourcing as much as we can is an ongoing process. I am not interested in rewriting that (and the BlueZ HFP code) into oFono just for the heck of it.
Furthermore providing some useful features (like call direction) only via a would-be oFono AT commands but not via the _preferred_ D-Bus interface seems silly and counter-productive to me.
----- Message d'origine -----
> why would bringing an interface up interfere? We are doing this right
> now. Just the IP assignment is done by ConnMan, but the interface
> up/down status is controlled by oFono or even BlueZ in case of
Logically whoever sets the IP parameters should bring the interface administratively up. This is layer 3.
oFono does layer 2. It should either create/remove the interface and/or play with the dormant and/or carrier flags.
Rebased old patch. Found some errors that had been introduced into the
simfs code. Added file type to simutil, although I couldn't test it
on any real hardware.
Kristen Carlson Accardi (4):
simfs: cache images
sim: implement GetIcon
simfs: fix incorrect math when calculating length to copy
simutil: add file type for EFimg
src/sim.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/simfs.c | 83 ++++++++++++++++++++++---
src/simfs.h | 4 +
src/simutil.c | 1 +
4 files changed, 266 insertions(+), 9 deletions(-)
This forces automake/make to build them first if needed (as before).
But it avoids marking every single header as a dependency of every
single object. Thus we do not need a bogus full rebuild of the tree
everytime a header is added.
Makefile.am | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index a4c47e8..ee7949d 100644
@@ -326,7 +326,8 @@ src_ofonod_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ @CAPNG_LIBS@ -ldl
src_ofonod_LDFLAGS = -Wl,--export-dynamic \
-CLEANFILES = src/builtin.h $(local_headers) $(rules_DATA)
+BUILT_SOURCES = $(local_headers)
+CLEANFILES = src/builtin.h $(BUILT_SOURCES) $(rules_DATA)
plugindir = $(libdir)/ofono/plugins
@@ -512,8 +513,6 @@ src/builtin.h: src/genbuiltin $(builtin_sources)
$(AM_V_GEN)cp $(srcdir)/$(subst 97-,,$@) $@
-$(src_ofonod_OBJECTS) $(unit_objects): $(local_headers)
$(AM_V_GEN)$(LN_S) $(abs_top_builddir)/$< $@
This series of patch is to add provide local info support by requesting the terminal to send time and language info. Please comment on the following aspects as I'm not sure after reading the spec:
1. Timezone may be a number in the range -47 through +48. In struct sms_scts, timezone is defined as gint8, thus 0xFF should shand for -1, which is a valid input. Thus I think build_dataobj_datetime_timezone() in src/stkutil.c is not correct. But I'm still not sure what value should be passed to oFono when timezone is absent.
2. DBUS_TYPE_BYTE represents an 8-bit unsigned integer, and D-Bus doesn't have a type related to 8-bit signed integer. So what's the best way to represent a timezone?
3. Only one byte is used to represent the year. Is the following logic correct to get the year with one byte?
if (year_dbus >= 2000)
year = year_dbus - 2000;
year = year_dbus - 1900;
Yang Gu (3):
network: Use bit as size instead of byte
stk: Handle provide local info proactive command
test-stk: Add provide local info
src/network.c | 4 +-
src/smsutil.c | 6 +-
src/stk.c | 113 ++++++++++++++++++++++++++++++++++++++
src/stkagent.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++
src/stkagent.h | 14 +++++
src/stkutil.c | 2 +-
test/test-stk-menu | 36 ++++++++++++
7 files changed, 322 insertions(+), 6 deletions(-)