Comment by ~dodoeg on ~mil/sxmo-tickets
I don't quite understand what you're saying here. Are you saying that with the latest crust you do not see modem disconnections on phone wake up anymore?
The hang up during probing is a different thing, and you would not see it anyway on sxmo, since it's not using systemd-elogind, and ModemManager is not doing any suspend/wakeup management.
Comment by ~dodoeg on ~mil/sxmo-tickets
I agree, that script is reliable in restoring the data connection, but not in ringing the phone in time during the wakeup from CRUST. When the modem resets the usb connection internally, the script would be stuck on waiting for ttyUSB for a long time, and during that time the call on the caller side terminates.
As I was saying in ticket #116, my workaround was to do the unbind and bind as it happens in the script always right after the wakeup from CRUST. Doing that, the connection is always restored, and my BH always rings reliably on the 3rd/4th ring on the caller side.
Comment by ~dodoeg on ~mil/sxmo-tickets
I tested quite a lot recently to have reliable calls when waking up from crust, and I might have found a workaround for my Braveheart. I'm no expert with low level hardware details, so I might be incorrect on some things here below, but I'd like to see whether this is useful for others as well.
From the modem logs (read through adb shell to the modem), I think that the underlying problem to the modem disconnections, common to all the distro, is that the power provided to the modem is reduced briefly sometimes during the wakeup from crust. When this happens, the modem closes and reopens the usb connection. Apparently the host doesn't see that, and therefore the "force closed errors".
So, my initial thought was to unbind the usb connection to the modem before the sleep, in order to rebind it when exiting suspend. Doing this, whatever happens during the wakeup (i.e. whether the modem closes the connection or not), we should end up having a valid state after the wakeup. Unfortunately doing this sometimes the usb device disappears completely, and requires a modem poweroff and poweron to restore it. I'm not sure why this happens, but my wild guess is that it might be related to the host usb powersave.
So, next try was to unbind and rebind the usb device immediately when exiting from suspend. With this approach, I haven't missed a single test call in the last day. I always get the notification for the incoming call on the 3rd/4th ring. The 4g connection is also always restored properly. Also, this works in plain sxmo, without elogind, which means without ModemManager doing anything specific before/after suspend.
Comment by ~dodoeg on ~mil/sxmo-tickets
Hi fedon, any news on this? I have put together my personal sxmo_matrix.sh that uses matrix-commander to integrate Matrix with the sxmo dmenu. So far I can list rooms and send messages similarly to what happens with SMS. I also have a modified matrix-commander running in background to create notifications for new messages. The notification quickly brings you to the room-specific menu to read last messages or send a new message.
I'd like to submit a patch after more testing and polishing, but maybe you have something already?