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 there | 00:37 |
---|---|---|
spiiroin | piggz: "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=handset | 04:32 |
spiiroin | call state comes from tracking ofono, audio route from tracking ohm | 04: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 WORKS | 06:12 |
T42 | <rodrisola> Working sailfish on mi4 lite | 06:36 |
T42 | <rodrisola> https://irc.thaodan.de/.imgstore/3d3ee696/file_3225.jpg | 06:38 |
T42 | <rodrisola> Thanks!!! | 06:38 |
T42 | <Verevka86> https://irc.thaodan.de/.imgstore/c5bd8a20/file_3226.jpg | 07:16 |
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 |
piggz | spiiroin: thanks, yeah, so far we've determined that MCE believes the call state to be !=HANDSET ... which probably comes from OHM? | 08:08 |
piggz | audio is routed correctly with pulse to Earpiece | 08:08 |
T42 | <AntonlX> Does sailfish os suport usb tethering feature? Like phone working as usb modem for pc. | 10:12 |
Thaodan | yes | 10:16 |
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 |
Thaodan | fix? | 12:51 |
Thaodan | What do you need to fix. | 12:51 |
T42 | <AntonlX> Encryption not working with my port | 12:53 |
Thaodan | Doesn't mean it has something to do with your port being a community port. | 12:54 |
Thaodan | What is not working? | 12:54 |
Thaodan | e.g. it works on two ports of mine. | 12:54 |
T42 | <rodrisola> How to fix wifi Bluetooth etc | 15: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> https://github.com/SailfishOS-vayu/droid-config-vayu/commits/master | 15:21 |
T42 | <Verevka86> for wifi to work without a module and additional settings- https://github.com/SailfishOS-vayu/android_kernel_xiaomi_sm8150/commit/88c339c7ee22215c6a96bb310dd21bcc94300ecb (re @rodrisola: The device starts bu...) | 15:21 |
T42 | <rodrisola> Brother hello, I disable time_daemon (re @Verevka86: https://github.com/S...) | 15:27 |
T42 | <Verevka86> what does time_deamon have to do with it? | 15:28 |
T42 | <rodrisola> i have error in this | 16:19 |
T42 | <rodrisola> [ 40.771030] droid-hal-init: Control message: Could not find 'android.hardware.graphics.composer@2.1::IComposer/default' for ctl.interface_start from pid: 3600 (/system/bin/hwservicemanager) | 16:19 |
piggz | mal: nice to see jolla's ofono become a bit more modern! | 17:32 |
mal | :) | 17:46 |
spiiroin | piggz: 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 |
piggz | spiiroin: ok, im looking at it now if you fancy helping ;) | 18:50 |
piggz | or suggest any debugging :) | 18:50 |
spiiroin | caveat 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 fine | 18:51 |
spiiroin | "mce -Tq -ldatapipe.c:call_state_pipe -ldatapipe.c:audio* -ldatapipe.c:proximity* -ldatapipe.c:display_state*" -> only the relevant state data changes | 18:52 |
spiiroin | omit the "q" i.e. "mce -T -l..." -> normal logging + state changes | 18:53 |
spiiroin | or possibly "-lmodules/audiorouting.c:*" if you know that all but audioroute stuff is already correct | 18:54 |
piggz | spiiroin: https://paste.mozilla.org/qwL27UyE | 18:56 |
spiiroin | "mce: T+3.037 D: modules/audiorouting.c: actions_dbus_cb(): audio_route_pipe: execute speaker" | 18:57 |
spiiroin | speaker use = no proximity blanking. but should it be =speaker? | 18:58 |
piggz | spiiroin: and this contains the audiorouting https://paste.mozilla.org/SxQeP2ne | 18:58 |
piggz | spiiroin: yeah, trick is working out why it thinks its speaker :) | 18:59 |
piggz | when, audio is actually on the earpiece | 18:59 |
piggz | spiiroin: 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 is | 19: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 form | 19:01 |
spiiroin | what mce version you have+ | 19:01 |
piggz | mce v1.109.1 | 19:02 |
mal | just wondering if xpolicy things could cause issues, that device has a bit hacky xpolicy files | 19:02 |
piggz | mal: monich migh disagree :D | 19:03 |
piggz | or maybe not | 19:03 |
mal | piggz: but you didn't have the earpiece conf modified | 19:04 |
mal | if it needs same changes as the main file | 19:04 |
mal | those sink/source changes | 19:05 |
piggz | mal: those are in there... | 19:05 |
piggz | [device] | 19:05 |
piggz | type = earpiece | 19:05 |
piggz | sink = equals:$dev_sink | 19:05 |
mal | piggz: but does the extra file from submodule override those | 19:05 |
piggz | ports = $dev_sink:$sink_earpiece | 19:05 |
piggz | that paste is from device | 19:05 |
mal | or did you remove the extra file from submodule | 19:05 |
mal | from the xpolicy.conf.d folder | 19:06 |
piggz | https://github.com/sailfish-on-dontbeevil/droid-config-pinephone/blob/master/sparse/etc/pulse/xpolicy.conf.d/earpiece.conf | 19:06 |
piggz | sparse will overwrite submodule | 19:06 |
spiiroin | piggz: 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" bits | 19:07 |
mal | ah, missed that you had also added that | 19:07 |
* spiiroin knows nothing about policy config ;-/ | 19:08 | |
spiiroin | one thing to check that comes to mind: does speaker toggle work? in the sense that audio output is as expected both ways? | 19:14 |
piggz | spiiroin: no it doesnt | 19:14 |
piggz | cant route to speaker | 19:14 |
piggz | mal: spiiroin: looking at line 250, you can see its routed correctly to "earpieceforcall" https://paste.mozilla.org/SxQeP2ne#L250 | 19:25 |
mal | what does the next line after that mean | 19:26 |
spiiroin | yes, but ~50ms later... mce: T+1.865 D: modules/audiorouting.c: audio_route_sink(): audio sink 'ihfforcall' -> audio route 1 (1 = "speaker") | 19:27 |
spiiroin | mal: 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 |
spiiroin | so 1st it is right = handset, then it is switched to "speaker" (but audio still comes from earpiece = mismatch?) | 19:30 |
piggz | spiiroin: and, the signals to mce coem from here? https://github.com/sailfishos/ohm-plugins-misc/blob/ef2c89c9896f48cd2e4dd3904934e6dacbaa2a35/plugins/route/route.c | 19:41 |
spiiroin | piggz: looks likely | 19:43 |
spiiroin | but 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 |
piggz | mixing up my sailors .. it was jusa that worked on the PA config, not monich | 19:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!