| Wizzup | uvos: what do you need that libgofono does not support? | 01:23 |
|---|---|---|
| uvos | Wizzup: org.ofono.VoiceCallManager org.ofono.MessageManager org.ofono.PushNotification | 09:50 |
| uvos | Wizzup: libgofono is geard to and only supports ofono usage for mobile data | 09:50 |
| uvos | Wizzup: and sphone uses dbus-glib, which is deprecated | 09:50 |
| uvos | Wizzup: so im probubly going to have to port it to gdbus | 09:51 |
| uvos | Wizzup: https://github.com/caiwenzh/libofono helps, i can pull lots of code from there | 09:51 |
| uvos | Wizzup: and is acctually supports the stuff we would need | 09:52 |
| lel | parazyd created a repository: https://github.com/maemo-leste/libtrace-ohm | 10:00 |
| lel | parazyd edited a repository: https://github.com/maemo-leste/libtrace-ohm | 10:01 |
| Wizzup | uvos: we did go for libgofono for various reasons | 10:59 |
| Wizzup | let me try to remember | 10:59 |
| Wizzup | uvos: but if this works well we could look at it, I am not sure if it supports as much as libgofono | 11:18 |
| Wizzup | uvos: but also libgofono is what sailfish os uses, so if we collaborate, that might be better | 11:18 |
| Wizzup | uvos: have you considered just trying to port it to the telepathy interface to use ring instead? there might be better bindings for it | 11:19 |
| uvos | libgofono supports essentally nothing | 11:19 |
| uvos | seriously | 11:19 |
| Wizzup | we've already tested ring to work as far as I know | 11:19 |
| Wizzup | uvos: I think I mostly haven't run into limitations yet, but that was not doing phone call stuff | 11:19 |
| Wizzup | uvos: as in, this works: https://wizzup.org/leste-sms-telepathy-ring-1.png | 11:19 |
| uvos | Wizzup: ok no idea about telephathy | 11:20 |
| Wizzup | it's what we'd like to use in the (near) future | 11:20 |
| Wizzup | I think this might be using TP (not sure) https://github.com/DigitalHERMES/rhizo-dialer | 11:20 |
| Wizzup | oh, I guess it doesn't | 11:21 |
| Wizzup | but it has some code for it | 11:21 |
| uvos | it uses at commands directly | 11:22 |
| uvos | mostly usesless on a qmi modem | 11:22 |
| Wizzup | yes | 11:22 |
| Wizzup | but it has a tp.c :) | 11:22 |
| Wizzup | in any case, feel free to pick any direction, but I'd be personally more interested in the TP path | 11:23 |
| Wizzup | since that means we could use the sphone also for e.g. sip calls | 11:23 |
| Wizzup | parazyd: so libtrace is fixed, I guess we can make ohm build with that now? | 11:23 |
| Wizzup | ok so policy-settings-basic/ contains ohmd.ini | 11:32 |
| Wizzup | ah libprolog is a sailfish/nokia thing | 12:18 |
| Wizzup | it's supposedly LGPL but I can't find the source | 12:23 |
| Pali | Wizzup: it was closed in Maemo, but open-sourced in Harmattan | 12:24 |
| Pali | I remember that sources were on meego.gitorious.org website | 12:25 |
| Pali | it was here: https://gitorious.org/maemo-multimedia/prolog.git | 12:26 |
| Wizzup | Pali: sailfish/mer and nemo use it, so I imagine it's open source | 12:28 |
| Pali | yes, it is open source... just gitorious.org is down forever... | 12:28 |
| Wizzup | Pali: ok, but sailfish CI must build it from somewhere | 12:33 |
| Pali | good point... so there should be some public repo | 12:33 |
| Pali | https://wiki.merproject.org/wiki/SailfishOSS | 12:36 |
| Wizzup | yes, it says it's LGPL | 12:36 |
| Wizzup | but has no link | 12:36 |
| Pali | libprolog - LGPLv2.1 - but missing link to git | 12:37 |
| Wizzup | I think I'll drop Juho another email and see if he has a pointer | 12:37 |
| Wizzup | I need to work on the tor stuff later today anyway | 12:38 |
| Pali | and has Juho replied to your email? | 12:38 |
| Wizzup | he replied that he was on vacation before and would reply when he had time, and told me to ping him after a few days | 12:39 |
| Wizzup | so I suppose now is a fair time to write a brief second email | 12:40 |
| Pali | ok... | 12:40 |
| Pali | tada! here is repo: https://git.sailfishos.org/mer-core/libprolog | 12:40 |
| Pali | "Archived project! Repository and other project resources are read only" | 12:40 |
| Pali | but it was already moved somewhere | 12:41 |
| Wizzup | huh, I am sure I searched for that | 12:41 |
| Wizzup | https://github.com/sailfishos/libprolog | 12:41 |
| Wizzup | it's moved here then | 12:41 |
| Wizzup | I'm so confused | 12:41 |
| Wizzup | Pali: thanks!! | 12:42 |
| Pali | and another link: https://github.com/nemomobile/libprolog | 12:42 |
| Pali | so looks like ping-pong move between github and gitlab | 12:42 |
| Wizzup | I tihnk generally the latest github.com/sailfishos is where the mer stuff moved | 12:43 |
| Wizzup | they merged that a while ago | 12:43 |
| Wizzup | ok, it builds | 12:43 |
| Wizzup | (libprolog) | 12:43 |
| Wizzup | I'll add the debian packaging then | 12:43 |
| Pali | also see http://wiki.maemo.org/Fremantle_closed_packages | 12:44 |
| Pali | maemo 5 version of libprolog is here: https://github.com/maemo-foss/maemo-multimedia-prolog/tree/6feb212f9b720caa57ddffb935e3f3ac47f4a4e0 | 12:44 |
| Wizzup | I'll probably go for the sfos one since we use the other parts of their stack too | 12:45 |
| Wizzup | we should figure out how to effectively make a mirror/backup of all of this | 12:45 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/libprolog | 12:56 |
| Wizzup | we also need https://github.com/sailfishos/libdres-ohm | 19:00 |
| Wizzup | ... :-) | 19:00 |
| Wizzup | also https://github.com/sailfishos/ohm-plugins-misc | 19:10 |
| Wizzup | and https://github.com/sailfishos/ohm-rule-engine | 19:10 |
| freemangordon | Wizzup: won't have time to check PRs today, want to finish OssoABookContactEditor first. However, will review them ASAP. | 19:40 |
| Wizzup | freemangordon: ok, thanks | 19:44 |
| Wizzup | this audio stuff is a lot of packages | 19:44 |
| Wizzup | easily 10+ | 19:44 |
| Wizzup | win 45 | 20:11 |
| Wizzup | oops | 20:11 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/libdres-ohm | 20:12 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/policy-settings-common | 20:22 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/ohm-rule-engine | 20:32 |
| Wizzup | can't wait for this to work & be finished | 20:51 |
| Wizzup | heh | 20:51 |
| Wizzup | parazyd: do you know how I can add an empty directory in a .deb pkg? | 21:02 |
| lel | MerlijnWajer edited a repository: https://github.com/maemo-leste/policy-settings-common | 21:07 |
| Wizzup | parazyd: when you have a moment pls look at policy-settings-common debian packaging, I don't know how to create the 'current' dir that the rpc/*.spec file makes | 21:08 |
| Wizzup | parazyd: that is in debian/policy-settings-common-text.install | 21:08 |
| Wizzup | parazyd: also the .spec file defines the .dres files for both packages | 21:09 |
| Wizzup | I think the .dres file should go in the -text only | 21:10 |
| Wizzup | also, we need an initscript for ohmd ;) | 21:12 |
| Wizzup | ok, just ohm-plugins-misc remains, I think I will do that another day | 21:17 |
| uvos | Wizzup: just use install ? | 21:32 |
| Wizzup | uvos: where, in rules file?? | 21:43 |
| uvos | just postinst | 21:43 |
| uvos | (note im no deb wizzard its just what i would do) | 21:44 |
| Wizzup | yeah | 21:44 |
| Wizzup | well I spent too many hours today doing packaging | 21:44 |
| Wizzup | I'll look at with a fresh mind tomorrow | 21:44 |
| Wizzup | I think once all of this is there, I can try it on the n900 | 21:44 |
| uvos | try what exactly? | 21:44 |
| uvos | tha audo setup from nemo? | 21:44 |
| Wizzup | yes, so hopefully we can get most of it to work, whih is: | 21:46 |
| Wizzup | 1. volume applet | 21:46 |
| Wizzup | 2. policy routing based on system state (hp plugged in, etc) | 21:46 |
| Wizzup | 3. call audio routing (if any) | 21:46 |
| Wizzup | and probably loads of other stuff I forget | 21:46 |
| uvos | ok cool | 21:46 |
| Wizzup | I don't think it works *yet) with ucm, so that will be for another time | 21:46 |
| uvos | i gues n900 because the backend stuff is hardcoded for n900 mixers | 21:47 |
| Wizzup | which is why I'd probably start with the n900 | 21:47 |
| uvos | ok | 21:47 |
| Wizzup | yeah because there are n900 files from nemo | 21:47 |
| Wizzup | I don't know if we also still need https://github.com/spinal84/alsa-policy-enforcement/ | 21:47 |
| Wizzup | I think probably not | 21:47 |
| Wizzup | uvos: for the d4, being able to detect the hp plug would be required I think though | 21:49 |
| uvos | not gonna happen | 21:49 |
| uvos | in any resonable timeframe | 21:49 |
| Wizzup | hm, not sure how we'll have to deal with that in the policy then | 21:49 |
| Wizzup | well, first things first I guess | 21:50 |
| uvos | its still a total mystery how the d4 hardware / the android kernel even detects the hp | 21:50 |
| uvos | it just talks with the cpcap firmware to enable routing and it dose everything itself | 21:51 |
| uvos | but somehow the hp isent connnected to any cpcap gpio either | 21:51 |
| Wizzup | do you think it could be worth asking sre? | 21:51 |
| uvos | so no idea how the fw even knows | 21:51 |
| uvos | Wizzup: well i asked sre about the audio problem like 2 months ago and he is totaly mia | 21:51 |
| uvos | also he dosent know i suspect | 21:51 |
| sicelo | asked him via email? | 21:54 |
| uvos | sicelo: yeah | 21:54 |
| uvos | the mc13783 datasheet also isent helpfull | 21:55 |
| uvos | as it dosent have the features used by the android kernel for hp | 21:55 |
| Wizzup | I haven't looked at the kernel much, does it report/print anything upon plug in dmesg or so? | 21:55 |
| uvos | no | 21:55 |
| uvos | it cant no omap4 gpio or cpapgpio changes | 21:55 |
| uvos | it has no possible source for the information | 21:56 |
| uvos | and mc13783 dosent have the stuff the android kernel uses (namely the uc/ rtos) | 21:56 |
| Wizzup | but alsa on android knows? | 21:56 |
| uvos | androids sound layer knows yeah | 21:56 |
| uvos | it gets it passed by the rtos in the mailbox system i think (at least it gets a message at the same time) | 21:57 |
| uvos | the rtos fw somehow reads the state | 21:57 |
| uvos | no idea how | 21:57 |
| uvos | so either you have to implement the rtos fw uploading and all the cpcap-uc handling stuff | 21:59 |
| uvos | (lots of work ergo not any time soon) | 21:59 |
| uvos | or you have to figure out where the hell the fw is sourceing this infomation | 21:59 |
| Wizzup | ok | 22:01 |
| Wizzup | well I don't know how we can work around it, but we'll figure it out later on I guess | 22:01 |
| uvos | i can now use sphone to place a call | 22:07 |
| uvos | (but nothing else works) | 22:07 |
| Wizzup | cool | 22:07 |
| Wizzup | what lib do you end up using? | 22:08 |
| uvos | just reimplmenting the calls with gdbus | 22:08 |
| uvos | its by far the easiest way atm | 22:08 |
| Wizzup | okay | 22:08 |
| Wizzup | it looks like even the audio policy routing relies on telepathy | 22:08 |
| Wizzup | e.g. | 22:09 |
| Wizzup | call_prefix(cellular, '/org/freedesktop/Telepathy/Connection/ring/tel/ring/'). | 22:09 |
| uvos | hmm thats not so great | 22:09 |
| Wizzup | call_prefix(skype , '/org/freedesktop/Telepathy/Connection/spirit/skype/'). | 22:09 |
| Wizzup | call_prefix(gtalk , '/org/freedesktop/Telepathy/Connection/gabble/jabber/'). | 22:09 |
| Wizzup | it's how it works in maemo and nemo/mer/sailfish | 22:09 |
| uvos | hmm | 22:09 |
| uvos | seams kinda excessive | 22:09 |
| Wizzup | I can't comment on how it works at all, since I don't know | 22:10 |
| Wizzup | (yet) | 22:10 |
| Wizzup | but it seems pretty likely we'll want to use thos code | 22:11 |
| Wizzup | s/thos/this/ | 22:11 |
| Wizzup | that's also why I suggested going the tp route | 22:11 |
| uvos | im still not sure why there is not just several modes with different pa streams associated to them and an app can ask for a stream | 22:11 |
| Wizzup | that might also work | 22:11 |
| uvos | and then depending on the mode the other streams are paused | 22:11 |
| Wizzup | I just looked at some of the policy files just now | 22:11 |
| uvos | and the volume is restored depending on what mode was enterd | 22:11 |
| Wizzup | could be | 22:12 |
| Wizzup | but it has different routing for ip calls than normal calls, etc, so it has to know | 22:12 |
| Wizzup | it can't just be a "phone" property somewhere in pa | 22:12 |
| Wizzup | somewhere in a pa stream | 22:12 |
| uvos | sure so have a 4th stream mode for ip calls | 22:12 |
| uvos | sure so have a 4th stream/mode for ip calls | 22:12 |
| uvos | i think tieing the entire audio setup to some implmentation of a comunications framework is a misstake | 22:13 |
| uvos | less is more here | 22:13 |
| uvos | but thats just imo | 22:13 |
| Wizzup | all I know is that I like what maemo does, and we need something, and sailfish is maemo stack but foss | 22:13 |
| Wizzup | I can't comment on how it works technically really | 22:13 |
| uvos | thats a problem in and of itself | 22:14 |
| Wizzup | but I do know that this is a solid path to get us to something works is proven to work | 22:14 |
| uvos | but ok | 22:14 |
| Wizzup | uvos: I didn't say I wouldn't know at some point | 22:14 |
| uvos | sure | 22:14 |
| Wizzup | uvos: it's like 10+ repos with a lot of prolog and C code | 22:14 |
| uvos | right | 22:14 |
| uvos | another problem in and of itself | 22:14 |
| uvos | :) | 22:14 |
| Wizzup | problems that lead to a solution :p | 22:14 |
| uvos | well its jour department | 22:15 |
| sicelo | "tieing the entire audio setup to some implmentation of a comunications framework" < no. it's not like that. the communications framework is in charge of exactly communications. other audio issues are not handled by tp at all (e.g. music playback) | 22:15 |
| uvos | sicelo: well the audo setup forces the communications framework to be tp forever | 22:16 |
| uvos | you cant swap out tp for ex the telegram-desktop app and place a ip call with that | 22:16 |
| Wizzup | yeah it's just pa doing the audio core, and then ohmd does all the routing policy (through some pa module to be able to do certain things) and then userspace can request audio features | 22:16 |
| uvos | if its just a specal stream for ip calls | 22:16 |
| Wizzup | uvos: that is my guess, it's not clear that that is true | 22:16 |
| sicelo | you can | 22:16 |
| uvos | then you could route the telegram app to use that that stream | 22:16 |
| uvos | and everything works | 22:16 |
| Wizzup | but just for the record our aim *is* to use tp for everything if we can | 22:17 |
| uvos | if pulse reads some special tp proparties and descides what to do based on that | 22:17 |
| uvos | then its a problem | 22:17 |
| Wizzup | no, pulse doesn't do that, ohm does | 22:17 |
| Wizzup | as I understand it | 22:17 |
| uvos | sure pulse ohm whatever | 22:17 |
| Wizzup | I'm sure you could extend to policy if it doesn't do what you want yet | 22:17 |
| uvos | point is the audio streams etc arnt configured correctly if i replace tp with some other app | 22:17 |
| Wizzup | but for example this also deals with emergency calls | 22:17 |
| Wizzup | uvos: well, I can't argue with that point because I do not know if that is the case | 22:18 |
| sicelo | :) | 22:18 |
| uvos | i dont either | 22:18 |
| Wizzup | :D | 22:18 |
| uvos | but that was wat i gatherd from the above | 22:18 |
| uvos | "but just for the record our aim *is* to use tp for everything if we can" maybe but tp wont and cant provide all the features of the native apps | 22:18 |
| sicelo | look, you can run your telegram just fine while the maemo tp stuff is in place. | 22:18 |
| Wizzup | it's 3.5k of prolog code (the basic policies) | 22:18 |
| uvos | so peapole will allways want to use the native apps | 22:19 |
| uvos | sicelo: maybe but when i get a call with the vollume be right? | 22:19 |
| sicelo | Wizzup is talking about the leste stuff. it doesn't prevent use of native anything | 22:19 |
| Wizzup | uvos: I agree it might not offer all the features, but I don't agree that that is what folks want | 22:19 |
| Wizzup | :p | 22:19 |
| Wizzup | uvos: it might be fine if it uses the standard pulseaudio phone property thing | 22:19 |
| uvos | sicelo: will the notifications be on the right volume? | 22:19 |
| Wizzup | we won't know until we have it in place | 22:19 |
| uvos | etc | 22:19 |
| sicelo | we were using linphone on n900 without any issues, even though that was not doing tp | 22:19 |
| uvos | "<Wizzup> uvos: it might be fine if it uses the standard pulseaudio phone property thing" ok but if we can use that and it works why dont we use the modern pa mechansums for exactly this + stream silencing etc instead of the neamo setup | 22:21 |
| uvos | not saying there is no reason | 22:21 |
| uvos | but we should know this kind of thing beforhand... | 22:21 |
| Wizzup | there is no phone that uses plain pa and works sensibly as far as I know | 22:22 |
| Wizzup | but the sailfish stuff does | 22:22 |
| Wizzup | and it's what maemo did | 22:22 |
| Wizzup | pulseaudio itself is not powerful enough to do many of the things we want to be able to do | 22:23 |
| uvos | thats insufficant for me sorry, anyhow im not really helping here, as i say its your department. | 22:23 |
| Wizzup | plus, this setup should give us audio on n900 voice calls | 22:23 |
| Wizzup | uvos: I think we both have waaaay to little knowledge of this to make any determination | 22:24 |
| uvos | right | 22:24 |
| dreamer | (ppst, pipewire kopen?) | 22:24 |
| uvos | shutup | 22:24 |
| uvos | :D | 22:24 |
| Wizzup | I'm simply taking the tested and proven path that also happens to support some of our more sophisted devices wrt audio routing | 22:24 |
| uvos | switching to pupewire just adds more complication we dont need atm :P | 22:24 |
| Wizzup | I think that makes the most sense since we don't have the resources to re-do all the work and it's foss | 22:24 |
| uvos | Wizzup: its fine, i dont have to like it | 22:25 |
| Wizzup | if it doesn't make sense, well then I spent a week packaging and understanding it, not the end of hte world | 22:25 |
| uvos | sure | 22:25 |
| Wizzup | I want to get to a point where it works and we can actually evaluate it | 22:25 |
| uvos | ok | 22:25 |
| uvos | not totaly insane i gues | 22:25 |
| Wizzup | my bet is that it'll actually work out quite ok, and I hope that the main challenge will be supporting ucm | 22:27 |
| Wizzup | plus it'll get us the other maemo bits like volume applet and such | 22:27 |
| Wizzup | uvos: but that's nice progress @ sphone | 22:33 |
| uvos | thanks | 22:43 |
| Wizzup | I think some things will come together this year :) | 22:45 |
| Wizzup | it might very well be audio + calls + telepathy/conversations + contacts | 22:46 |
| freemangordon | Wizzup: Re volume applet - someone (me?) shall port it to stream-restore-nemo once we have it | 22:51 |
| Wizzup | freemangordon: we'll see if that's required, it might just be the same | 22:52 |
| Wizzup | or is there still code missing | 22:52 |
| uvos | sms works | 22:53 |
| freemangordon | IIRC the diff between stream-restore and stream-restore2 was that latter supports both absolute and relative volume while former supports absolute only | 22:54 |
| Wizzup | ok | 22:55 |
| Wizzup | ah, we also need https://github.com/sailfishos/libresource | 22:55 |
| Wizzup | (i think) | 22:56 |
| uvos | btw any idea what the point is of declaring a function extern in header | 22:59 |
| uvos | like this "extern int ofono_call_hangup(gchar *path);" | 22:59 |
| uvos | all functions that arnt static are effectively extern no? | 23:00 |
| uvos | am i missing something? | 23:00 |
| sicelo | yes on droid 4 everything works, except USSD. i once made a basic hildon thing in python to handle incoming calls and smses via ofono dbus | 23:01 |
| sicelo | maybe USSD works now. not sure | 23:01 |
| uvos | call audio works only on external speaker | 23:01 |
| sicelo | or it worked, but there was no reply ... can't remember anymore | 23:01 |
| uvos | unles you have hack applied | 23:01 |
| uvos | (like i do) | 23:01 |
| sicelo | i stopped working on the application because it sounded like we only wanted tp | 23:02 |
| uvos | ok | 23:02 |
| uvos | sicelo: also i assume you where replieing to this "sms works" | 23:02 |
| uvos | i ment sms works in sphone | 23:03 |
| uvos | not d4 in general | 23:03 |
| Wizzup | how are you testing? | 23:03 |
| sicelo | yes i was replying to that. sms doesn't work on d4 now? | 23:03 |
| uvos | yes it dose | 23:03 |
| uvos | and i just implmented the interface in sphone | 23:03 |
| uvos | so it works | 23:03 |
| uvos | Wizzup: i sent myself a sms | 23:04 |
| sicelo | actually works on all leste phones | 23:04 |
| uvos | Wizzup: and for calls i call a automatic customer service thing from the provider | 23:04 |
| Wizzup | ah, check | 23:04 |
| Wizzup | uvos: so testing on the d4? | 23:05 |
| uvos | yeah | 23:05 |
| uvos | btw can re fix sapwood-engine-WARNING **: 23:08:56.000: sapwood-theme: Failed to load pixmap file /usr/share/themes/marina/images/qgn_plat_separator_horizontal_paned.png: Failed to connect to sapwood server using `/var/tmp/sapwood-:0': Connection refused | 23:09 |
| uvos | somehow | 23:09 |
| uvos | sphone hits this manny times | 23:09 |
| uvos | makeing its output really hard to read | 23:09 |
| Wizzup | how do you spawn it | 23:10 |
| Wizzup | and as what user | 23:10 |
| uvos | user | 23:10 |
| Wizzup | over ssh? | 23:10 |
| uvos | just ./sphone over ssh yeah | 23:10 |
| Wizzup | try maybe source /etc/profile or something | 23:10 |
| Wizzup | I think it's just missing some env stuff | 23:10 |
| uvos | that dident help | 23:11 |
| uvos | yeah launched on device it dosent happen | 23:12 |
| Wizzup | maybe diff the env from device shell and ssh shell | 23:12 |
| uvos | hmm its not obvious when looking at printenv after sourceing the profile | 23:15 |
| uvos | anyhow ill quit there for today | 23:15 |
| uvos | with some luck ill have sphone working as intended by next weak | 23:15 |
| Wizzup | \o/ | 23:16 |
| Wizzup | uvos: when you restart just run 'env | sort > /tmp/1.txt' and diff it | 23:17 |
| Wizzup | with ssh vs phone | 23:17 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/libicd-network-tor | 23:17 |
| Wizzup | (ofc do not write to the same file twice) | 23:18 |
| Wizzup | uvos: hm it could also be some x auth stuff but seems unlikely | 23:18 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
