| lel | IMbackK opened a pull request: https://github.com/maemo-leste/mce/pull/50 (Move to new build system: cmake) | 00:34 |
|---|---|---|
| uvos | Wizzup: ^^^ | 00:35 |
| Wizzup | cool | 00:40 |
| Wizzup | will chkec tomorrow | 00:40 |
| uvos | ok | 00:41 |
| uvos | oh btw one thing i noticed while porting | 00:42 |
| uvos | https://github.com/maemo-leste/mce/blob/81c3c41bef4d0d21924138e450d279105b3ad10f/mce.h#L269 | 00:42 |
| uvos | how did this ever work? | 00:42 |
| uvos | it ofc immidatly stopped working when i switched the build system | 00:42 |
| uvos | but they just declare those varaibles in a header | 00:42 |
| uvos | and then include that header everywhere | 00:42 |
| uvos | and somehow it ends up as the same varaible everywhere | 00:43 |
| uvos | not sure how this ever linked | 00:43 |
| uvos | now its extern... in the header and declared in one c file | 00:43 |
| Wizzup | if they are not static then that makes sense, no? | 00:44 |
| uvos | except it should not link | 00:45 |
| uvos | because you have multiple symbols with the same name no? | 00:45 |
| uvos | (thats also what happens) | 00:45 |
| uvos | but with the original makefile it wokes - somehow | 00:46 |
| Wizzup | hm, not sure | 00:47 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/50 (Move to new build system: cmake) | 00:53 |
| Wizzup | https://github.com/maemo-leste/mce/pull/50/files#diff-6ff8f05ac631e587272a617c2046359aaef8494fd978c1ed5d1f458e144e7133R26 hm | 00:56 |
| uvos | Wizzup: see https://github.com/maemo-leste/mce/pull/50/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR62 | 01:04 |
| uvos | i gues <> is still better | 01:05 |
| uvos | i might have done that before i did the other change | 01:05 |
| Wizzup | mhm | 01:09 |
| uvos | Wizzup: it seams autoconnect also now work fine | 09:47 |
| Wizzup | uvos: great | 09:53 |
| uvos | yes :) | 09:54 |
| uvos | makes for quite the usability improvment | 09:54 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/50 (Move to new build system: cmake) | 10:38 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/50 (Move to new build system: cmake) | 10:39 |
| Wizzup | uvos: well let's test wifi a bit more and then we can promote it | 10:41 |
| Wizzup | I'm getting my second shot today so I might get sick for a bit, so not planning on doing much, but we'll see | 10:42 |
| Wizzup | uvos: I was thinking of testing audio stuff in VM first, seems sane, no? | 13:14 |
| Wizzup | ofc not call audio, but the general policy stuff | 13:14 |
| Wizzup | uvos: ^ | 13:36 |
| uvos | well we would need a ucm profile that emulates the phone ones with the profile names | 13:44 |
| uvos | you could have a profile that has hifi and voice and all the output configs for those | 13:44 |
| uvos | with the ones that dont make sense on vm just noop | 13:44 |
| uvos | then you can do the pulseaudio stuff on top of that and have it work the same on device | 13:45 |
| Wizzup | I think the audio profiles do not relate to ucm per se | 13:46 |
| Wizzup | for example nemo doesn't seem to use UCM | 13:46 |
| Wizzup | so all of that stuff I should be able to build and test without UCM | 13:46 |
| uvos | well the maemo stuff driectly controlls mixers afaik | 13:47 |
| uvos | we dont want to do that | 13:47 |
| Wizzup | sure, that part will have to change, but there are other things to do, e.g. volume applet | 13:47 |
| uvos | we want it to set the profiles, because thats what we have to abstract away hw differences | 13:47 |
| Wizzup | phone calls are just a part of it | 13:47 |
| Wizzup | yeah | 13:47 |
| uvos | sure if you are not touching that part then you can test the setup wherever, gentoo maybe? :P | 13:48 |
| Wizzup | I'm saying it's not a big part of the actual work involved in doing it | 13:49 |
| Wizzup | but yeah, ucm for vm makes sense. | 13:49 |
| uvos | right | 13:49 |
| uvos | (both statements) | 13:50 |
| uvos | ucm for vm should be trivial | 13:50 |
| uvos | just take https://github.com/maemo-leste/leste-config/tree/master/leste-config-mapphone/usr/share/alsa/ucm2/Mapphone_Audio | 13:50 |
| uvos | and remove all cset commands | 13:50 |
| uvos | then you have a dummy setup that you can check with pactl to see if you stuff on top set the right thing | 13:50 |
| Wizzup | ok | 13:52 |
| freemangordon | I really hope UCM is smart enough to be able to handle all the use cases | 14:12 |
| freemangordon | so far it has a deficiency that you cannot attach user data to profile (or whatever it was called) | 14:12 |
| freemangordon | maybe we shall patch that | 14:13 |
| freemangordon | uvos: do you know if ^^ is possible already | 14:13 |
| freemangordon | use case is volume applet, you have more steps on volume slider when using speakers as an output compared to when you use FMTX, for example | 14:14 |
| uvos | ucm is not smart, and thats not its job | 14:19 |
| uvos | its job it so that there is one mixer controll from alsa for pulse to worry about for eatch fucntion, not $(20-RANDOM-CONTROLS) that variy by device | 14:20 |
| Wizzup | freemangordon: afaik UCM can help us switch the mixer values for us, but the policy we still have to do | 14:30 |
| Wizzup | i.e. when do we decide to switch UCM profile, and to what do we switch it | 14:30 |
| Wizzup | it's just easier to use than fiddling with alsamixer values | 14:30 |
| Wizzup | freemangordon: I think for volume applet this can be done with pulse | 14:31 |
| Wizzup | unless I'm confused? | 14:31 |
| lel | parazyd created a repository: https://github.com/maemo-leste/applet-tor | 15:57 |
| freemangordon | actually on fremantle the 'switching' is done by alsa-policy-enforcement, IIRC | 17:50 |
| Wizzup | freemangordon: yes | 17:51 |
| freemangordon | the point is that in PA 'profiles' one can attach some arbitrary user values (key-value pairs), that can be retrieved by PA functions | 17:51 |
| freemangordon | in fremantle that is | 17:51 |
| Wizzup | I am not sure I understand the point | 17:52 |
| Wizzup | see also https://web.archive.org/web/20200815080328/https://github.com/nemomobile/pulseaudio-policy-enforcement | 17:52 |
| freemangordon | so, we have a "Master volume" in PA, and we have a list attached to it with 10 (for example) volume levels that define 10 steps in volume slider | 17:52 |
| Wizzup | so really https://git.sailfishos.org/mer-core/pulseaudio-policy-enforcement | 17:52 |
| freemangordon | ok, so we need this module it seems | 17:53 |
| Wizzup | ok, but I am not sure if we are clear on things | 17:53 |
| Wizzup | alsa = (low level) kernel audio interface with lots of switches | 17:54 |
| Wizzup | ucm = way to interpret alsa switches | 17:54 |
| Wizzup | pulseaudio can also use ucm | 17:54 |
| freemangordon | ok | 17:54 |
| freemangordon | see https://github.com/maemo-leste/maemo-statusmenu-volume/blob/master/src/volume_steps_update | 17:54 |
| Wizzup | and we just need to instrument pulseaudio in various ways, first of all to have separate 'groups' of applications (iiuc), music playing ones and phone calls, and also attach tags | 17:54 |
| Wizzup | that is entirely separate from corking streams, and actually having certain switches change at the right moment | 17:55 |
| Wizzup | assuming we have a proper UCM and pulseaudio understands "Call Mode" (as it does on the d4), we can utility pulseaudio-policy-enforcement to set the right PA modules depending on system state | 17:55 |
| Wizzup | this is really as far as my understanding goes, I plan to understand more this week | 17:55 |
| freemangordon | Wizzup: what I am discussing is on top of that | 17:56 |
| Wizzup | ok | 17:56 |
| freemangordon | look how volume applet initializes | 17:56 |
| freemangordon | https://github.com/maemo-leste/maemo-statusmenu-volume/blob/master/src/item.c#L511 | 17:56 |
| freemangordon | we have 2 predefined sinks | 17:56 |
| freemangordon | 'normal' and 'in-call' | 17:56 |
| bencoh | freemangordon: wasn't xpolicy directly related to pulseaudio? | 17:57 |
| Wizzup | yes, this is what I mean with 17:54 < Wizzup> and we just need to instrument pulseaudio in various ways, first of all to have separate 'groups' of applications (iiuc), music playing ones and phone calls, and also attach tags | 17:57 |
| freemangordon | ok, lets call those properties 'tags' if you wish | 17:57 |
| Wizzup | It's quite some work to pull that apart and reproduce it proper, but that's what I intend to do this week | 17:57 |
| Wizzup | to port the fremantle audio config (minus enforcement) so that volume applet can work | 17:58 |
| Wizzup | that's basically what I plan to do | 17:58 |
| Wizzup | and then hopefully alarms will also work | 17:58 |
| freemangordon | great! | 17:58 |
| freemangordon | LMK if you need help | 17:58 |
| Wizzup | *nod* | 17:58 |
| freemangordon | though I am on osso-abook | 17:58 |
| bencoh | Wizzup: you might want to check /etc/pulse/xpolicy.conf on fremantle | 17:59 |
| freemangordon | bencoh: and there is more to that, in /var/lib IIRC | 17:59 |
| Wizzup | bencoh: I have a tar of all the files on my ssd I think | 18:00 |
| bencoh | /var/lib/pulse{,-nokia} yeah | 18:01 |
| freemangordon | so, if I get that right, each sink has 2 user-defined properties that are used by volume applet | 18:01 |
| freemangordon | first is for volume steps when not in call, the second - when in call | 18:01 |
| Wizzup | I believe so | 18:01 |
| freemangordon | that's what we shall somehow recreate, at least in terms of volume applet | 18:01 |
| bencoh | at least that's how it behaves from a user pov | 18:02 |
| freemangordon | not only from user POV, see the code | 18:02 |
| freemangordon | https://github.com/maemo-leste/maemo-statusmenu-volume/blob/master/src/item.c#L1046 | 18:02 |
| bencoh | ah :) | 18:02 |
| freemangordon | I REed that, yeah :) | 18:03 |
| bencoh | :) | 18:03 |
| freemangordon | so, we ahve a properties, which are list of volumes in dB | 18:03 |
| freemangordon | and when a sink becomes active (?) the applet uses those properties to tune it's slider number of steps and to set the output volume based on the current step | 18:04 |
| freemangordon | taking in consideration if we are n call or not | 18:05 |
| Wizzup | yes | 18:05 |
| freemangordon | *in | 18:05 |
| freemangordon | the particular values for n900 are in /var/lib/... IIRC | 18:06 |
| bencoh | freemangordon: wait, don't tell me the status applet is actually the one changing the output volume once the call stats | 18:06 |
| bencoh | starts* | 18:06 |
| freemangordon | yes, it is | 18:06 |
| freemangordon | IIUC | 18:06 |
| bencoh | :'( | 18:06 |
| Wizzup | bencoh: what should do it in your opinion? | 18:06 |
| bencoh | I dunno, but definitely not some UI element | 18:07 |
| freemangordon | why is that an issue? | 18:07 |
| freemangordon | it is not really UI element | 18:07 |
| bencoh | from a logical pov, it sounds kinda ... broken | 18:07 |
| freemangordon | UI is just on top of its core functionality | 18:07 |
| freemangordon | and its core functionality is to change the volume :p | 18:07 |
| Wizzup | bencoh: I mean, something has to map keyboard key to pulse actio | 18:08 |
| Wizzup | n | 18:08 |
| Wizzup | and it's not pulse that does this | 18:08 |
| bencoh | I don't expect status applet to take any active part in the actual system, only to allow me to interact with it | 18:08 |
| bencoh | but ... meh | 18:08 |
| Wizzup | mhm | 18:08 |
| freemangordon | bencoh: and who is supposed to do the actual volume change? | 18:08 |
| freemangordon | shall we teach PA on calls? | 18:09 |
| bencoh | no idea, tbf | 18:09 |
| freemangordon | my stance is - Nokia did it like that, unless we have some strong evidence it can be done better, lets not reinvent the wheel :) | 18:10 |
| bencoh | I'd have expected telepathy / the telephony framework / the phone app to notify pulseaudio and switch output/volume, but ... | 18:10 |
| freemangordon | oh I'd say this is even worse | 18:11 |
| bencoh | freemangordon: yeah, I'm not really arguing about what we should do tbh | 18:11 |
| freemangordon | application should not control things like volume IMO | 18:11 |
| bencoh | but I think we had a similar discussion back at some point (when you RE-ed maybe? or it was another piece of software) | 18:11 |
| freemangordon | could be | 18:11 |
| freemangordon | don;t really remember | 18:11 |
| bencoh | me neither, until now | 18:12 |
| bencoh | anyway, I don't really have a better idea for now, so ... | 18:12 |
| bencoh | :) | 18:12 |
| freemangordon | :) | 18:13 |
| bencoh | is pulseaudio in the same state than back in fremantle days? or does it have new abstractions we could benefit from? | 18:13 |
| freemangordon | see https://github.com/maemo-leste/maemo-statusmenu-volume/blob/master/src/item.c#L1237 | 18:13 |
| freemangordon | no f..ing idea | 18:13 |
| freemangordon | PA is not something I am good in | 18:13 |
| bencoh | freemangordon: that function is fine, because it basically acts upon user request | 18:14 |
| freemangordon | but the result of it is based on whether we are in call or not | 18:14 |
| freemangordon | no volume is changed otherwise (without user action) | 18:15 |
| bencoh | that's the part that bothered me I think: https://github.com/maemo-leste/maemo-statusmenu-volume/blob/master/src/item.c#L1237 | 18:15 |
| bencoh | (assuming I understand what it does) | 18:15 |
| freemangordon | yes, but I don;pt understand why you have issues with it | 18:15 |
| bencoh | basically receive a "on call" signal, update the slider accordingly, and change the volume | 18:15 |
| freemangordon | oh, no | 18:16 |
| bencoh | ? | 18:16 |
| freemangordon | 'on call' signal just sets the call_active variable | 18:16 |
| bencoh | hmm | 18:16 |
| freemangordon | so the next time user changes the volume, the appropriate list ov volumes is used | 18:16 |
| freemangordon | nothing happens without user interaction, IIUC | 18:17 |
| bencoh | then who switches the volume to the proper value when I answer a call? | 18:17 |
| freemangordon | 'stream restore' functionality IIUC | 18:17 |
| freemangordon | that's PA thing | 18:17 |
| bencoh | ah | 18:17 |
| freemangordon | because you change the output sink | 18:17 |
| bencoh | then it's fine | 18:17 |
| bencoh | (design-wise) | 18:18 |
| freemangordon | take everything I say about PA with a grainof salt though | 18:18 |
| freemangordon | but I believe this is what happens | 18:18 |
| bencoh | at least it makes sense | 18:18 |
| bencoh | (and it's much nicer than what I understood at first :) ) | 18:19 |
| freemangordon | see https://github.com/maemo-leste/maemo-statusmenu-volume/blob/master/src/item.c#L615 | 18:19 |
| freemangordon | if I read that correctly, on 'stream restore' volume slider is modified to account for the new volume applied by PA | 18:19 |
| * bencoh nods | 18:20 | |
| freemangordon | BTW Nokia introduced "stream_restore_2" which was not upstreamed, but I was not able to understand what are the differences | 18:21 |
| Wizzup | nemo has the same | 18:21 |
| Wizzup | https://git.sailfishos.org/mer-core/pulseaudio-modules-nemo/tree/master/src | 18:21 |
| Wizzup | stream-restore-nemo | 18:21 |
| bencoh | it's funny how they really patched the whole ecosystem to make that phone work :) | 18:22 |
| bencoh | (and I have to admit it's a great piece of work in the end) | 18:22 |
| freemangordon | :) | 18:22 |
| uvos | the patches are partially very hacky tho | 18:22 |
| freemangordon | Wizzup: maybe we will need that too | 18:22 |
| uvos | not that i blame them | 18:22 |
| bencoh | uvos: yeah, but still :) | 18:23 |
| uvos | they where loosing the war with android and with the symbian /wimo devision | 18:23 |
| uvos | so im sure they where under duress | 18:23 |
| freemangordon | the war with android was not even started by then | 18:23 |
| sicelo | actually maemo had nothing to do with android :) | 18:23 |
| sicelo | it's symbian that was fighting | 18:24 |
| uvos | well yes it did | 18:24 |
| freemangordon | there was simply no android :) | 18:24 |
| uvos | android was around | 18:24 |
| uvos | so it was a competitor | 18:24 |
| bencoh | it was more symbian/iOS back then; android was around, but still pretty infant | 18:24 |
| freemangordon | mhm | 18:24 |
| uvos | the d1 came out around the same time | 18:24 |
| uvos | and was a huge sucess sales wise | 18:24 |
| freemangordon | 2009? | 18:24 |
| uvos | yes | 18:24 |
| bencoh | "with the first commercial Android device, the HTC Dream, being launched in September 2008" | 18:24 |
| sicelo | uvos: seriously. maemo fremantle had nothing to do with android. in fact, it was even struggling to make a case against symbian itself, let alone android. anyway | 18:24 |
| freemangordon | because the code in question was *finished* 2009 | 18:24 |
| uvos | sure | 18:25 |
| bencoh | yeah, android was an infant :) | 18:25 |
| uvos | sure ok but "compettion" | 18:25 |
| uvos | the iphone for sure | 18:25 |
| freemangordon | not really | 18:25 |
| uvos | come one | 18:25 |
| freemangordon | it was internal competition in Nokia | 18:25 |
| uvos | the fremantle ui apes the iphone | 18:25 |
| freemangordon | with symbian | 18:25 |
| bencoh | iphone 3/3gs was its direct "competitor" (of at all) | 18:25 |
| bencoh | (if* at all) | 18:25 |
| Wizzup | yeah nokia messed up internally a lot as well | 18:25 |
| freemangordon | well, n900 was anno9unced as iphone killer :D | 18:25 |
| freemangordon | *announced | 18:25 |
| freemangordon | which it was really back then | 18:26 |
| bencoh | honestly, it might have been, if not for ... pretty much everything, apart from the technical aspect | 18:26 |
| uvos | freemangordon: practicaly maybe | 18:26 |
| uvos | comertially? no | 18:26 |
| freemangordon | despite that, I know lots of wealthy people who bought n900 back then | 18:26 |
| uvos | sure | 18:26 |
| freemangordon | but it was Nokia who screw it | 18:26 |
| bencoh | same, and I still come across people that tell me they had one at some point | 18:26 |
| freemangordon | mhm | 18:27 |
| uvos | but no doubt of the big phones sold in 2009: the d1 the n900 and the iphone | 18:27 |
| freemangordon | not technical guys | 18:27 |
| uvos | the n900 did worst | 18:27 |
| Wizzup | I had people tell me they had the phone way back when.... but they saw my d4 with leste and though it was n900 with fremantle ;) | 18:27 |
| freemangordon | :D | 18:27 |
| bencoh | haha | 18:27 |
| uvos | he | 18:27 |
| freemangordon | ok, I am back to osso-abook | 18:27 |
| bencoh | :) | 18:27 |
| uvos | Wizzup: did you change anything with qt5 | 19:54 |
| uvos | or the calculator app? | 19:54 |
| uvos | btw im very sure that fremantle takes inspiration from android 1.0 i mean look at os2008 and fremantle and a1.0 | 19:56 |
| uvos | but its not important | 19:56 |
| uvos | anyhow calculator app: theming is broken again | 19:56 |
| uvos | the text box is white now for some reason | 19:57 |
| uvos | so no input can be seen | 19:57 |
| Wizzup | uvos: I don't think I changed anything | 20:01 |
| uvos | hmm | 20:01 |
| uvos | i dident either local | 20:01 |
| uvos | *localy | 20:01 |
| uvos | the hildon preeview is even still right | 20:02 |
| uvos | coult you check on your device? | 20:02 |
| Wizzup | yeah same for me | 20:04 |
| Wizzup | interesting | 20:04 |
| uvos | hmm wierd | 20:04 |
| Wizzup | maybe some pkg was promoted or something | 20:08 |
| uvos | promoted? | 20:08 |
| uvos | by debian you mean | 20:08 |
| uvos | (as we are on devel for us ofc) | 20:08 |
| uvos | yeah maby a qt5 change in debian caused this | 20:09 |
| stan | calculator could be a candidate to add to default image | 20:09 |
| stan | or is it too different | 20:10 |
| Wizzup | it's very similar | 20:10 |
| stan | then will you include it? | 20:11 |
| sicelo | stan: isn't it already there by default? | 20:15 |
| Wizzup | https://github.com/maemo-leste/hildon-meta/blob/master/debian/control#L48 | 20:15 |
| stan | not in the device i have running now. maybe in the newer image | 20:23 |
| uvos | stan: if it dident install with updateing | 20:24 |
| uvos | you dont have the metapackage installed | 20:24 |
| uvos | which is bad | 20:24 |
| stan | it's in the newer image, sorry | 20:25 |
| uvos | it should be in _any_ image | 20:25 |
| uvos | if you updated it half way recently | 20:25 |
| uvos | if its not your image is broken (its missing the metapackage at least) | 20:25 |
| Wizzup | you probably just removed it | 20:25 |
| uvos | the metapackage also dissapeard on an update for me too btw | 20:27 |
| uvos | i think something was conflicting at some point | 20:27 |
| uvos | that was very long ago tho | 20:27 |
| stan | is there a forseeable way we could set system languages we want supported on our device, then prevent apt from downloading every translation available? e.g. 71-osso-pdf-viewer-l10n-zhhk 72-osso-pdf-viewer-l10n-zhcn | 21:42 |
| Wizzup | no | 21:43 |
| uvos | tmlind: any idea what the difference between mbmloader_hs.bin and mbmloader_ns.bin is? | 21:59 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/mce/pull/50 (Move to new build system: cmake) | 22:25 |
| uvos | Wizzup: ^^^ "" <> braket thing remove | 22:26 |
| uvos | d | 22:26 |
| lel | IMbackK closed an issue: https://github.com/maemo-leste/mce/issues/28 (Mce should not depend on maemo) | 22:27 |
| lel | IMbackK closed an issue: https://github.com/maemo-leste/mce/issues/23 (iio-als: do something with the iio-sensor-proxy "unit" prop) | 22:27 |
| lel | IMbackK opened an issue: https://github.com/maemo-leste/mce/issues/51 (Doxygen documentation for mce-dev) | 22:29 |
| Wizzup | uvos: ok, I think I'll also want to ask fmg to take a look, but let's see if we can try to get it merged this week | 22:42 |
| Wizzup | I guess this just replaces nokia-voice modules https://git.sailfishos.org/mer-core/pulseaudio-modules-nemo/tree/master/src/voice | 22:51 |
| stan | power use with wlan on, screen off is good but RET keeps increasing d=2021-07-05|t=23:07:54|i=OFF:0,RET:3646|p=133|c=NA|b=none | 23:08 |
| stan | 3646 in 8 minutes | 23:09 |
| uvos | so? | 23:10 |
| uvos | thats normal | 23:10 |
| uvos | maybe a tiny tad high | 23:10 |
| uvos | if your uptime is just 8minutes its low even | 23:10 |
| uvos | the count is pretty meaningless anyhow | 23:13 |
| stan | happy i don't need to unload modules | 23:13 |
| uvos | as it tells you nothing about how mutch time the device spent in ret | 23:13 |
| stan | would disabling the phone modem save power? | 23:13 |
| stan | ok | 23:13 |
| stan | it seems still tied to the snd_ playback | 23:14 |
| uvos | not loading motmdm modules dose reduce power consumption some | 23:14 |
| uvos | as dose not loading cpcap_phy | 23:14 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!