**** BEGIN LOGGING AT Thu Aug 15 02:59:58 2019 Aug 15 06:18:19 Tofe: I'll try regular oFono with Hammerhead see how it behaves Aug 15 06:18:35 Just for reference Aug 15 06:18:49 I'm not sure we eventually would want to go down Mer's oFono route with all it's specifics which aren't needed for us Aug 15 09:02:13 Morning Aug 15 09:26:57 Tofe: Morning! Aug 15 09:35:45 Tofe: I'll try plain vanilla oFono 1.30 on Hammerhead to see what it does there, just for reference Aug 15 09:36:15 Just to see to what extend we "need" Mer's oFono Aug 15 09:36:39 Not using Mer's oFono, also means we don't need libgofono, libgofonoext etc Aug 15 09:39:09 I know it's 5.1 based, so different RIL etc, so it's limited in terms of use, but still Aug 15 09:43:31 Well, Mer's ofono "rilmodem" is 5.1 based too Aug 15 09:43:41 ah wait Aug 15 09:43:51 now I understand your sentence Aug 15 09:43:55 damn, I need coffee Aug 15 09:45:21 I just had another one :P Aug 15 09:46:12 can you paste me your ofono.bb? Aug 15 09:46:32 It doesn't build yet it seems, gimme a few minutes ;) Aug 15 09:46:36 oh ok :) Aug 15 10:00:25 Seems I dropped my .bbappend in previous 1.30 build and I need to update our patches ;) Aug 15 10:16:57 And some other cleanup Aug 15 10:17:10 Let me try and just push the changes in a new meta-webos-ports branch Aug 15 10:21:29 Tofe: This is what I have. oFono builds OK with this, just need to test whole luneos-dev-package still: https://github.com/webOS-ports/meta-webos-ports/commit/d143b2b9fddf39e1eff5d7ed54b266716bbec365 Aug 15 10:33:00 Whole image also OK Aug 15 10:36:58 ok Aug 15 10:38:51 I just added it in a new layer for now Aug 15 10:39:03 Since it's not in Yocto yet Aug 15 10:39:09 well we have backports now Aug 15 10:39:32 It's not in Yocto master or master-next yet :P Aug 15 10:39:47 ah, correct :) Aug 15 10:53:32 Seems Hammerhead doesn't like my oFono, it's failing hard to start Aug 15 10:53:35 Will do some debugging Aug 15 11:01:19 on my side, I advanced a bit: the cause why ofono doesn't trigger anything when called is that UNSOL_RESPONSE_CALL_STATE_CHANGED isn't sent from RIL Aug 15 11:01:35 Only UNSOL_CALL_RING is sent Aug 15 12:24:18 Tofe: Well RIL should come from https://github.com/LineageOS/android_hardware_ril/tree/cm-14.1-caf I would say Aug 15 14:19:13 Are we using caf ril for tissot ? I thought it was quzlcomm's Aug 15 14:35:25 Not sure, good question, let me cehck to make sure Aug 15 14:36:54 https://paste2.org/tvZhIc91 I see "qcril_qmi_voice_map_qmi_to_ril_last_call_failure_cause: map qmi reason: 16" Aug 15 14:37:11 Which could translate to "No provision" Aug 15 14:37:47 Tofe: Well the BoardConfig.mk seems to suggest CAF: https://github.com/nicolasmartbg/android_device_xiaomi_tissot/blob/810de638678f6c2d94f2c6cb3fd7ffe6fdb8b102/BoardConfig.mk#L199 Aug 15 14:38:19 ok, good to know Aug 15 14:43:18 Though there are some references to MidoRIL which is some extension to the Qcom RIL it seems Aug 15 14:43:27 However all the code is in Java, so not appplicable to us Aug 15 14:43:45 And anyway seems that the device tree from Tissot was cloned from Mido at some point :P Aug 15 14:58:15 Tofe: CAF = Code Aurora Forum = Qualcomm ;) Aug 15 15:00:17 but I fear that the details of the failure lies in the qcom proprietary driver, qcril_qmi Aug 15 15:14:32 I wonder where it pulls that in though Aug 15 15:32:28 Ah found them Aug 15 15:32:53 https://bpaste.net/show/bQ_F Aug 15 15:34:58 Tofe: Not for Tissot specifically, but might give you some ideas, since it's MSM8953 which is used by Tissot as well: https://github.com/Plutonium-AOSP/msm8937-8953_vendor_qcom_proprietary/tree/master/qcril/qcril_qmi Aug 15 15:36:46 This one is for Xiaomi Cancro Halium build: https://github.com/halium-cancro/android_vendor_qcom_proprietary/blob/cm-14.1/qcril/qcril_qmi/qcril_qmi.mk Aug 15 16:29:00 Tofe: That at least should allow you to look in sourcecode instead of ASM ;) **** ENDING LOGGING AT Fri Aug 16 03:05:29 2019