Re: [PATCH] udevng: Add support for Quectel BG96 modem
by Martin Hundebøll
Hi Sean,
On 11/25/19 9:26 AM, Sean Nyekjaer wrote:
> Signed-off-by: Sean Nyekjaer <sean(a)geanix.com>
No signoff when submitting to ofono.
// Martin
> ---
> plugins/udevng.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/plugins/udevng.c b/plugins/udevng.c
> index 40ed2b02..cc294c94 100644
> --- a/plugins/udevng.c
> +++ b/plugins/udevng.c
> @@ -1790,6 +1790,8 @@ static struct {
> { "quectelqmi", "qcserial", "2c7c", "0121" },
> { "quectelqmi", "qmi_wwan", "2c7c", "0125" },
> { "quectelqmi", "qcserial", "2c7c", "0125" },
> + { "quectelqmi", "qmi_wwan", "2c7c", "0296" },
> + { "quectelqmi", "qcserial", "2c7c", "0296" },
> { "ublox", "cdc_acm", "1546", "1010" },
> { "ublox", "cdc_ncm", "1546", "1010" },
> { "ublox", "cdc_acm", "1546", "1102" },
>
10 months
Telit ME910C1-WW not detected
by Dresdo Gabriele
Hello,
I'm new to oFono, I'm trying to setup a Telit ME910C1 with oFono 1.18 in our embedded system (ARMHF) with Debian stretch kernel 4.9.11 but list-modems returns no results.
I installed ofono packet using apt-get
I can send and receive AT commands to the modem using a terminal connected to /dev/ttyUSB1
I paste Log from ofonod -dn.
Any suggestion will be useful
Thanks
Gabriele
ofonod[592]: oFono version 1.18
ofonod[592]: src/plugin.c:__ofono_plugin_init()
ofonod[592]: plugins/push-notification.c:push_notification_init()
ofonod[592]: plugins/smart-messaging.c:smart_messaging_init()
ofonod[592]: src/cdma-provision.c:ofono_cdma_provision_driver_register() driver: 0x54c3f868 name: CDMA provisioning
ofonod[592]: src/gprs-provision.c:ofono_gprs_provision_driver_register() driver: 0x54c3f83c name: Provisioning
ofonod[592]: plugins/upower.c:upower_init() upower init
ofonod[592]: src/handsfree-audio.c:ofono_handsfree_card_driver_register() driver: 0x54c3f7e8
ofonod[592]: plugins/dun_gw_bluez5.c:dun_gw_init()
ofonod[592]: src/handsfree-audio.c:ofono_handsfree_card_driver_register() driver: 0x54c3f74c
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f760, name: hfp
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f704, name: ublox
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f6ac, name: quectel
ofonod[592]: plugins/he910.c:he910_init()
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f65c, name: he910
ofonod[592]: plugins/connman.c:connman_init()
ofonod[592]: src/private-network.c:ofono_private_network_driver_register() driver: 0x54c3f630, name: ConnMan Private Network
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f5e8, name: sim900
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f5a0, name: samsung
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f558, name: speedupcdma
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f508, name: speedup
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f4c0, name: alcatel
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f468, name: icera
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f420, name: linktop
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f3d8, name: nokiacdma
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f390, name: nokia
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f348, name: cinterion
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f2c0, name: ste
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f268, name: ifx
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f220, name: palmpre
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f1d0, name: novatel
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f188, name: sierra
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f110, name: huawei
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f0c8, name: zte
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f068, name: hso
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f018, name: mbm
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3efc8, name: calypso
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ef80, name: wavecom
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ef38, name: g1
ofonod[592]: src/cdma-voicecall.c:ofono_cdma_voicecall_driver_register() driver: 0x54c3eedc, name: cdmamodem
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3ef04, name: cdmamodem
ofonod[592]: src/cdma-connman.c:ofono_cdma_connman_driver_register() driver: 0x54c3ef24, name: cdmamodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ee3c, name: phonesim
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ee6c, name: localhfp
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3ee20, name: phonesim
ofonod[592]: src/ctm.c:ofono_ctm_driver_register() driver: 0x54c3ee0c, name: phonesim
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3ede4, name: phonesim
ofonod[592]: plugins/phonesim.c:parse_config() filename /etc/ofono/phonesim.conf
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3edc8, name: ubloxmodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3ed8c, name: speedupmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3ec48, name: hfpmodem
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3ecec, name: hfpmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3eca0, name: hfpmodem
ofonod[592]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x54c3ecd4, name: hfpmodem
ofonod[592]: src/handsfree.c:ofono_handsfree_driver_register() driver: 0x54c3ed1c, name: hfpmodem
ofonod[592]: src/siri.c:ofono_siri_driver_register() driver: 0x54c3ed54, name: hfpmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3ebc0, name: dunmodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3ebe4, name: dunmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3eaf0, name: stemodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3eb7c, name: stemodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3eb40, name: stemodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e9cc, name: ifxmodem
ofonod[592]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x54c3ea24, name: ifxmodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3ea38, name: ifxmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3ea70, name: ifxmodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3ea9c, name: ifxmodem
ofonod[592]: src/ctm.c:ofono_ctm_driver_register() driver: 0x54c3eabc, name: ifxmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e958, name: hsomodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e97c, name: hsomodem
ofonod[592]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0x54c3e918, name: telitmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e88c, name: mbmmodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3e8b0, name: mbmmodem
ofonod[592]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0x54c3e8d0, name: mbmmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e7f4, name: calypsomodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3e844, name: calypsomodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3e6f8, name: huaweimodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e70c, name: huaweimodem
ofonod[592]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x54c3e75c, name: huaweimodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e794, name: huaweimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e770, name: huaweimodem
ofonod[592]: src/cdma-netreg.c:ofono_cdma_netreg_driver_register() driver: 0x54c3e7c4, name: huaweimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e67c, name: iceramodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e6a8, name: iceramodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e624, name: ztemodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e5e0, name: swmodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e598, name: nwmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e40c, name: atmodem
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3e4a4, name: atmodem
ofonod[592]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x54c3e45c, name: atmodem
ofonod[592]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x54c3e1e4, name: atmodem
ofonod[592]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0x54c3e224, name: atmodem
ofonod[592]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x54c3e130, name: atmodem
ofonod[592]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0x54c3e48c, name: atmodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3e3e8, name: atmodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3e1a0, name: atmodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3e328, name: atmodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3e370, name: atmodem-noef
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3e3c0, name: atmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3e288, name: atmodem
ofonod[592]: src/cbs.c:ofono_cbs_driver_register() driver: 0x54c3e1c8, name: atmodem
ofonod[592]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x54c3e4d4, name: atmodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3e504, name: atmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e518, name: atmodem
ofonod[592]: src/sim-auth.c:ofono_sim_auth_driver_register() driver: 0x54c3e53c, name: atmodem
ofonod[592]: src/gnss.c:ofono_gnss_driver_register() driver: 0x54c3e55c, name: atmodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3e090, name: gobi
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3ded0, name: qmimodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3df38, name: qmimodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3def0, name: qmimodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3df5c, name: qmimodem-legacy
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3dfa4, name: qmimodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3dfec, name: qmimodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3e00c, name: qmimodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3e020, name: qmimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e034, name: qmimodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e050, name: qmimodem
ofonod[592]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0x54c3e078, name: qmimodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3de68, name: u8500
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3de48, name: u8500
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3de00, name: n900
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ddb8, name: isiusb
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3db60, name: isimodem
ofonod[592]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0x54c3db50, name: isimodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3db80, name: isimodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3dba4, name: isimodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3dbec, name: isimodem
ofonod[592]: src/cbs.c:ofono_cbs_driver_register() driver: 0x54c3dc0c, name: isimodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3dc20, name: isimodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3dc68, name: isimodem
ofonod[592]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x54c3dc7c, name: isimodem
ofonod[592]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x54c3dc9c, name: isimodem
ofonod[592]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x54c3dccc, name: isimodem
ofonod[592]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0x54c3dce4, name: isimodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3dd0c, name: isimodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3dd34, name: isimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3dd48, name: isimodem
ofonod[592]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x54c3dd64, name: isimodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3dd70, name: wgmodem2.5
ofonod[592]: drivers/rilmodem/rilmodem.c:rilmodem_init()
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3d928, name: rilmodem
ofonod[592]: drivers/rilmodem/sim.c:ril_sim_init()
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3d9fc, name: rilmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3d96c, name: rilmodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3da44, name: rilmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3d948, name: rilmodem
ofonod[592]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x54c3d9b4, name: rilmodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3d9cc, name: rilmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3d9e0, name: rilmodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3da64, name: rilmodem
ofonod[592]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x54c3da78, name: rilmodem
ofonod[592]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x54c3daa8, name: rilmodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3dac8, name: rilmodem
ofonod[592]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x54c3daf0, name: rilmodem
ofonod[592]: src/netmon.c:ofono_netmon_driver_register() driver: 0x54c3db08, name: rilmodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3db18, name: rilmodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3d8c0, name: ril_sofia3gr
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3d878, name: infineon
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3d830, name: ril
ofonod[592]: plugins/udevng.c:udev_start()
ofonod[592]: plugins/udevng.c:enumerate_devices()
ofonod[592]: plugins/udevng.c:check_usb_device() hub [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() hub [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() usb [0424:2514]
ofonod[592]: plugins/udevng.c:check_usb_device() usb [1bc7:1101]
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.0/ttyUSB0/tty/ttyUSB0
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB0 (telit) 255/255/255 [00] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.1/ttyUSB1/tty/ttyUSB1
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB1 (telit) 255/255/255 [01] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.2/ttyUSB2/tty/ttyUSB2
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB2 (telit) 255/254/255 [02] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.3/ttyUSB3/tty/ttyUSB3
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB3 (telit) 255/255/255 [03] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() hub [(null):(null)]
ofonod[592]: plugins/udevng.c:create_modem() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:create_modem() driver=telit
ofonod[592]: src/modem.c:ofono_modem_create() name: (null), type: telit
ofonod[592]: plugins/udevng.c:setup_telit() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB0 255/255/255 00 (null)
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB1 255/255/255 01 (null)
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB2 255/254/255 02 (null)
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB3 255/255/255 03 (null)
ofonod[592]: plugins/udevng.c:setup_telit() modem=/dev/ttyUSB0 aux=/dev/ttyUSB3 gps=(null) diag=/dev/ttyUSB1
ofonod[592]: src/modem.c:set_modem_property() modem 0x55d8e3d8 property Modem
ofonod[592]: src/modem.c:set_modem_property() modem 0x55d8e3d8 property Aux
ofonod[592]: src/modem.c:set_modem_property() modem 0x55d8e3d8 property GPS
ofonod[592]: src/modem.c:ofono_modem_register() 0x55d8e3d8
1 year, 2 months
Re: [pulseaudio-discuss] Proposal for a new API and usage of
Bluetooth HSP and HFP profiles on Linux
by Denis Kenzior
Hi Pali,
>> There have been one or two implementations of AG role fully external to
>> oFono. These implementations simply used the existing oFono APIs to drive
>> the modem.
>
> bluez & pulseaudio developers told me that it would be a good idea to
> avoid implementing a new AT parser for telephony stack. And rather use
> ofono implementation for telephony part...
In my opinion there's nothing scary about AT parsing. In fact that is
the easiest part of this whole venture. If you don't want to roll your
own parser, you can borrow one from the oFono project. We already
solved this nicely in the form of the gatchat library. You could
incorporate this into your project (if it is GPL compatible). Or you
could wait until we port gatchat to ell which will be under LGPL license.
>
> But if I should use existing DBus API provided by ofono, it means that I
> need to do parsing of all AT commands (including telephony) and
> translate them to ofono DBus API.
I think you will need to do this regardless. Otherwise I fail to see
how you prevent one 'agent' from consuming AT commands it shouldn't be.
This is a possibility you need to consider, whether it happens by
accident or maliciously.
>
> I agree, this should work and there is not need to modify ofono. But it
> means that in hsphfpd daemon I need to have full AT parser for all
> telephony commands and it was something which bluez / pa developers
> thought that should be avoided. Therefore I come up with idea that
> telephony commands would be handled by external Telephony Agent, which
> can be ofono.
Understood. But I think the metric function was selected
inappropriately in this case. My opinion is that you should have
started with what the overall architecture should look like; you should
not have based design decisions on which parts might be a little hard to
implement.
>
>> You could do that. But as I said, we rejected such a design a
>> long time ago due to complexity and other issues.
>
> Anyway, what is the problem with accepting modem socket in ofono via
> DBus and starts talking with it like with any other modem which ofono
> supports? Currently ofono already takes modem socket from bluez via DBus
> API, so in same way hsphfpd can pass modem socket to ofono. Basically
> ofono then can reuse same code which already uses for sockets from
> bluez, just it do not have to parse and interpret audio related AT
> commands (as these are handled by hsphpfd itself).
>
> What are exact issues? I do not see complexity at ofono part (as has
> already everything implemented) and currently I do not see those "other"
> issues.
The issues are many. And really the question is not whether it 'could
be' done, but whether it 'should be' done. Let me describe a couple
examples:
- In the case of HF role (1), oFono already provides all the necessary
APIs. So put yourself in oFono's maintainer shoes. What would we gain
by supporting almost the same but different mechanism? We would have to
introduce a new hfp_hf plugin, one that is almost identical, but
different to hfp_hf_bluez5 plugin. These two plugins would have
coexistence issues, which would add more complexity. Then there's the
impact on PulseAudio and other users. How do they know when to use the
HandsfreeAudio API vs some external API? Supporting this new way buys
us a lot of extra code / complexity with no value added.
- The other example is more practical. HFP Service Level Connection
(SLC) establishment is actually quite tricky. There are certain
limitations on what can and cannot be done prior to SLC establishment,
including how audio handling is done. Unfortunately, codec negotiation,
indicator negotiation, and feature negotiation are part of the SLC.
oFono already solves all of this and handles all of it nicely. We have
passed all relevant certification testing. It is very unclear how you
plan to handle this (or whether you realistically even can) in your
architecture when the responsibilities are split between the various
daemons. So again, oFono has nothing to gain here...
>
> You suggested to use phone simulator together with ofono and then
> starts extending / patching phone simulator to supports all needed parts
> which are in my hsphfpd design (battery status, button press, codec
> selection)?
>
Not quite. I suggested you expand oFono's emulator implementation (for
AG role) and its DBus APIs (for HF role) to support the new vendor
specific features that you want.
Forget about the phone simulator, it is really irrelevant for what
you're trying to accomplish.
> Also how to handle the main problem of phone simulator that it is too
> much complicated to setup it on desktop? Looking at the steps...
>
> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/B...
>
> ... that desktop user needs to run nontrivial commands in command like,
> plus creating configuration file only just to connect bluetooth headset
> is ridiculous and non-acceptable for desktop application.
>
> If this problem is not fixed, ofono and phone simulator are not usable
> as "main" software implementation of HFP profile for usage of bluetooth
> headsets on Linux.
oFono was never advertised as solving the 'HFP AG without a modem' use
case. This is something we never had as a requirement / objective.
Phonesim is a development tool. So of course it isn't trivial to setup,
it isn't meant to be used in production in the first place. The use of
phonesim described in the PA wiki, while creative, is a giant hack ;)
Basically it all boils down to the fact that nobody has stepped up all
this time to solve a particular use case you care about. But blaming
oFono for this is misguided.
So, if you want to solve the HFP AG without a modem case I fully support
your efforts.
Perhaps this can even be solved in oFono itself (since it already does
90% of what you want) by making the modem requirement optional. What we
could do for example is to create a dummy modem if an AG connection is
requested and no other suitable modems are detected in the system. The
resultant AG wouldn't have any call control capability, it could still
be used for transferring audio data, battery, etc. If you want to
pursue this, we can brainstorm further.
Regards,
-Denis
1 year, 4 months
[PATCH] xmm7modem: CPIN handling after sending puk
by Antara Borwankar
On XMM modems SIM is busy after PUK is entered. CME ERROR: 14
is received for AT+CPIN? query. Therefore polling for CPIN: READY
state.
---
drivers/atmodem/sim.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c
index e750a13..3ed5aa0 100644
--- a/drivers/atmodem/sim.c
+++ b/drivers/atmodem/sim.c
@@ -1354,13 +1354,14 @@ static void at_pin_send_cb(gboolean ok, GAtResult *result,
case OFONO_VENDOR_HUAWEI:
case OFONO_VENDOR_SIMCOM:
case OFONO_VENDOR_SIERRA:
+ case OFONO_VENDOR_XMM:
/*
* On ZTE modems, after pin is entered, SIM state is checked
* by polling CPIN as their modem doesn't provide unsolicited
* notification of SIM readiness.
*
- * On SIMCOM modems, SIM is busy after pin is entered (we
- * got a "+CME ERROR: 14" for the "AT+CPIN?" request) and
+ * On SIMCOM and XMM modems, SIM is busy after pin is entered
+ * (we got a "+CME ERROR: 14" for the "AT+CPIN?" request) and
* ofono don't catch the "+CPIN: READY" message sent by the
* modem when SIM is ready. So, use extra CPIN to check the
* state.
--
1.9.1
1 year, 4 months
[PATCH] sim: handling crash in error scenario for SIM PIN query
by Antara Borwankar
In case of error in sim_pin_query_cb function. pin_type is set
to -1. This is causing segmentation fault in function
sim_passwd_name due to invalid index pin_type = -1. Fixing this
issue by handling error case before calling sim_passwd_name
function.
---
src/sim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/sim.c b/src/sim.c
index 535ccbc..33e1245 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -3201,7 +3201,7 @@ static void sim_pin_query_cb(const struct ofono_error *error,
DBusConnection *conn = ofono_dbus_get_connection();
const char *path = __ofono_atom_get_path(sim->atom);
struct cached_pin *cpins = pin_cache_lookup(sim->iccid);
- const char *pin_name = sim_passwd_name(pin_type);
+ const char *pin_name;
char **locked_pins;
gboolean lock_changed;
@@ -3212,6 +3212,8 @@ static void sim_pin_query_cb(const struct ofono_error *error,
return;
}
+ pin_name = sim_passwd_name(pin_type);
+
if (sim->pin_type != pin_type) {
sim->pin_type = pin_type;
--
1.9.1
1 year, 4 months
[PATCH] xmm7xxx: modified handling of XSIM states for xmm modems
by Antara Borwankar
+XSIM:7 state as defined in xmm7560 functional AT specification
only indicates ready for attach.
+CPIN: READY is received after SIM is completely initialized.
Also indicating readiness of Phonebook and SMS. Hence moving the
creation of SMS and Phonebook atom to xmm7xxx_post_sim function.
+XSIM:4 PUK needed state was not handled. It must be handled
same as PIN needed state. Added handling of this case to
switch_sim_state_status function.
---
plugins/xmm7xxx.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/plugins/xmm7xxx.c b/plugins/xmm7xxx.c
index 32c024e..b3aaf85 100644
--- a/plugins/xmm7xxx.c
+++ b/plugins/xmm7xxx.c
@@ -106,8 +106,8 @@ struct xmm7xxx_data {
GAtChat *chat; /* AT chat */
struct ofono_sim *sim;
ofono_bool_t have_sim;
- ofono_bool_t sms_phonebook_added;
unsigned int netreg_watch;
+ int xsim_status;
};
/* Coex Implementation */
@@ -980,10 +980,10 @@ static void switch_sim_state_status(struct ofono_modem *modem, int status)
if (data->have_sim == TRUE) {
ofono_sim_inserted_notify(data->sim, FALSE);
data->have_sim = FALSE;
- data->sms_phonebook_added = FALSE;
}
break;
case 1: /* SIM inserted, PIN verification needed */
+ case 4: /* SIM inserted, PUK verification needed */
if (data->have_sim == FALSE) {
ofono_sim_inserted_notify(data->sim, TRUE);
data->have_sim = TRUE;
@@ -991,30 +991,26 @@ static void switch_sim_state_status(struct ofono_modem *modem, int status)
break;
case 2: /* SIM inserted, PIN verification not needed - READY */
case 3: /* SIM inserted, PIN verified - READY */
- case 7: /* SIM inserted, SMS and phonebook - READY */
+ case 7: /* SIM inserted, Ready for ATTACH - READY */
if (data->have_sim == FALSE) {
ofono_sim_inserted_notify(data->sim, TRUE);
data->have_sim = TRUE;
}
ofono_sim_initialized_notify(data->sim);
-
- if (data->sms_phonebook_added == FALSE) {
- ofono_phonebook_create(modem, 0, "atmodem", data->chat);
- ofono_sms_create(modem, 0, "atmodem", data->chat);
- data->sms_phonebook_added = TRUE;
- }
-
break;
default:
ofono_warn("Unknown SIM state %d received", status);
break;
}
+
+ data->xsim_status = status;
}
static void xsimstate_notify(GAtResult *result, gpointer user_data)
{
struct ofono_modem *modem = user_data;
+ struct xmm7xxx_data *data = ofono_modem_get_data(modem);
int status;
GAtResultIter iter;
@@ -1029,7 +1025,8 @@ static void xsimstate_notify(GAtResult *result, gpointer user_data)
DBG("status=%d\n", status);
- switch_sim_state_status(modem, status);
+ if (data->xsim_status != status)
+ switch_sim_state_status(modem, status);
}
static void xsimstate_query_cb(gboolean ok, GAtResult *result,
@@ -1083,7 +1080,7 @@ static void cfun_enable_cb(gboolean ok, GAtResult *result, gpointer user_data)
g_at_chat_send(data->chat, "AT&C0", NULL, NULL, NULL, NULL);
data->have_sim = FALSE;
- data->sms_phonebook_added = FALSE;
+ data->xsim_status = -1;
ofono_modem_set_powered(modem, TRUE);
@@ -1239,6 +1236,9 @@ static void xmm7xxx_post_online(struct ofono_modem *modem)
DBG("%p", modem);
+ ofono_phonebook_create(modem, 0, "atmodem", data->chat);
+ ofono_sms_create(modem, 0, "atmodem", data->chat);
+
ofono_netreg_create(modem, OFONO_VENDOR_IFX, "atmodem", data->chat);
gprs = ofono_gprs_create(modem, OFONO_VENDOR_IFX, "atmodem",
--
1.9.1
1 year, 4 months
Re: [pulseaudio-discuss] Proposal for a new API and usage of
Bluetooth HSP and HFP profiles on Linux
by Denis Kenzior
Hi Pali,
>>> But would you accept patches which exports DBus API e.g. for displaying text
>>> on HFP headset with embedded display? Or patches which implements 3
>>> different way for reporting battery level status of HFP headset? And API
>>> for sending "computer battery level" to HFP headset? Or implementing
>>> setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
>>> uinput linux device for button press events? Because all these
>>
>> So which roles are we talking about here? Your Design document shows
>> hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was not
>> the intent?
>
> My proposed hsphfpd is going to support both roles. Which means to
> implement whole HFP profile. So for connecting bluetooth headsets (when
> AG role is needed on desktop) and also for connecting mobile phones
> (when HF role is needed on desktop).
>
> And my primary motivation is for bluetooth headsets as this is what are
> asking desktop and laptop users again and again that is missing on Linux
> systems.
>
> So higher priority has AG role and slightly lower priority has HF role.
>
So to summarize. You have broadly 3 main use cases for HFP:
1. HF connecting to AG role. Essentially a carkit role. oFono does
this pretty well already and has the APIs defined that cover up to HFP
1.7. Any vendor extensions can be easily added. And some carkit
manufacturers already use it.
2. AG role when you have a 'real modem' behind it. oFono already
provides everything needed for this scenario.
3. AG role when you don't have a real modem or you have some sort of
VoIP use case. oFono doesn't cover this case as you stated.
So I can see value in something that implements case #3. But having
said that, oFono will not be receiving AT commands from external daemons:
- For case 1, it'd just be a rehash of what oFono does well already. I
reinvented a few wheels in my time, but doesn't mean I think this one
should be.
- The reasoning for case 2/3 I already covered upthread.
>> If you're talking about extending oFono APIs when it is acting as the HF
>> connecting to the AG, then codec setup APIs, etc are definitely something
>> that would be welcome.
>>
>> If you're talking about AG role, then that is different... In general, if
>> the oFono is in an AG role, then there should be nothing to configure and
>> there are no APIs for this role.
>
> Codecs needs to be configured also in AG role. Before accepting SCO
> connection you need to configure SCO socket for correct codec. Also for
> vendor codecs it needs to be properly negotiated via AT commands.
>
Sure, but that doesn't mean they need an actual D-Bus API to be
configured with. You can simply extend oFono emulator to support
whatever codecs you want and whatever custom AT command handling that
you need. If the HF requests the codec, then you use it. There's no
D-Bus API required here. Again, take a look at how this is done in
oFono today.
>> Such a design will get a NAK from me on the oFono side. But don't let that
>> stop you. You can simply invoke oFono APIs directly from your daemon. No
>> need for any changes in oFono itself. As mentioned above, I wouldn't
>> recommend it, but... :)
>
> So if you are disagreeing with this design, can you propose alternative?
> Which would support needs for desktop users? Support for HSP profile (in
> AG role), support for HFP profile (in AG role), ability to parse and
> interpret needed AT commands. And later also HS and HF role of these
> profiles.
>
There have been one or two implementations of AG role fully external to
oFono. These implementations simply used the existing oFono APIs to
drive the modem. You could do that. But as I said, we rejected such a
design a long time ago due to complexity and other issues.
Or you can ignore the call control aspects entirely...
But in the end, it is your architecture. All I can do is point out
(early in the process) what is and what is not acceptable to oFono upstream.
>>
>> Okay, I see now. Yes, the above is correct. My comments about not needing
>> a modem device hold true only if oFono is in HFP HF role connecting to an
>> AG.
>
> Ok. So I guess now you understood main problem. I thought it was
> obvious, but seems that bluetooth HFP is too complicated, so talking
> about it always needs more detailed explanation. Sorry for that if it
> was not clear from my side since beginning what are requirements for my
> setup.
Well it was a bit of reading comprehension fail on my part as well. The
two roles are really quite different, so precise language helps.
Regards,
-Denis
1 year, 4 months
[PATCH] xmm7xxx: handling of sms ready state for xmm7xxx plugin
by Antara Borwankar
+XSIM:7 state as defined in xmm7560 functional AT specification
only indicates ready for attach. PB ready and SMS ready has to be
quired seperately using +XSIMSTATE command after +XSIM:12 state
is received indicating SIM SMS Caching Completed. (Sent only when
SMS caching enabled). +XSIM:12 may or may not be received so moving
the sms ready and pb ready logic to post sim function afteR receiving
+CPIN:READY
---
plugins/xmm7xxx.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 61 insertions(+), 11 deletions(-)
diff --git a/plugins/xmm7xxx.c b/plugins/xmm7xxx.c
index 32c024e..f62a093 100644
--- a/plugins/xmm7xxx.c
+++ b/plugins/xmm7xxx.c
@@ -106,7 +106,8 @@ struct xmm7xxx_data {
GAtChat *chat; /* AT chat */
struct ofono_sim *sim;
ofono_bool_t have_sim;
- ofono_bool_t sms_phonebook_added;
+ ofono_bool_t phonebook_added;
+ ofono_bool_t sms_added;
unsigned int netreg_watch;
};
@@ -968,6 +969,59 @@ static GAtChat *open_device(struct ofono_modem *modem,
NULL);
}
+static void xsimstate_sms_ready_query_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct xmm7xxx_data *data = ofono_modem_get_data(modem);
+ int sms_ready, pb_ready;
+ GAtResultIter iter;
+
+ DBG("%p", modem);
+
+ if (!ok)
+ return;
+
+ g_at_result_iter_init(&iter, result);
+
+ if (!g_at_result_iter_next(&iter, "+XSIMSTATE:"))
+ return;
+
+ if (!g_at_result_iter_skip_next(&iter))
+ return;
+
+ if (!g_at_result_iter_skip_next(&iter))
+ return;
+
+ if (!g_at_result_iter_next_number(&iter, &pb_ready))
+ return;
+
+ if (!g_at_result_iter_next_number(&iter, &sms_ready))
+ return;
+
+ DBG("sms_ready=%d\n", sms_ready);
+
+ DBG("data->sms_added=%d\n", data->sms_added);
+
+ if (pb_ready && data->phonebook_added == FALSE) {
+ ofono_phonebook_create(modem, 0, "atmodem", data->chat);
+ data->phonebook_added = TRUE;
+ }
+
+ if (sms_ready && data->sms_added == FALSE) {
+ ofono_sms_create(modem, 0, "atmodem", data->chat);
+ data->sms_added = TRUE;
+ }
+}
+
+static void xmm7xxx_get_sms_ready_state(struct ofono_modem *modem)
+{
+ struct xmm7xxx_data *data = ofono_modem_get_data(modem);
+
+ g_at_chat_send(data->chat, "AT+XSIMSTATE?", xsimstate_prefix,
+ xsimstate_sms_ready_query_cb, modem, NULL);
+}
+
static void switch_sim_state_status(struct ofono_modem *modem, int status)
{
struct xmm7xxx_data *data = ofono_modem_get_data(modem);
@@ -980,7 +1034,8 @@ static void switch_sim_state_status(struct ofono_modem *modem, int status)
if (data->have_sim == TRUE) {
ofono_sim_inserted_notify(data->sim, FALSE);
data->have_sim = FALSE;
- data->sms_phonebook_added = FALSE;
+ data->phonebook_added = FALSE;
+ data->sms_added = FALSE;
}
break;
case 1: /* SIM inserted, PIN verification needed */
@@ -991,20 +1046,13 @@ static void switch_sim_state_status(struct ofono_modem *modem, int status)
break;
case 2: /* SIM inserted, PIN verification not needed - READY */
case 3: /* SIM inserted, PIN verified - READY */
- case 7: /* SIM inserted, SMS and phonebook - READY */
+ case 7: /* SIM inserted, READY for ATTACH - READY */
if (data->have_sim == FALSE) {
ofono_sim_inserted_notify(data->sim, TRUE);
data->have_sim = TRUE;
}
ofono_sim_initialized_notify(data->sim);
-
- if (data->sms_phonebook_added == FALSE) {
- ofono_phonebook_create(modem, 0, "atmodem", data->chat);
- ofono_sms_create(modem, 0, "atmodem", data->chat);
- data->sms_phonebook_added = TRUE;
- }
-
break;
default:
ofono_warn("Unknown SIM state %d received", status);
@@ -1083,7 +1131,8 @@ static void cfun_enable_cb(gboolean ok, GAtResult *result, gpointer user_data)
g_at_chat_send(data->chat, "AT&C0", NULL, NULL, NULL, NULL);
data->have_sim = FALSE;
- data->sms_phonebook_added = FALSE;
+ data->phonebook_added = FALSE;
+ data->sms_added = FALSE;
ofono_modem_set_powered(modem, TRUE);
@@ -1225,6 +1274,7 @@ static void xmm7xxx_post_sim(struct ofono_modem *modem)
{
struct xmm7xxx_data *data = ofono_modem_get_data(modem);
+ xmm7xxx_get_sms_ready_state(modem);
ofono_lte_create(modem, 0, "atmodem", data->chat);
ofono_radio_settings_create(modem, 0, "xmm7modem", data->chat);
ofono_sim_auth_create(modem);
--
1.9.1
1 year, 4 months
Re: [pulseaudio-discuss] Proposal for a new API and usage of
Bluetooth HSP and HFP profiles on Linux
by Denis Kenzior
Hi Pali,
> Yes, I see. Also there are devices without HFP support, only with HSP.
> pulseaudio support also these devices and pulseaudio is not going to
> drop support for them. Last time when I looked at ofono, it has no HSP
> support. Is ofono going to add support for HSP?
>
No.
<snip>
>
> But would you accept patches which exports DBus API e.g. for displaying text
> on HFP headset with embedded display? Or patches which implements 3
> different way for reporting battery level status of HFP headset? And API
> for sending "computer battery level" to HFP headset? Or implementing
> setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
> uinput linux device for button press events? Because all these
So which roles are we talking about here? Your Design document shows
hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was
not the intent?
If you're talking about extending oFono APIs when it is acting as the HF
connecting to the AG, then codec setup APIs, etc are definitely
something that would be welcome.
If you're talking about AG role, then that is different... In general,
if the oFono is in an AG role, then there should be nothing to configure
and there are no APIs for this role. Things like reporting AG battery
level to HFP headset are done directly using plugins. See
ofono_emulator_set_indicator and how this is done by upower.c for
example. I happily take patches for any additional features (codecs,
etc) you want to support here.
But... oFono upstream has no interest in accepting forwarded AT commands
from some external daemon if we're in AG role. We rejected such a
design years ago and nothing has changed.
AG role is already quite tricky to implement without additional
complexity introduced by having multiple applications and IPC. "Its
your funeral" as the saying goes if you want to go that route.
<snip>
> I disagree here. Primary purpose of HFP for desktop users is ability to
> use bluetooth's microphone. And not telephony stack and its complicated
> features like call hold and others, which are in HFP used and
> implemented probably only in car kits.
So your primary goal here is to have the desktop play the role of the
AG, purely so you can forward the audio from a headset out to whatever
it is that you want. And you want oFono (or some other daemon) to
(optionally) handle the call related AT commands in the HFP AG role.
Such a design will get a NAK from me on the oFono side. But don't let
that stop you. You can simply invoke oFono APIs directly from your
daemon. No need for any changes in oFono itself. As mentioned above, I
wouldn't recommend it, but... :)
>
>>>> Also for using ofono with HFP profile is not possible on desktop
>>>> computer which do not have any modem as it is hooked to some active
>>>> modem.
>>
>> This statement is not true at all. You can use oFono without any 'real'
>> modems attached. It can happily manage only HFP devices (or modems as we
>> call them.)
>
> Ok, can you please provide exact steps how to do it, including
> activating of bidirectional audio stream?
So again, which role? If we're the HF connecting to the AG, then things
just work without a modem. If we're the AG, then yes you need a modem
to be driven by the AG connection.
>>
>> You must be thinking of the oFono HFP AG implementation...
>
> Yes! For connecting bluetooth headset you need HFP AG implementation.
>
> And I guess this is the reason why simulator is needed. HFP headset acts
> as a "client" for modem. Therefore on desktop / laptop you need to
> implement "modem server" which will be used by HFP headset "client".
>
> And phone simulator is doing exactly this "modem server", it is
> simulator of modem.
>
Okay, I see now. Yes, the above is correct. My comments about not
needing a modem device hold true only if oFono is in HFP HF role
connecting to an AG.
Regards,
-Denis
1 year, 4 months
Re: [pulseaudio-discuss] Proposal for a new API and usage of
Bluetooth HSP and HFP profiles on Linux
by Denis Kenzior
Hi Pali,
>>> I'm not sure what logic around HSP you really care about. It is just a
>>> single button press in the end.
>>
>> CSR features (battery status level, ...) and CSR codec selection (e.g.
>> AuriStream). Also some apple extensions are used in HSP profile.
Since HFP can do everything that HSP can and more, I view HSP as
deprecated and not to be used. If these are also available in HFP, then
I'd just use HFP instead. But HSP was never my focus, so if you feel
there's a need for better HSP support, then fair enough.
>>
>>> For HFP, oFono can already support all sorts of extensions. See for example
>>> how we handled Siri for HFP support in oFono here:
>>> https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt.
>
> About Siri: In hsphfpd API it is delegated to Telephony Agent. So
> hsphfpd is not going to (re)implement it.
>
>> I saw. But it does not support usage of vendor codecs, like CSR
>> AuriStream and it does not support CSR extensions, like displaying text
>> on embedded display.
But that's my point, you can easily accomplish this by creating another
oFono API / atom for HFP CSR extensions and expose this information /
functionality. Similar to how Siri was done. I see no need for a
completely new external daemon.
>>
>>> Many of the extensions you talked about are also relevant for real modems as
>>> well (like battery reporting, call volume, etc). Some of these APIs are
>>> already defined in fact.
>>>
>>> Given the above, oFono upstream has no interest in adding or maintaining
>>> support this new framework.
>
> Maybe better question: Do you mean that you do not want to maintain
> hsphfpd, or that you completely do not want to see that ofono would be
> "Telepony Agent" for hsphfpd?
The latter.
>
>> Denis, if you are not interested in my proposed hsphfpd daemon, how you
>> want to solve problem with other extensions and other vendor codecs?
>>
See above..
>> Also in my proposed solution it is possible to use HFP profile without
>> Telephony Agent (ofono). Do you think it is really a good idea to have
>> strong dependency on ofono just for bluetooth HFP headset?
>>
Why not? The main purpose of HFP is telephony; whether it is classic
phone calls or skype/facetime. oFono seems a natural fit.
>> Also for using ofono with HFP profile is not possible on desktop
>> computer which do not have any modem as it is hooked to some active
>> modem.
This statement is not true at all. You can use oFono without any 'real'
modems attached. It can happily manage only HFP devices (or modems as
we call them.)
>>
>> There is a way to use ofono sim simulator which provide fake modem, but
>> its setup is hard on desktop and it not automated.
>>
You must be thinking of the oFono HFP AG implementation...
>> So connecting bluetooth headset in HFP profile with ofono is something
>> not so easy and not an obvious way.
>>
Again, not true. As I said above, you can use oFono for this use case
just fine. Certainly the main driver for the development of oFono was
to drive real modem hardware, but it isn't limited to that. So if you
want to use it only for HFP, you can.
Regards,
-Denis
1 year, 4 months
