Re: RFC: Supporting STK without PDUs
Hi Waldo, I propose to add a set of additional (optional) STK functions that a modem plugin can chose to use/implement instead: void (*envelope_parsed)(struct ofono_stk *stk, struct stk_envelope *e, ofono_stk_envelope_cb_t cb, void *data); /* if envelope_parsed is non-NULL then stk_send_envelope / envelope_queue_run should call envelope_parsed(...) instead of stk_pdu_from_envelope(...) + envelope(...) */ void (*terminal_response_parsed)(struct ofono_stk *stk, struct stk_response *rsp, ofono_stk_generic_cb_t cb, void *data); /* if terminal_response_parsed is non-NULL then stk_respond() should call terminal_response_parsed(...) instead of stk_pdu_from_response(...) + terminal_response(...) */ void ofono_stk_proactive_command_parsed_notify(struct ofono_stk *stk, struct stk_command *command); /* ofono_stk_proactive_command_parsed_notify is like ofono_stk_proactive_command_notify without the call to stk_command_new_from_pdu(pdu, length); */ Thoughts? We have already had a discussion on this one when designing the current stk modem API. The bottom line is that oFono tries to keep its core - modem interfaces minimal and exposing the entirety of stkutil.h as official API is definitely too much. So right now you will need to re-encode into PDU form to support such modems (or ask the vendor to give the raw pdus) While this is a bit of a performance hit, it isn't too bad as the PDUs are always smaller than 256 bytes. Having said that, such 'pre-parsed' STK APIs are quite common. Unfortunately they all behave differently, especially when it comes to handling the more complex commands (e.g. Setup Call, etc) We have been kicking around some ideas on how to handle such modems. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: RFC: Supporting STK without PDUs
Hi Waldo, It looks like the preferred way to handle STK with IFX modems is to use a dedicated mode where the modem handles most of STK commands and only a few remaining commands are passed on to the apps processor for further handling. as far as I know, the IFX firmware also supports what they call raw mode. That mode is purely PDU based. Why just not use that one and let oFono do the hard work. Seems to be working perfectly fine for MBM, STE and Calypso based hardware. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: RFC: Supporting STK without PDUs
We have already had a discussion on this one when designing the current stk modem API. The bottom line is that oFono tries to keep its core - modem interfaces minimal and exposing the entirety of stkutil.h as official API is definitely too much. So right now you will need to re-encode into PDU form to support such modems (or ask the vendor to give the raw pdus) While this is a bit of a performance hit, it isn't too bad as the PDUs are always smaller than 256 bytes. In that case we would still want to use functionality from stkutil.c to do the actual re-encoding. So in my mind it is a trade-off between forking stkutil.c for one or more modem-plugins or exporting stkutil.h Given that the type definitions in stkutil.h are a relative straightforward mapping of TS 102.223 and friends, it may not qualify as a minimal API but it will be a rather stable API. So I would like to ask to reconsider exposing the type definitions as part of the official oFono modem API. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: RFC: Supporting STK without PDUs
Hi Waldo, We have already had a discussion on this one when designing the current stk modem API. The bottom line is that oFono tries to keep its core - modem interfaces minimal and exposing the entirety of stkutil.h as official API is definitely too much. So right now you will need to re-encode into PDU form to support such modems (or ask the vendor to give the raw pdus) While this is a bit of a performance hit, it isn't too bad as the PDUs are always smaller than 256 bytes. In that case we would still want to use functionality from stkutil.c to do the actual re-encoding. So in my mind it is a trade-off between forking stkutil.c for one or more modem-plugins or exporting stkutil.h Given that the type definitions in stkutil.h are a relative straightforward mapping of TS 102.223 and friends, it may not qualify as a minimal API but it will be a rather stable API. So I would like to ask to reconsider exposing the type definitions as part of the official oFono modem API. what is the big deal with just using the PDU interface of the IFX firmware? Why go through all this trouble if your target modem actually does support PDU mode? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
