| Almindor | r0kk3rz: it doesn't normally do it, try putting the phone to your ear with just some random app running it won't dim. It only does it if the app sets it somehow. I suppose I could use QSensor and send mce the "dim screen" message as needed... | 00:07 |
|---|---|---|
| r0kk3rz | hmm, talk to spiiroin about it | 00:15 |
| *** zbenjamin_ is now known as zbenjamin | 01:15 | |
| *** SpeedEvil is now known as Guest53750 | 02:29 | |
| *** BitEvil is now known as SpeedEvil | 03:59 | |
| spiiroin | Almindor is gone, but... if you have an app that performs phone like function / otherwise needs to have in-call like proximity blanking behavior in your app, you can tell mce that there is a call -> https://git.merproject.org/mer-core/mce-dev/blob/master/include/mce/dbus-names.h#L167 | 05:52 |
| spiiroin | or, if this is something you want to do in general -> you can tell mce to treat proximity sensor as lid/cover sensor -> mcetool --set-ps-acts-as-lid=<enabled|disabled> | 05:57 |
| spiiroin | btw, if an app making those call state requests drops from dbus, the request will be automatically ignored -> if testing with mcetool, it must not be allowed to exit immediately -> mcetool --set-call-state=active:normal --block | 06:03 |
| r0kk3rz | thanks spiiroin | 06:19 |
| dcaliste | Hello chriadam, just a word to report that Maus who tested the mKCal patch yesterday is reporting that it fixes the issue of un-deletable event (see MER#2032). | 06:54 |
| chriadam | great! | 06:54 |
| chriadam | nice work | 06:54 |
| dcaliste | Yeh, that's good. | 06:55 |
| dcaliste | Yesterday, I forgot to tell you also that I won't be there next week and won't be able to attent the meeting. | 06:56 |
| chriadam | ah, no problem :-) | 06:56 |
| chriadam | I saw that pvuorela had a few comments on the PR - will you get a chance to address those this week? or maybe you did that already? | 06:56 |
| dcaliste | I'm replying to his remarks just now and will soon push the corrected version to jolla-email repo. | 06:57 |
| chriadam | brilliant, thanks. hopefully once that is done he will approve and I can merge/tag ;-) | 06:58 |
| Coolgeek | hey | 09:03 |
| Coolgeek | I want to update some of my apps from openrepos, but storeman says there is an error : "File './qt/armv7hl/dconf-0.28.0-1.3.1.jolla.armv7hl.rpm' not found on medium 'https://releases.jolla.com/releases/3.0.2.8/jolla/armv7hl/'" | 09:05 |
| Coolgeek | any idea ? | 09:05 |
| karry | @Coolgeek try to update your package cache... Run "pkcon refresh" from command line... | 09:06 |
| Coolgeek | doing it now... will see :) | 09:08 |
| Coolgeek | karry: thx, ot worked ! | 09:10 |
| Coolgeek | it* | 09:10 |
| *** frinring_ is now known as frinring | 10:22 | |
| spiiroin | r0kk3rz: before I forget - that in-call proximity blanking depends also on audio routing i.e. when headset/loudspeaker is used -> no proximity blanking. if it does not work with custom "calls" in the expected manner -> audiorouting/ohm hiccups/confusion could be the reason | 10:27 |
| manemobiili | Has anyone tried compiling plain linux desktop software on sailfishos? | 13:31 |
| leszek | manemobiili: apparently. Like weechat and others exist for SFOS aswell | 13:39 |
| manemobiili | leszek: how about wayland? | 13:44 |
| Almindor | what's the correct way to blank but not lock the display from an app? | 17:14 |
| Almindor | mce headers suggest apps should never call MCE_DISPLAY_*_REQ calls | 17:15 |
| spiiroin | Almindor: blanking is ok, unblanking is not | 18:05 |
| spiiroin | Almindor: btw, did you see the stuff I wrote earlier today? | 18:05 |
| spiiroin | Almindor: I mean "to induce in-call like proximity behavior, tell mce that you have ongoing call" -> http://www.merproject.org/logs/%23sailfishos/%23sailfishos.2019-04-10.log.html | 18:06 |
| Almindor | didn't see, checking now, thanks! | 18:17 |
| Almindor | hmm ok and this will blank the screen when in active state? | 18:18 |
| Almindor | hmm I'm probably doing something wrong, getting [D] :49 - call failed org.freedesktop.DBus.Error.ServiceUnknown message: The name com.nokia.mce was not provided by any .service files | 18:27 |
| spiiroin | Almindor: system bus | 18:27 |
| Almindor | ah | 18:29 |
| Almindor | ok, so I got true back on setting it to 'active'/'normal' but it doesn't seem to do anything. screen stays on if I trigger the sensor | 18:31 |
| Almindor | not using audio in any way atm. so it shouldn't be the speakers thing | 18:33 |
| Almindor | I know the proximity sensor is working fine, it reports things fine, but the screen doesn't blank. Tried with no audio and audio playing (not loudspeaker). Is there any way to debug this further? The Dbus call returned true | 19:06 |
| attah | So that'd be *after* sensorfw i guess? Otherwise perhaps: https://git.merproject.org/mer-core/sensorfw/blob/master/README.md | 19:10 |
| Almindor | what do you mean after? | 19:14 |
| attah | like things sorta happen in a chain right... something reads sensor and then tells other thingamajig to dim screen | 19:15 |
| Almindor | well I suspect mce is supposed to listen to the sensor and turn the screen off if the call state is set to 'active' | 19:16 |
| Almindor | I have 0 control over that stuff apart from setting that state, but since I got true back I'm fairly sure that part worked ok | 19:16 |
| attah | and listen is on dbus? so i guess sensorfwd is talking on dbus... but i don't actually know that | 19:16 |
| Almindor | you mean the proximitysensor? | 19:17 |
| attah | and probably many others | 19:17 |
| Almindor | I just use QML's ProximitySensor with active: true and a logger on the event | 19:17 |
| Almindor | that part registers ok | 19:17 |
| attah | XA2 screwy proximity sensor workaround is to restart sensorfwd | 19:17 |
| Almindor | I get true with hand close, false without | 19:17 |
| Almindor | no I think the issue is with mce and the active call state | 19:18 |
| Almindor | for some reason mce doesn't dim the screen even tho I set the call state to active/normal and get 'true' back | 19:18 |
| attah | is that in the qt call method, or on dbus-monitor? | 19:19 |
| Almindor | this is on a Jolla 1 test phone, the call to mce is done using dbus interface (QML) right on the start of the app atm. (logged) | 19:20 |
| Almindor | I then trigger the sensor but the screen stays up | 19:20 |
| Almindor | looks like this: https://ghostbin.com/paste/eu57z | 19:26 |
| attah | Hmm, yeah, i don't really have any ideas here | 19:30 |
| coderus | shouldn't we be able to reinstall any existing package inside sdk? what the point of preinstalling pacakge inside target, but package is not available in repo? i'm talking about ambienced-devel package. | 19:47 |
| spiiroin | Almindor: 1st get it working with mcetool: 1) "systemctl restart mce" (the assumed audiorouting defaults = allows blanking); 2) "mcetool -c active:normal -B" (it should now react to sensor cover/uncover) | 20:13 |
| spiiroin | if when that works, you can stop mce service and run it manually in debug mode, for ex. | 20:14 |
| spiiroin | mce -Tqqq -ldatapipe.c:audio*pipe -ldatapipe.c:proximity_sensor_effective_pipe -l modules/audiorouting.c:audio_route_sink | 20:14 |
| spiiroin | should show you both proximity & audio route processing | 20:15 |
| spiiroin | if you physically get the audio to go to the earpiece in the phone, but mce reports != "handset" -> might be case of missing sink mapping | 20:21 |
| Almindor | thanks, I'll check this out | 20:21 |
| Almindor | do I have to install mcetool from somewhere? | 20:24 |
| spiiroin | Almindor: pkcon install mce-tools | 20:24 |
| Almindor | ah mce-tools | 20:24 |
| Almindor | right thx | 20:24 |
| Almindor | ok mcetool side works fine, going to do the debug logs now | 20:26 |
| Almindor | the logging output of mce <your args> should be stdout/stderr? | 20:27 |
| spiiroin | Almindor: yes, the "-T" part switches from syslog -> stderr | 20:28 |
| Almindor | it's not outputing anything | 20:28 |
| spiiroin | "mce -V" says? | 20:29 |
| Almindor | # mce -V | 20:29 |
| Almindor | mce v1.99.8 | 20:29 |
| Almindor | wouldn't the -Tqqq make it quiet? | 20:29 |
| Almindor | ah that was it, removed the qqq | 20:30 |
| spiiroin | Almindor: yes, but then we turn on specific parts | 20:30 |
| Almindor | oh hmm | 20:30 |
| spiiroin | but, sorry. some of that stuff is from current devel head of mce. I'll need to check a bit | 20:30 |
| spiiroin | mce -Tqqq -lmodules/aud*:* -ltklock.c:audio*pipe*cb | 20:33 |
| spiiroin | then drop the 'qqq' and add things like perhaps '-ltklock.c:tklock_uiexception_rethink' | 20:34 |
| spiiroin | but getting the sink name that gets activated when you app does audio playing would be the 1st glue | 20:35 |
| Almindor | https://ghostbin.com/paste/ntqjx | 20:44 |
| Almindor | I can confirm mce works without the audioplayback in there | 20:44 |
| Almindor | the logs are with the playback of course | 20:44 |
| Almindor | you can see the OPEN -> CLOSe in the middle for the sensor | 20:46 |
| Almindor | I suspect it's because the playback is categorized as music? it's not loud tho, doesn't seem to be "loudspeaker" setting (maxing out I can berely hear it) | 20:46 |
| spiiroin | Almindor: a sec, been a while this was touched ... | 20:46 |
| Almindor | sure, no rush :) NOTE: I'm just using MediaPlayer (QML) with a file as placeholder for testing, i wonder if maybe there's some enum I need to set to make it think it's a call audio? | 20:47 |
| spiiroin | that "music playback" thing is more about volume key policy... should not affect proximity blanking | 20:49 |
| spiiroin | but I can see only "audio sink 'ihf' -> audio route 1" like info in the log | 20:50 |
| spiiroin | which should be "internal hands free" aka the speaker. not earpiece | 20:52 |
| spiiroin | the assumption is that proximity blanking is only desirable when sound goes to earpiece -> phone is placed at ear during call while not using headset/speaker | 20:53 |
| Almindor | how is the sink controller? | 20:53 |
| Almindor | *controlled | 20:53 |
| Almindor | customAudioRole? | 20:54 |
| spiiroin | a bit outside my area of expertise... jusa would know, possibly others too | 20:55 |
| Almindor | hmm no that doesn't seem to exist in our Qt version yet | 20:55 |
| Almindor | looking at https://doc.qt.io/qt-5/qml-qtmultimedia-mediaplayer.html#audioRole-prop but getting invalid property in qml | 20:56 |
| Almindor | oh wait just using old version of import, but using audioRole: MediaPlayer.VoiceCommunicationRole doesn't seem to change it | 20:58 |
| spiiroin | switching between headset and speaker is "automatic" on headset connect/disconnect | 20:59 |
| Almindor | I don't have anything connected on this jolla | 20:59 |
| spiiroin | getting audio to go to the earpiece might be something completely else | 20:59 |
| spiiroin | call ui has toggle that chooses between earpiece and speaker ... | 21:01 |
| Almindor | call ui isn't open source is it? :D | 21:02 |
| spiiroin | no, but qml sources are there and can be read | 21:02 |
| Almindor | where? I wasn't able to find the phone app sources anywhere | 21:02 |
| spiiroin | but those cellular calls are probably quite different from all other audio things. | 21:03 |
| Almindor | there has to be a way, android apps can do it | 21:04 |
| Almindor | would be really sad if this wasn't possible from native | 21:05 |
| spiiroin | Almindor: /usr/share/voicecall-ui-jolla/pages/calling/InCallView.qml | 21:05 |
| spiiroin | speakerSwitch does things like: telephony.audioMode = 'earpiece' | 21:06 |
| spiiroin | where that actually leads is another thing | 21:06 |
| Almindor | where's telephony itself from? | 21:08 |
| spiiroin | probably: /usr/share/voicecall-ui-jolla/VoiceCallManager.qml | 21:10 |
| Almindor | I don't think I'm allowed to import import Sailfish.Telephony 1.0 | 21:13 |
| spiiroin | I was thinking that it might provide some hints, but I guess it delves into cellular specialities | 21:15 |
| spiiroin | probably all it needs is some audio magick, but... | 21:16 |
| spiiroin | pulse-audio I mean | 21:17 |
| Almindor | well in https://sailfishos.org/wiki/Telephony it says that Call audio management and routing is implemented through PulseAudio: | 21:18 |
| Almindor | but it only goes directly to sources on the two there | 21:18 |
| Almindor | there has to be a nice way to switch the sink for an app | 21:20 |
| spiiroin | I could try asking around tomorrow/fri, but now I think I need to get some sleep | 21:23 |
| Almindor | sure, thanks a lot anyway! at least now I know where the issue is | 21:24 |
| Almindor | I'll be around the next few days | 21:24 |
| spiiroin | ok, meanwhile what might work for app development purposes: rename/move /usr/lib/mce/modules/audiorouting.so somewhere | 21:26 |
| spiiroin | that should cause: mce does not get audiorouting changes -> the startup default that allows proximity blanking stays effective even if you do audio playback | 21:27 |
| spiiroin | but do check that mce starts up & otherwise behaves / maybe do not leave it like that over reboots | 21:28 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!