| piggz[m] | Mal: an idea... I wonder, would you be able to summarise a list of files/dbus-interfaces/additions that sailfish needs ontop of ofono (ignoring drivers/ril) .... I wonder if its easier to maintain a fork of them ontop of upstream for the pp modem? | 07:05 |
|---|---|---|
| piggz[m] | Hi @rainemak... I know youre busy, but pine asked me again today :) | 07:46 |
| norayr | i would build dino for sailfish... but to install the sdk i need vm with wayland... so it is complicated. | 11:03 |
| norayr | someone please build dino? | 11:03 |
| mal | what is that dino? | 11:07 |
| mal | based on what I see, that is based on gtk which would make it difficult | 11:09 |
| norayr | mal, oh, why? | 13:57 |
| norayr | gtk supports wayland. | 13:58 |
| norayr | so gtk program should work natively in sailfish. no? | 13:58 |
| norayr | we don't have a good xmpp client in sailfish. and dino is very good for mobile. its newest development targets mobile and it works under other mobile systems very well. | 13:59 |
| norayr | very convenient. | 13:59 |
| mal | wayland is not the issue, sailfish doesn't have gtk packages, you would have to package all needed gtk packages and build them on chum for example | 14:03 |
| norayr | hmmm... | 16:13 |
| norayr | maybe i would... but i need sailfish sdk and it only works under... wayland. | 16:14 |
| norayr | is there a vm with preinstalled sailfish sdk? | 16:14 |
| attah | piggz[m]: Pinephone Pro arriving on Friday supposedly | 17:05 |
| piggz | cool, i hope youre not disappointed with my port | 17:08 |
| attah | I expect nothing but the highest quality ;) | 17:09 |
| Flohack | mal. Got a minute for me? Re sensorfw | 19:13 |
| Flohack | mal: I have a specific question on how to obtain initial readings from proximity sensor | 19:15 |
| piggz[m] | attah: we have an interesting conundrum .. to continue with Jolla's ofono, and struggle ti integrate upstream patches ... or switch to upstream ofono, and try to implement all the Jolla bits on top of that | 19:15 |
| Flohack | piggz: UT is also interested in how this will move forward. Cell broadcast, 5G, eSIM are hot topics where we do not have a good idea yet what to do | 19:16 |
| piggz[m] | Flohack: Jolla's ofono has a cellinfo-netmon plugin ... which may be that cellbroadcast you are talking about? | 19:17 |
| Flohack | piggz: Cell broadcast is pretty far already, yes. But on all the test alerts we had in various countries there were parsing errors of the payload. Its impossible to test otherwise, but it would be good if we can work with a carrier in a GSM lab to send as many broadcast as we need | 19:18 |
| attah | piggz[m]: struggle to integrate upstream patches, or struggle to maintain current patches, gotcha :) | 19:19 |
| piggz[m] | Flohack: what version of ofono is used in UT? | 19:19 |
| piggz[m] | attah: exactly | 19:19 |
| attah | GSM (in the specific sense) is kind of doable at home | 19:19 |
| piggz[m] | upstream ofono dev told me he plans to remove glib completely, so going forward, integrating back into our ofono will get harder | 19:20 |
| Flohack | piggz: I have to check. We ahve used multiple versions over time, trying to get closer to upstream, but with heavy applied patches still. I guess the latest for Android 9/10/11 devices is a bit more what you guys have | 19:20 |
| attah | LTE and NR not so doable | 19:21 |
| piggz[m] | Flohack: im more interested in support for qmimodem and the pinephones .... jolla's ofono will be fine for rilmodem | 19:21 |
| Flohack | piggz: I agree that this creates additional effort. Yes we also want Pinephone ofc ;) | 19:21 |
| piggz[m] | i have a branch which integrates all the recent upstream ofono commits, with jolla's ofono plugins ... im just scared to try it :D | 19:23 |
| piggz[m] | it was a lot of cherry-picking and fixing last night! | 19:23 |
| Flohack | piggz: ooof sounds mighty ;) | 19:23 |
| Flohack | Lemme ask the guys what exactly do we pull right now | 19:23 |
| attah | wow! | 19:24 |
| attah | with ELL even? | 19:24 |
| piggz[m] | but im getting tired of re-doing all this ... i wish jolla would bite the bullet, switch to libell and rebase their version on upstream :) | 19:24 |
| piggz[m] | attah: yes, ive packaged libell, and using a few functions from there where the commits used them, was probably < 10 functions | 19:25 |
| Flohack | Ok wait piggz so we have still ofono, ofonojolla, ofono-sailfish and ofono-UT? | 19:25 |
| attah | ....and are there equivalents of everything, so we could just make a silly adapter-include? | 19:25 |
| piggz[m] | and ofono-piggz :D | 19:25 |
| Flohack | hehe | 19:26 |
| attah | the pig-brigade is on fire lately | 19:26 |
| piggz[m] | attah: atm, i need to understand just what jolla added plugin wise .... my initial thought is that if its just a few plugins, we could reimplement them using upstream and ell | 19:26 |
| Flohack | piggz: Also we have the neverending block of VoLTE. Our efforts in UT were entirely fruitless for the last 2 years or so | 19:27 |
| mal | Flohack: sure, just ask | 19:27 |
| Flohack | mal: So our problem is that our repowerd wakes up when a notification arrives, and has to decide to turn on the main screen or not: If proximity is near, phone is in pocket, screen should stay off | 19:28 |
| Flohack | mal: So now in old UT this worked flawlessly, since libhardware or what it was could deliver the correct initial state. It does not work with sensorfw: We always get proximity FAR, only if it would change it would be correct | 19:29 |
| mal | do you keep proximity sensor on all the time or just on-demand? | 19:29 |
| Flohack | No, on demand it seems | 19:29 |
| Flohack | Same seems to be for ambient lgiht, though there it does not make such a big deal, since a new value will arrive soon after we start the loop | 19:30 |
| mal | mce used for controlling when display can be turned on can handle also on-demand proximity sensor, not sure how it was done | 19:30 |
| mal | https://github.com/sailfishos/mce/commit/d9c917b763dd1ab4e11b0743fff56b2f9879d08a | 19:31 |
| Flohack | mal: We tried to make an initial dbus read request, but this also delivers the wrong value. Ok lemme take alook | 19:32 |
| mal | need to check how sensorfw does things | 19:32 |
| mal | Flohack: which sensorfw backend do you use? | 19:33 |
| Flohack | mal: mal: Need to look, ust a sec | 19:35 |
| attah | piggz[m]: would the specific parts even have to switch to ell? | 19:37 |
| Flohack | mal: case PluginType::LIGHT: return "alssensor"; | 19:37 |
| Flohack | case PluginType::PROXIMITY: return "proximitysensor"; | 19:37 |
| mal | I mean the sensorfw side, hal, binder, iio? | 19:38 |
| piggz | attah: not sure ... that what we need to figure out ... they may in the future if more is removed | 19:39 |
| piggz | the new plugin stuff added by dennis recently reduces all the boiler-plate code a bunch, and upstream ofono looks in decent shape | 19:39 |
| piggz | plenty of improvemements lately | 19:39 |
| Flohack | mal: hard to tell, we package sensorfw here, idk if we enable specific backends only: https://gitlab.com/ubports/development/core/packaging/sensorfw/-/tree/main/debian | 19:41 |
| Flohack | piggz: We use https://github.com/sailfishos/ofono/archive/refs/tags/1.29+git7.tar.gz currently as a base for packaging | 19:43 |
| piggz | Flohack: intersting, you use jollas version .. i assumed you used upstream | 19:43 |
| piggz | i guess to support rilmodem? | 19:44 |
| Flohack | piggz: yes I guess we cannot use pure upstream due to the heavy dependency on rilmodem plugin | 19:44 |
| Flohack | yess | 19:44 |
| mal | Flohack: well you have hybris and hidl packages there which contain hal and binder backends, the iio backend is in the main package | 20:03 |
| Flohack | mal: I will try to get current config file from overlay | 20:04 |
| mal | Flohack: have you monitored sensorfw debug or test output to see if gets any proximity even before display turns on | 20:05 |
| Flohack | mal: No, not really | 20:05 |
| piggz | mal: attah https://editor.mergely.com/d0hTT6PP | 20:16 |
| attah | Yeah... that's a diff alright | 20:19 |
| mal | piggz: is that really correct? which branches is that comparing? | 20:22 |
| piggz | no, im just checking ... my grepping/filtering might have taken too much out | 20:23 |
| mal | piggz: for example connman.c is missing from one when it's really always there | 20:24 |
| piggz | mal: looks better now | 20:26 |
| mal | piggz: the second one doesn't seem to be sorted correctly | 20:28 |
| mal | hmm, now it looks ok | 20:28 |
| mal | piggz: still some missing things from second column | 20:30 |
| piggz | now? its just the output of: | 20:34 |
| piggz | find | sort | grep -v "\.git" | grep -v "\.o" | grep -v "\.deps" > ~/ofono-sfos.files | 20:34 |
| mal | piggz: what makes for example storage.c and voicecall.c to not be there in second list | 20:36 |
| piggz | hmmm, my grep magic must be failing | 20:38 |
| piggz | youre right, its there | 20:38 |
| piggz | mal: there, fixed that one | 20:39 |
| mal | piggz: is that grep "\.o" accidentally removing all with o | 20:39 |
| piggz | maybe a piped to wrong file :) | 20:40 |
| piggz | so, there is a bunch of stuff in src/ and some extra plugins ? | 20:42 |
| mal | piggz: can you update the diff | 20:47 |
| piggz | mal: i think you just refresh? | 20:48 |
| piggz | now you made me delete it :D | 20:48 |
| piggz | one sec.... | 20:48 |
| mal | nothing changes, those files were still missing | 20:48 |
| piggz | mal: https://editor.mergely.com/c45imbVZ | 20:49 |
| mal | not that bad diff anymore | 20:55 |
| mal | piggz: most the new files in our version for exposing stuff to our plugins | 21:01 |
| piggz[m] | mal: yeah, i guess its a case if trying to implement the bare minimum to make the voicecall-ui happy initially | 21:08 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!