Monday, 2022-01-17

T42<rodrisola> after reboot, the phone, no longer boots into the system, it must be a service, but I can't read the dmesg, I'm stuck there00:37
spiiroinpiggz: "prox sensor works fine ... but in a call, it doesnt dim the screen" - mce also needs to know that call_state=active and audio_route=handset04:32
spiiroincall state comes from tracking ofono, audio route from tracking ohm04:33
T42<AntonlX> Where I can find crash reporter reports?05:34
T42<TheVancedGamer> YYESSSS (re @MissRose_bot: Another one bites th...)06:12
T42<TheVancedGamer> IT WORKS06:12
T42<rodrisola> Working sailfish on mi4 lite06:36
T42<rodrisola> Thanks!!!06:38
T42<Verevka86> Poco X3 Pro, but the problem of sound during a phone call negates all efforts, it is not possible to use it as a phone 😔07:18
piggzspiiroin: thanks, yeah, so far we've determined that MCE believes the call state to be !=HANDSET ... which probably comes from OHM?08:08
piggzaudio is routed correctly with pulse to Earpiece08:08
T42<AntonlX> Does sailfish os suport usb tethering feature? Like phone working as usb modem for pc.10:12
T42<AntonlX> How to include it to my port? I have to install some packages?10:19
T42<AntonlX> Is there any way to fix encryption on community ports?12:51
ThaodanWhat do you need to fix.12:51
T42<AntonlX> Encryption not working with my port12:53
ThaodanDoesn't mean it has something to do with your port being a community port.12:54
ThaodanWhat is not working?12:54
Thaodane.g. it works on two ports of mine.12:54
T42<rodrisola> How to fix wifi Bluetooth etc15:06
T42<rodrisola> The device starts but it takes 10 minutes to start, I know it's not normal, but you have to keep debugging....15:07
T42<Verevka86> for wifi to work without a module and additional settings- (re @rodrisola: The device starts bu...)15:21
T42<rodrisola> Brother hello, I disable time_daemon (re @Verevka86:
T42<Verevka86> what does time_deamon have to do with it?15:28
T42<rodrisola> i have error in this16:19
T42<rodrisola> [   40.771030] droid-hal-init: Control message: Could not find '' for ctl.interface_start from pid: 3600 (/system/bin/hwservicemanager)16:19
piggzmal: nice to see jolla's ofono become a bit more modern!17:32
spiiroinpiggz: sort of yes, audio_route=handset is derived from ohm policy dbus signals (but call_state is ofono-thing + iirc voicecall manager does it too)18:49
piggzspiiroin: ok, im looking at it now if you fancy helping ;)18:50
piggzor suggest  any debugging :)18:50
spiiroincaveat is that it is (or was?) just a signal -> restarting mce = ohm status is lost. but as long as mce is started well before testing call it should be fine18:51
spiiroin"mce -Tq -ldatapipe.c:call_state_pipe -ldatapipe.c:audio* -ldatapipe.c:proximity* -ldatapipe.c:display_state*" -> only the relevant state data changes18:52
spiiroinomit the "q" i.e. "mce -T -l..." -> normal logging + state changes18:53
spiiroinor possibly "-lmodules/audiorouting.c:*" if you know that all but audioroute stuff is already correct18:54
spiiroin"mce: T+3.037 D: modules/audiorouting.c: actions_dbus_cb(): audio_route_pipe: execute speaker"18:57
spiiroinspeaker use = no proximity blanking. but should it be =speaker?18:58
piggzspiiroin: and this contains the audiorouting
piggzspiiroin: yeah, trick is working out why it thinks its speaker :)18:59
piggzwhen, audio is actually on the earpiece18:59
piggzspiiroin: we have a completely custom pulseaudio and xpolicy config ... mostly written with help from monich, but never fully tested, so, im wondering if its in there that the problem is19:00
spiiroin"mce: T+1.803 D: modules/audiorouting.c: audio_route_sink(): audio sink 'earpieceforcall' -> audio route 0" <-- that "0", they were recently changed to human readable form19:01
spiiroinwhat mce version you have+19:01
piggzmce v1.109.119:02
maljust wondering if xpolicy things could cause issues, that device has a bit hacky xpolicy files19:02
piggzmal: monich migh disagree :D19:03
piggzor maybe not19:03
malpiggz: but you didn't have the earpiece conf modified19:04
malif it needs same changes as the main file19:04
malthose sink/source changes19:05
piggzmal: those are in there...19:05
piggztype  = earpiece19:05
piggzsink  = equals:$dev_sink19:05
malpiggz: but does the extra file from submodule override those19:05
piggzports = $dev_sink:$sink_earpiece19:05
piggzthat paste is from device19:05
malor did you remove the extra file from submodule19:05
malfrom the xpolicy.conf.d folder19:06
piggzsparse will overwrite submodule19:06
spiiroinpiggz: using mce v1.109.2 while debugging might be useful - does not fix your problem, but it has "make audio_route logging more human readable" bits19:07
malah, missed that you had also added that19:07
* spiiroin knows nothing about policy config ;-/19:08
spiiroinone thing to check that comes to mind: does speaker toggle work? in the sense that audio output is as expected both ways?19:14
piggzspiiroin: no it doesnt19:14
piggzcant route to speaker19:14
piggzmal: spiiroin: looking at line 250, you can see its routed correctly to "earpieceforcall"
malwhat does the next line after that mean19:26
spiiroinyes, but ~50ms later... mce: T+1.865 D: modules/audiorouting.c: audio_route_sink(): audio sink 'ihfforcall' -> audio route 1 (1 = "speaker")19:27
spiiroinmal: it is how mce interprets the policy change broadcast, using enum set: AUDIO_ROUTE_UNDEF = -1, AUDIO_ROUTE_HANDSET = 0, AUDIO_ROUTE_SPEAKER = 1, AUDIO_ROUTE_HEADSET = 2,19:29
spiiroinso 1st it is right = handset, then it is switched to "speaker" (but audio still comes from earpiece = mismatch?)19:30
piggzspiiroin: and, the signals to mce coem from here?
spiiroinpiggz: looks likely19:43
spiiroinbut that is how all of ohm looks to me: there main() and some likely leaf functions that I sort of understand and a big mystery in between those ...19:44
piggzmixing up my sailors .. it was jusa that worked on the PA config, not monich19:59

Generated by 2.17.1 by Marius Gedminas - find it at!