stan | thank you for "Emergency Shell" on lcd tmlind. | 01:12 |
---|---|---|
stan | saves me from pulling the sdcard to fix some goofups | 01:12 |
buZz | stan: lol had me searching for 'target.com phones' in ML | 02:26 |
stan | hi buzz. do you know where these actions for 'android buttons' are configured? | 02:32 |
stan | the functions chosen seem pretty sensible, but i am curious about user-configurability | 02:33 |
buZz | what device? | 02:46 |
stan | d4 | 02:49 |
buZz | i -think- those a gpio buttons somehow , not sure | 02:56 |
buZz | they arent in normal keymap anyway | 02:57 |
stan | they are just part of touchscreen and show as clicks in xev, i think | 03:00 |
Daanct12 | Is it possible to switch branch to a more breaking-edge one? | 03:56 |
Daanct12 | : Conflicting distribution: https://maedevu.maemo.org/leste unstable InRelease (expected unstable but got beowulf) | 04:51 |
Daanct12 | Looks like i can't :( | 04:51 |
uvos | its deb https://maedevu.maemo.org/leste beowulf-devel main contrib non-free droid4 | 08:57 |
uvos | replace droid4 with the device you have | 08:57 |
stan | uvos: what's the best candidate for a maemo-friendly podcast client? i think gpodder once was maemo-ized, no? | 09:11 |
uvos | i just use firefox | 09:13 |
uvos | you can use rss extensions | 09:13 |
uvos | and play your podcast with ff | 09:14 |
stan | i think the browser doesn't automatically download the episodes | 09:38 |
freemangordon | stan: uvos is not the best person to ask for maemo specific applications, he has not been a maemo/fremantle user | 09:48 |
uvos | thats right | 09:48 |
freemangordon | uvos: hi! Seems there was some progress on libsdl, at least I was left with that impression by reading TMO. hmm? | 09:49 |
uvos | no | 09:50 |
uvos | i tried the sdl1.2 -> sdl2 shim | 09:50 |
uvos | nothing else was done | 09:50 |
freemangordon | I see | 09:50 |
stan | major improvement was recent - the half-screen-down shift in fullscreen mode was alleviated | 09:51 |
stan | I also now get keyboard input in fullscreen mode | 09:51 |
freemangordon | oh, seems -devel stuff has been moved to -stable | 09:52 |
freemangordon | that explains it | 09:52 |
stan | 32-bit arm could also benefit from the NEON accelerated SDL, but these additions were taken out of upstream in 2019 | 09:54 |
stan | afaik the reason they were pulled was that some apps were broken on 64-bit arm systems | 09:55 |
uvos | tmlind: so the problem is that Voice Playback stream is never considerd active by DAPM | 10:25 |
uvos | tmlind: when starting a call cpcap_voice_set_tdm_slot ins run but /sys/kernel/debug/asoc/Mapphone\ Audio/cpcap-codec.0/dapm/Voice\ Playback remains "Off" so all downstream widgets remain off too, including the PGA | 10:26 |
uvos | so snd_soc_dapm_route is fine | 10:29 |
uvos | but the "Voice Playback" snd_soc_dai_driver remains off in call | 10:30 |
Wizzup | Danct12: are you on -devel? | 10:33 |
sicelo | Danct12: perhaps show us your sources.list (including the HAM sources.list) | 10:49 |
bencoh | stan: I dunno what it's worth, but http://maemo.org/packages/view/gpodder/ | 10:52 |
stan | yeah i remember thp was doing maemo stuf | 10:56 |
stan | my use-case is for a home device on ethernet to pull the feeds, then i push those to my portable devices via script | 10:57 |
stan | running /etc/init.d/droid4-wlanconfig restart when transferring a sd to a new device seemed to help wlan | 11:05 |
uvos | that dose absoulty nothing except the first time | 11:07 |
uvos | and it should run on first boot | 11:08 |
uvos | oh wiht transfering a sd to a new deivce you mean some old install running on a different d4 | 11:08 |
stan | yes, what should i run to re-calibrate wlan | 11:09 |
uvos | yeah then you must rerun that (or maserati-callibrate directly) | 11:09 |
stan | ok ty | 11:09 |
stan | it didn't see my AP. now it does. | 11:09 |
uvos | yes running the fem parameters from some other deivce is not a good idea | 11:10 |
stan | that could be a warning on the wiki (to recalibrate wlan if transferring system to another device) | 11:10 |
stan | how about checking the hw mac address on boot and if changed, recalibrate wlan? | 11:11 |
bencoh | talking about calibration, should batery calibration happen automagically, or should I run something? | 11:25 |
uvos | automagically | 11:26 |
stan | why does maserati-calibrate refuse to be rerun? | 11:27 |
stan | do i cause harm by removing that check from the script? | 11:27 |
bencoh | uvos: is there a reason why the battery status applet keeps saying "calibration needed" then? | 11:28 |
uvos | bencoh: device? | 11:28 |
bencoh | (I'm not running -devel yet, btw) droid4 | 11:28 |
uvos | it has to see battey low and battery full within one boot | 11:28 |
uvos | and subsequently it needs to see one of those in the current boot | 11:28 |
uvos | otherwisese its uncallibrated | 11:28 |
bencoh | hmm, I think it saw both, but maybe not in that order | 11:29 |
uvos | stan: yes you cant callibrate without the stock fem parameters | 11:29 |
bencoh | either that, or it always crashed after low | 11:29 |
uvos | order dosent matter | 11:29 |
bencoh | well, then ... | 11:29 |
uvos | it needs to shutdown cleanly | 11:29 |
uvos | ofc | 11:29 |
uvos | otherwise no save | 11:29 |
bencoh | I'll have to give it another try I guess | 11:29 |
bencoh | last time it shutdown in my hands it was around ~25% according to upower | 11:30 |
stan | uvos: but dpkg-reconfigure firmware-ti-connectivity, then running maserati-calibrate could work? | 11:30 |
bencoh | (~3.3V) | 11:30 |
uvos | you have to reinstall the firmware | 11:30 |
bencoh | (I think it reached cutoff during a current peak) | 11:30 |
uvos | bencoh: if you battery is bad it can be impossible to callibrate | 11:31 |
bencoh | I replaced it a few years ago and barely used the phone since then | 11:31 |
bencoh | but it could be | 11:31 |
stan | i think we need a wiki page for 'how to use an existing maemo-leste sdcard in a different device' | 11:31 |
uvos | why dont you go improve the wiki | 11:32 |
stan | i can paste your comments to a page under that title to ensure I do not write anything incorrect | 11:33 |
uvos | please format it nicely | 11:33 |
uvos | also put it into the droid4 and bionic page | 11:34 |
uvos | its device specific | 11:34 |
stan | ok | 11:34 |
stan | how do i < uvos> you have to reinstall the firmware | 11:34 |
uvos | apt reinstall | 11:34 |
stan | that is difficult without wlan | 11:35 |
uvos | well you can use usbnet | 11:36 |
uvos | or download it elsewhere and dpkg -i | 11:36 |
bencoh | dpkg -i sounds better yeah | 11:37 |
stan | thanks, then you confirm that apt reinstall ti-firmware-connectivity is necessary and dpkg-reconfigure ti-firmware-connectivity is insufficient? | 11:37 |
uvos | btw you must reboot after reinstalling | 11:37 |
uvos | yes | 11:37 |
uvos | so reinstall the firmware -> reboot -> maserati-callibrate | 11:38 |
stan | ty again. will setup wiki page | 11:38 |
stan | btw it looks like there is progress with qualcomm supporting linux. there may be some snapdragon based phones that can do leste now/soon | 11:39 |
Wizzup | it looks like dsme doesn't actually wait() for anything that it kills, so it might report that it stopped a program too soon | 12:44 |
Wizzup | I suppose it can't always just wait, depending on the signal it sends, but that's probably why some of our service restarts fail | 12:45 |
Wizzup | I think this is also ultimately the cause for the resets we are seeing on certain upgrades | 12:46 |
Wizzup | ke-recv is restarted way too fast, when the previous one is not gone yet, fails to start because of that, and the device reboots after 10 attempts | 12:46 |
Wizzup | it might make sense to increase the dsme log level as well | 12:52 |
Wizzup | that would be adding -v 7 invocation in the init script | 12:55 |
Wizzup | yeah, I cannot think of any other reason that ke-recv would fail to restart, unless it is somehow restarted with some poor env, or when debian is still working on parts it needs | 12:59 |
Wizzup | the code is straightforward and should log to syslog right away in case of problems | 12:59 |
uvos | something something ditch dsme :P | 13:07 |
uvos | (for starting non-session services at least) | 13:07 |
Wizzup | it's not clear it's dsme, it could be debian restarting it at an unfortunate time | 13:13 |
uvos | well the point is dont spend to mutch time on this, both ke-recv and dsme we should ditch for various reasons. | 13:15 |
freemangordon | uvos: please... | 13:16 |
uvos | no not please | 13:16 |
uvos | both of these lack technical merit | 13:16 |
uvos | and dsme is really architecutally broken | 13:16 |
uvos | (except as a session manager thats ok) | 13:16 |
freemangordon | you're wasting too much energy spittin on dsme, launcher, whatnot, basically a reverse NIH syndrome I'd say | 13:17 |
freemangordon | and this is not really useful | 13:17 |
Danct12 | Wizzup, i assume just add devel into source.list should work right? | 13:18 |
Wizzup | uvos: tbh I don't know how many linux phones support on the fly apt-upgrade, I guess mobian probably does | 13:18 |
Wizzup | Danct12: the specific line, but yes | 13:18 |
Wizzup | uvos: ubports for sure cannot do it | 13:18 |
Wizzup | iirc | 13:18 |
Danct12 | https://paste.ubuntu.com/p/zN7dw47rQd/ | 13:18 |
freemangordon | Wizzup: maemo has never supported apt-get upgrade | 13:19 |
freemangordon | system upgrades shall be done through HAM | 13:19 |
uvos | freemangordon: we shal keep the underlying system working | 13:19 |
freemangordon | uvos: sure. so? | 13:19 |
uvos | freemangordon: many parts of ke-recv dont work on mainline and sfos absorbed ke-recv stuff into mce so we can just copy + paste that so thats hardly reverse NIH | 13:19 |
uvos | so dont break apt | 13:19 |
freemangordon | I am not talking about ke-recv in particular, but in general about your attitude:"there is a bug in program X? ah, lets remove it then." | 13:20 |
bencoh | freemangordon: iirc fremantle broke with *dist-upgrade*, not with upgrade | 13:20 |
uvos | no upgrade | 13:21 |
uvos | or rather both | 13:21 |
uvos | multiple times now | 13:21 |
uvos | freemangordon: no its allways remove program X | 13:21 |
freemangordon | bencoh: upgrade was never officially supported either | 13:21 |
uvos | just when a bug comes i ofc reiterate | 13:21 |
freemangordon | that's why the PR thingie | 13:21 |
bencoh | well, I guess I had luck with upgrade then | 13:21 |
bencoh | anyway, I'd really like to be able to run apt-get upgrade on leste | 13:21 |
buZz | isnt the appmanager just a frontend for apt really? | 13:21 |
freemangordon | I said "supported" ;) | 13:21 |
freemangordon | yes, it is | 13:22 |
bencoh | freemangordon: yeah :) | 13:22 |
freemangordon | but is stops lots of things before doing the real upgrade | 13:22 |
freemangordon | including putting the device offline etc | 13:22 |
freemangordon | apt will never do that IIUC | 13:22 |
uvos | wich is just a hack around various bugs really | 13:22 |
Wizzup | freemangordon: /system/osso/connectivity/srv_provider/[VALUE]/module <-- here VALUE is just a name, right, not a network type? | 13:22 |
freemangordon | ummm.... | 13:23 |
freemangordon | no idea :) | 13:23 |
Wizzup | I have a working provider module, but it only works on DUMMY network types, not on WLAN_INFRA, and I don't know why | 13:23 |
Wizzup | I get this: | 13:23 |
Wizzup | Jun 29 13:21:08 localhost icd2 0.98[17712]: calling service provider module | 13:23 |
Wizzup | Jun 29 13:21:08 localhost icd2 0.98[17712]: srv type 'WLAN_INFRA' unknown | 13:23 |
Wizzup | fro Jun 29 13:21:08 localhost icd2 0.98[17712]: calling service provider module | 13:23 |
bencoh | freemangordon: tbf it sounds like something that we might be able to fix in an incremental fashion | 13:23 |
Wizzup | Jun 29 13:21:08 localhost icd2 0.98[17712]: srv type 'WLAN_INFRA' unknown | 13:23 |
Wizzup | er.. | 13:23 |
Wizzup | from https://github.com/maemo-leste/icd2/blob/master/icd/icd_srv_provider.c#L1000 | 13:23 |
bencoh | (writing proper prerm/postrm/preinst/postinst scripts) | 13:23 |
bencoh | (and proper services dependency) | 13:23 |
Wizzup | freemangordon: I don't know where service_type is set | 13:23 |
Wizzup | I have this: | 13:24 |
Wizzup | gconftool -s /system/osso/connectivity/srv_provider/DUMMY/network_type --type list --list-type string '[DUMMY,WLAN_INFRA]' | 13:24 |
freemangordon | Wizzup: me neither, but I would grep for it | 13:24 |
Wizzup | I tried, it's all over the place, but ok | 13:24 |
freemangordon | I'll try to do it as well, gimme a minute | 13:24 |
Wizzup | hmmm maybe it comes from the module itself | 13:25 |
Danct12 | Wizzup, is this source.list good enough for adding devel? | 13:26 |
Danct12 | https://paste.ubuntu.com/p/yy6pqWtPRs/ | 13:26 |
Wizzup | freemangordon: it looks like icd_plugin_load has a callback icd_srv_provider_init where it might be set by some callback | 13:26 |
uvos | Danct12: thats fine | 13:27 |
Wizzup | Danct12: I'm surprised this is not documented on our wiki, hm | 13:27 |
Danct12 | i noticed that HAM source.list doesn't specify n900 | 13:28 |
Wizzup | gchar *service_type = g_strrstr(dir, "/"); | 13:28 |
Wizzup | cb_data.service_type = service_type; | 13:28 |
Wizzup | ugh. | 13:28 |
Wizzup | I guess it does get it from the gconf path then... | 13:28 |
parazyd | ouch | 13:28 |
freemangordon | Wizzup: yeah.looks like | 13:29 |
Wizzup | ok, maybe I did something wrong | 13:29 |
Wizzup | freemangordon: btw, it would be nice to set aside some time to talk service providers too I think | 13:29 |
Wizzup | (next to abook) | 13:30 |
freemangordon | ok | 13:30 |
freemangordon | lets try to talk abook today or tomorrow | 13:30 |
* stan found a n900 with working usb \o/. will use for testing | 13:31 | |
Wizzup | freemangordon: ok, please let me know a few hours in advance | 13:34 |
Wizzup | parazyd: ^^ | 13:53 |
Wizzup | freemangordon: there is now libicd-provider-dummy service | 13:53 |
Wizzup | it will only print when icd2 runs with -l0, but it works for wifi and dummy network types for me | 13:53 |
Wizzup | Jun 29 13:52:36 localhost icd2 0.98[7209]: No other ip_up functions found | 13:54 |
Wizzup | Jun 29 13:52:36 localhost icd2 0.98[7209]: calling service provider module | 13:54 |
Wizzup | Jun 29 13:52:36 localhost icd2 0.98[7209]: dummy_connect: b4902622-2506-49a3-99a8-f746cf05cf21 | 13:54 |
Wizzup | There is a lot to do UX wise | 13:55 |
Wizzup | also I have more research I need to do I guess, since there are various ways to side load icons or something | 13:56 |
lel | IMbackK opened an issue: https://github.com/maemo-leste/bugtracker/issues/552 (Sphone) | 19:35 |
uvos | Wizzup: ^^^ | 19:36 |
Wizzup | uvos: can I add points, or shall I suggest them here? | 19:37 |
Wizzup | * integrate with osso-abook (when ready) | 19:37 |
uvos | right: replace the very basic contacts handling with something better | 19:37 |
Wizzup | maybe something wrt telepathy and other call things | 19:37 |
Wizzup | but that's future | 19:37 |
uvos | sphone dose soemthing with telepathy | 19:37 |
Wizzup | I can start on the packaging now I think | 19:37 |
uvos | for contacts | 19:37 |
Wizzup | cool | 19:38 |
Wizzup | unless parazyd wants to do the packaging | 19:38 |
uvos | i also added: make sphone -c options a settings applet | 19:38 |
uvos | idk if that is the right terminiology | 19:39 |
uvos | but i mean the stuff in the settings programm | 19:39 |
uvos | so its there instead of a a seperate window | 19:39 |
uvos | any thing else? | 19:39 |
Wizzup | controlpanel applet | 19:41 |
Wizzup | we'll have to see how much sense it makes | 19:42 |
Wizzup | I think ultimately we might end up tweaking a lot | 19:42 |
Wizzup | (we do already have a phone controlpanel applet, part of my cellular stuff, it's just unfinished and buggy) | 19:42 |
uvos | well sphone -c options lets you set the ringtone and sutch | 19:42 |
uvos | ok | 19:42 |
uvos | i gues sphone could read gsettings for it if we have sutch an applet | 19:42 |
uvos | so i changed it to "make sphone -c options a controlpanel applet or replace it with an existing applet" | 19:47 |
uvos | also added "remove legacy xdg system tray icon (done) and integrate sphone with some hildon status menu item " | 19:47 |
uvos | i think thats it | 19:47 |
Wizzup | uvos: the ringtone is part of one of our controlpanel paapplets as well | 19:49 |
Wizzup | I think it's in the profiles? | 19:49 |
Wizzup | and yes, stored in gconf | 19:49 |
Wizzup | I think there is a phone status applet, I could look at it in IDA and re it to read ofono callstate or something | 19:49 |
Wizzup | (of course, it also needs to work with other telepathy call types later) | 19:49 |
uvos | ok | 19:50 |
uvos | phone status applet that shows when your in a call seems not so need | 19:50 |
uvos | so the sphone systemtray item mostly shows when you have a missed call | 19:50 |
uvos | a new sms | 19:50 |
uvos | that sort of thing | 19:51 |
freemangordon | sphone is written using what? gtk? | 19:51 |
uvos | gtk2 | 19:51 |
uvos | yeah | 19:51 |
freemangordon | cool | 19:51 |
freemangordon | does it support vide calls? | 19:52 |
freemangordon | *video | 19:52 |
uvos | no | 19:52 |
uvos | its just a ofono dialer | 19:52 |
uvos | and sms app | 19:52 |
uvos | and so on | 19:52 |
freemangordon | we'll have to implement that as well | 19:52 |
uvos | ringer deamon | 19:52 |
uvos | sure | 19:52 |
uvos | at some point | 19:52 |
freemangordon | ok | 19:52 |
uvos | i dont think thats a priority | 19:52 |
uvos | do you use video calls alot? | 19:52 |
uvos | you would be the first person i know to use umts video calls | 19:52 |
uvos | or do you mean ip ones? | 19:53 |
freemangordon | i[ ones | 19:53 |
freemangordon | *ip | 19:53 |
uvos | okay | 19:53 |
freemangordon | through telepathy | 19:53 |
uvos | ok | 19:53 |
freemangordon | but yeah, this is for the future | 19:53 |
uvos | well support different backends like voip telegram or whatever thorugh the dialer would be nice | 19:53 |
Wizzup | the plan is to make that work through telepathy | 19:54 |
uvos | http://uvos.xyz/maserati/dialer.png | 19:54 |
uvos | btw in case you have not seen it freemangordon | 19:55 |
freemangordon | hmm | 19:55 |
freemangordon | lots to be done there :) | 19:55 |
uvos | sure but its a nice start | 19:56 |
freemangordon | mhm | 19:56 |
uvos | and would allow sms and calls to work very soon | 19:56 |
Wizzup | I think it's nice to have a tangible base that we can build on | 19:56 |
freemangordon | right | 19:56 |
Wizzup | it's easier than REing 1MB of binaries to find the gtk parts | 19:56 |
Wizzup | we can then look at it after the fact for specific features | 19:56 |
Wizzup | rtcom-eventlogger, that kind of stuff | 19:56 |
freemangordon | agree | 19:56 |
freemangordon | also EM calls and service numbers | 19:57 |
freemangordon | and abook integration | 19:57 |
Wizzup | sure, and probably in-call DMTF (if that is what it is called) | 19:57 |
freemangordon | mhm | 19:57 |
uvos | it tires to do dmtf | 19:57 |
uvos | but uses a special htc mixer | 19:57 |
freemangordon | we have a library that will generate the tones for us | 19:57 |
uvos | (like the droid4 also has) | 19:57 |
uvos | freemangordon: that cant work | 19:57 |
freemangordon | why> | 19:58 |
freemangordon | ? | 19:58 |
uvos | because on most modern phones the cpu isent involved in the audio stream | 19:58 |
uvos | you cant just inject something | 19:58 |
freemangordon | that's stupid | 19:58 |
uvos | this was true of the htc device sphone was devloped on too btw | 19:58 |
uvos | freemangordon: not really | 19:58 |
uvos | the n900 seams fairly alone in this | 19:59 |
uvos | anyhow we can do dtmf via pulse | 19:59 |
freemangordon | uvos: it is stupid, because your dialer shall support each in every HW it is intended to be used on | 19:59 |
uvos | no | 19:59 |
uvos | why> | 19:59 |
Wizzup | uvos: so we can't send audio at all to the phone modem? | 19:59 |
uvos | the kernel abstracts this | 19:59 |
freemangordon | uvos: I don;t get what you're saying | 20:00 |
freemangordon | the library I am talking about just generates waveforms | 20:00 |
uvos | freemangordon: the kernel abstracts the dtmf thing away we can just create a ucm mode for dtmf | 20:00 |
Wizzup | I think he is saying we cannot send audio to the modem from userspace | 20:00 |
uvos | then the dialer dosent have to know | 20:01 |
Wizzup | but maybe I am confused | 20:01 |
freemangordon | who generates and plays busy tone then? | 20:01 |
uvos | so on mapphones you can in theory via the voice loopback thing | 20:01 |
uvos | but you cant rely on that | 20:01 |
uvos | existing on all devices | 20:01 |
uvos | so we can just have a pa control that generates dtmf | 20:02 |
uvos | on n900 that makes some pa module generate the waveform | 20:02 |
Wizzup | how about https://github.com/rilmodem/ofono/blob/master/doc/voicecallmanager-api.txt#L188 ? | 20:02 |
uvos | on pp and mapphones it asks the kernel driver to do it | 20:02 |
Wizzup | oh that's just rilmodem I guess | 20:02 |
Wizzup | hm, no | 20:02 |
freemangordon | and for generating the waceform we use the lib I am talking about :) | 20:02 |
freemangordon | *waveform | 20:02 |
uvos | freemangordon: sure on n900 | 20:02 |
freemangordon | on every device | 20:02 |
uvos | no | 20:02 |
uvos | you cant | 20:02 |
uvos | freemangordon: but not directly, through a pa moudle | 20:03 |
freemangordon | pa module calls the lib to generate the waveform | 20:03 |
uvos | freemangordon: and ucm /kernel takes care of device differences | 20:03 |
uvos | you can not send any audio to the modem during a call. | 20:03 |
uvos | you must ask the modem to insert dtmf | 20:03 |
freemangordon | uvos: so, who generates dtmf tones? | 20:03 |
uvos | the kernel exposes this via alsa | 20:03 |
freemangordon | ah | 20:04 |
freemangordon | and what about busy tone? | 20:04 |
uvos | modem | 20:04 |
uvos | modem dose everything | 20:04 |
freemangordon | ok, will see | 20:04 |
uvos | on n900 you have to emulate the stuff the modem dose on pp/mapphones via pulse | 20:05 |
freemangordon | because I don;t see that happening for IP calls | 20:05 |
uvos | the interface stays the same for the dialer | 20:05 |
uvos | freemangordon: right for ip calls different story ofc | 20:05 |
uvos | the busy tone comes from the voip server tho no? | 20:05 |
uvos | (not sure) | 20:05 |
freemangordon | I doubt | 20:06 |
freemangordon | but not really sure | 20:06 |
uvos | also note that busy tones are kina a thing of the past | 20:07 |
freemangordon | why is that | 20:07 |
uvos | on lte modern phones just say busy (at least the ones i use) | 20:07 |
freemangordon | so, what if I am dialing through my car kit? | 20:07 |
freemangordon | shall I read the messages while driving with 140 km/h? | 20:08 |
uvos | the device makes a sound | 20:08 |
freemangordon | called busy tone, no? | 20:08 |
uvos | though whatever output it is | 20:08 |
uvos | yeah no | 20:08 |
Wizzup | is busy the sound before you pick up? | 20:08 |
uvos | its just the sound of the notification | 20:08 |
freemangordon | Wizzup: no, what you describe is "ringing" tone | 20:09 |
uvos | no the busy sound like in a pstn netowrk | 20:09 |
freemangordon | beep-beep-beep-beeo-... | 20:09 |
Wizzup | ok | 20:09 |
Wizzup | well I'll look at packaging it now | 20:09 |
Wizzup | seems like a concrete thing I can work on | 20:09 |
uvos | aka it dosent come over the phone conection like in pstn | 20:09 |
uvos | lte just sends the device a message really | 20:09 |
freemangordon | and the device shall generate it | 20:09 |
freemangordon | (the tone) | 20:10 |
uvos | well they dont anymore | 20:10 |
uvos | but sure if you want | 20:10 |
freemangordon | uvos: see my car kit example | 20:10 |
freemangordon | I can do voice dial and I expect an audible feedback | 20:10 |
uvos | right and what im saying is that this is not speccaly implmented | 20:11 |
uvos | its just a notification | 20:11 |
uvos | and that has a sound | 20:11 |
freemangordon | well, you said "a thing from the past" :) | 20:11 |
uvos | right the beep beep beep thing that gsm and ptsn do is a thing of the past | 20:12 |
uvos | thats what i was getting at | 20:12 |
freemangordon | if you mean that it does not come from the networks, then ok | 20:12 |
freemangordon | but the sound as such, I doubt it will be gone soon | 20:12 |
freemangordon | it doesn't really make sense to remove the most recognized phone tone which was there since the beginning of the telephony just to replace it with some other sound | 20:13 |
freemangordon | no matter who generates it, beep-beep-... will not go soon IIUC | 20:14 |
uvos | pff back in the day the nice operator told you the line was in use :P | 20:14 |
freemangordon | which is very useful when I am in Greece :) | 20:14 |
freemangordon | or when you are in Bulgaria :p | 20:15 |
Wizzup | so I think we'll figure this out along the way, no? | 20:15 |
freemangordon | yeah | 20:15 |
Wizzup | it feels like we're overly zooming on in this at this point :P | 20:15 |
freemangordon | Wizzup: it is important from the architectural POV | 20:15 |
freemangordon | who does what | 20:15 |
freemangordon | busy tone was just an example | 20:16 |
Wizzup | yeah, but we have a lot more to figure out I think | 20:16 |
freemangordon | sure, but this is easy | 20:16 |
freemangordon | :) | 20:16 |
uvos | lets get something to work, then get it work well | 20:16 |
freemangordon | agree, but lets try to have as much as possible from the bigger picture upfront | 20:17 |
freemangordon | that'll save us some effort in the future | 20:17 |
Wizzup | we could have a wiki page as scratchpad | 20:17 |
Wizzup | I think we will probably change a *lot* in sphone | 20:17 |
uvos | well geting sphone running with everyhing implmented in the modem like on d4 first is a no brainer | 20:17 |
uvos | since all the code is just sitting there. | 20:17 |
Wizzup | but it's nice to get audio going, test calls a lot, etc | 20:17 |
Wizzup | yes | 20:18 |
freemangordon | very important aspect is how long it takes for the phone to start ringing | 20:18 |
uvos | why? | 20:18 |
Wizzup | uvos: any idea what debian section we should use for sphone | 20:18 |
uvos | no | 20:18 |
freemangordon | IIRC we have 1.5 second if we want to follow the standards | 20:19 |
uvos | well the modem dose eveything | 20:19 |
uvos | im sure it follows standarts | 20:19 |
uvos | or you mean the reverse | 20:19 |
uvos | in this case sphone is ram resident | 20:19 |
uvos | and instant | 20:19 |
freemangordon | but it takes some time UI to show up and to play "ring-ring" sound | 20:19 |
uvos | pretty mutch | 20:19 |
uvos | sphone keeps everything in ram | 20:19 |
freemangordon | mlock? | 20:19 |
uvos | no | 20:20 |
freemangordon | then it can be swapped | 20:20 |
freemangordon | also, we'll have to renice | 20:20 |
uvos | sure but just do that with cgroups | 20:20 |
freemangordon | or implement cgroups | 20:20 |
uvos | but its just one big binary with everthing that runs as a deamon | 20:20 |
freemangordon | yeah | 20:20 |
Wizzup | (like the rtcom-call ui program) | 20:20 |
freemangordon | actually it uses a big lib as well | 20:21 |
uvos | and ofono needs to be in ram ofc | 20:21 |
freemangordon | I guess we'll have to mlock it as well, or somesuch | 20:21 |
uvos | but jeah just dump everything into a cgroup that keeps it loaded | 20:21 |
freemangordon | mhm | 20:21 |
uvos | dbus too | 20:22 |
freemangordon | mhm | 20:22 |
freemangordon | and PA | 20:22 |
freemangordon | we may look at what fremantle is doing | 20:22 |
freemangordon | though it uses ohm as well | 20:22 |
Wizzup | uvos: what contains unique-1.0.pc ? | 20:23 |
uvos | fremantle is pre cgroups tho | 20:23 |
uvos | i think | 20:23 |
uvos | Wizzup: unique | 20:23 |
freemangordon | it uses cgrous as well | 20:23 |
Wizzup | I thought it was uuid-dev, but it looks like it is not | 20:23 |
freemangordon | *cgroups | 20:23 |
Wizzup | ah libunique ? | 20:23 |
uvos | yes | 20:23 |
Wizzup | hm I don't see it | 20:23 |
uvos | sec | 20:23 |
Wizzup | can you dpkg -S it on your device? | 20:23 |
uvos | libunique-dev | 20:25 |
uvos | owns /usr/lib/arm-linux-gnueabihf/pkgconfig/unique-1.0.pc | 20:25 |
Wizzup | It is not avail in my debian | 20:25 |
Wizzup | devuan* | 20:25 |
Wizzup | where did you get it from? | 20:25 |
Wizzup | testing or something? | 20:25 |
uvos | just apt install | 20:25 |
uvos | no its old i think its dropped in sid | 20:26 |
Wizzup | (mine is set to dutch atm but it can't find it) | 20:26 |
Wizzup | E: Kan pakket libunique-dev niet vinden | 20:26 |
Wizzup | it's not avail in beowulf it seems | 20:26 |
uvos | i just apt installed on a leste device | 20:26 |
Wizzup | wtf | 20:26 |
Wizzup | let me apt update I guess | 20:26 |
uvos | can you make apt list what repo a pacakge came from? | 20:27 |
uvos | or dpkg | 20:27 |
Wizzup | apt did something insane | 20:27 |
Wizzup | I did apt update | 20:27 |
Wizzup | and now it's installing libunique-1.0-0 | 20:27 |
uvos | ok | 20:27 |
Wizzup | so it remembered? | 20:28 |
uvos | hmm | 20:28 |
Wizzup | ah no | 20:28 |
Wizzup | I had the command queued | 20:28 |
Wizzup | ok so I have it now! | 20:28 |
Wizzup | not sure what happened there with apt | 20:28 |
Wizzup | lol localisation is so annoying when stuff like make is being translated | 20:32 |
* Wizzup changes and reboots | 20:32 | |
Wizzup | uvos: well, dpkg-deb: building package 'sphone' in '../sphone_0.06_amd64.deb'. | 20:37 |
Wizzup | :) | 20:37 |
Wizzup | it looks a bit awkward in landscape | 20:38 |
uvos | thats right | 20:38 |
uvos | we need to force it protrait | 20:38 |
uvos | or fix it a bit | 20:38 |
Wizzup | shall I push this to a branch or to master | 20:39 |
Wizzup | uvos: well forcing portrait is pretty simple | 20:39 |
uvos | master | 20:39 |
Wizzup | uvos: done | 20:40 |
Wizzup | it should build for you now | 20:40 |
freemangordon | maybe use teh issue tracker of the repo instead of wiki | 20:42 |
Wizzup | so far we've mostly used the main issue tracker | 20:42 |
Wizzup | not package specific repo | 20:42 |
Wizzup | but we could if you want to | 20:42 |
Wizzup | uvos: shall I just put this in the CI now? | 20:42 |
Wizzup | uvos: then parazyd can give you perms to rebuild it as well | 20:42 |
uvos | sure why not | 20:43 |
freemangordon | Wizzup: the point is that we know there are lots of thing to be implemented | 20:43 |
uvos | freemangordon: there is https://github.com/maemo-leste/bugtracker/issues/552 | 20:43 |
uvos | but i knda want to keep that to immidate issues | 20:44 |
uvos | not stuff like add voip support or whatever | 20:44 |
freemangordon | uvos: yes, that's what I meant to use repo tracker for | 20:44 |
uvos | ok | 20:44 |
freemangordon | we'll pollute the main tracker otherwise | 20:45 |
uvos | sure | 20:45 |
Wizzup | uvos: wrt force dialer into portait mode somehow, we have a x atom for it | 20:45 |
uvos | Wizzup: ok | 20:45 |
Wizzup | like we have for supporting both portrait and landscape based on device orientation | 20:45 |
freemangordon | why not use hildon flags? | 20:45 |
Wizzup | afaik | 20:45 |
uvos | Wizzup: please also set the standart min max aspect ratio atom | 20:45 |
Wizzup | freemangordon: that is what I mean I think | 20:45 |
freemangordon | ok | 20:45 |
uvos | those flags are atoms | 20:45 |
Wizzup | uvos: what is that? | 20:45 |
uvos | WM_NORMAL_HINTS | 20:46 |
uvos | https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#window_manager_properties | 20:46 |
uvos | min_aspect | 20:46 |
uvos | max_aspect | 20:46 |
freemangordon | uvos: I know, the point is that we have 2 atoms and those are easily set by a single hildon call | 20:46 |
uvos | the hildon call should then also set those | 20:47 |
uvos | as other window managers use them to detine if the window needs landscape or portrait | 20:47 |
uvos | nokia must have missed them while implmenting hildon | 20:47 |
Wizzup | :) | 20:48 |
Wizzup | https://phoenix.maemo.org/job/sphone-binaries/ | 20:48 |
Wizzup | soon it'll be an apt-get install away on my d4 | 20:48 |
Wizzup | uvos: I took the liberty to update your comment | 20:49 |
uvos | pff mod powers abuse :P | 20:50 |
uvos | your build is failing | 20:50 |
tmlind | uvos: droid4 alsamixer can do dtmf during call no problem, see https://github.com/tmlind/droid4-sms-tools/blob/master/droid4-dtmf.sh | 20:51 |
uvos | tmlind: yeah i know :) | 20:51 |
tmlind | well amixer | 20:51 |
tmlind | not a nice interface, but that seems to be what few others do too with alsa | 20:52 |
uvos | right | 20:52 |
Wizzup | uvos: seems to be this? | 20:53 |
Wizzup | ./configure: line 6605: syntax error near unexpected token `0.35.0' | 20:53 |
Wizzup | ./configure: line 6605: `IT_PROG_INTLTOOL(0.35.0)' | 20:53 |
uvos | yes | 20:53 |
uvos | i saw this too | 20:53 |
uvos | you need intltool | 20:53 |
uvos | installed | 20:53 |
Wizzup | ok | 20:53 |
Wizzup | will make it a Build-Depends | 20:54 |
uvos | thats a absouly great error message btw | 20:54 |
uvos | thank you autotools | 20:54 |
Wizzup | yes :D | 20:54 |
Wizzup | no worries cmake can probably best it somehow ;) | 20:54 |
uvos | no doubt | 20:55 |
uvos | i dont think a truely good build system exists | 20:55 |
uvos | at least cmake as less layers | 20:55 |
uvos | *has | 20:55 |
Wizzup | autotools is not great in many ways, but it's a standard and for that alone I think it's mostly good | 20:55 |
Wizzup | but yeah, the sphone guy used it so it was easy | 20:56 |
uvos | i wonder if sphone guy is still around | 20:56 |
uvos | maybe we should inform him of our use | 20:56 |
uvos | he was clearly interested in linux on qwerty sliders.. | 20:57 |
Wizzup | let's get it working in some shape first :-D | 20:57 |
Wizzup | amd64 build is ok now | 20:57 |
uvos | ok | 20:57 |
Wizzup | we also need to fix up our ofono some | 20:57 |
Wizzup | (I still have a sim with pin required set and ofono never detects it still) | 20:58 |
Wizzup | (unless I restart ofono) | 20:58 |
uvos | Wizzup: something is up with your unit | 20:59 |
uvos | mine detects the sim every time | 20:59 |
uvos | check the modem firmware version in android maybe | 20:59 |
Wizzup | uvos: I think I digged into this before | 20:59 |
Wizzup | like I said, the sim notification presence is sent, but ofono does not pick it up | 20:59 |
uvos | ok | 21:00 |
uvos | hmm | 21:00 |
Wizzup | I can see it in dmesg | 21:00 |
uvos | ok | 21:00 |
Wizzup | https://github.com/maemo-leste/bugtracker/issues/530 | 21:00 |
uvos | you mean before the you unlock the sim? | 21:00 |
uvos | if you try to unlock it then sees it immidiatly | 21:00 |
uvos | ? | 21:00 |
Wizzup | startup-pin-query waits for the sim to present before it attempts to unloc kit of course | 21:00 |
Wizzup | basically the UI will forever show 'no sim present' in tsatu bar | 21:01 |
uvos | ok yeah i think i see that | 21:01 |
Wizzup | until you restart ofono or kick it in some way | 21:01 |
uvos | ok | 21:01 |
uvos | ok | 21:01 |
uvos | yes | 21:01 |
Wizzup | yeah I don't fully understand how ofono on the d4 works yet, but I think it acts on the tty line, and then uses qmi to actually do things | 21:01 |
Wizzup | so maybe we just need another 'act on this when you see it on tty line' thing | 21:02 |
Wizzup | (this is an extremely simplified version of my already basic understanding) | 21:02 |
uvos | maybe | 21:02 |
uvos | same issue exists on pp? | 21:02 |
uvos | or no? | 21:02 |
Wizzup | btw my revision is on that gh issue | 21:02 |
Wizzup | I don't think that issue exists on the pinephone or on the n900 | 21:03 |
tmlind | uvos: for the voice call issues, not sure i know what we should do.. but i think we should move dts node for cpu_dai_mdm to be a child of the cpu_audio node as the cpu is not involved at all | 21:03 |
tmlind | uvos: then when voice call is active, it would also keep it's parent active | 21:04 |
Wizzup | uvos: sphone should be apt-get install'able on the d4 now | 21:05 |
uvos | tmlind: ok if that would work :P right now i have no clue how soc_snd descides what dai is active | 21:06 |
uvos | tmlind: i just sent sre a emial with that very question | 21:06 |
tmlind | uvos: i think right now we completely rely on the set_tdm_slot() hack | 21:07 |
tmlind | uvos: yeah sre should know, i don't | 21:07 |
uvos | ok that dosent cause Voice Playback to be active | 21:07 |
uvos | see debugfs | 21:07 |
tmlind | yeah ok makes sense | 21:07 |
Wizzup | uvos: shall I try to hildonize the sphone ui somewhat? | 21:07 |
uvos | Wizzup: explain? | 21:08 |
Wizzup | add the atoms, maybe make the text fields larger | 21:08 |
uvos | Wizzup: besidse using libhildon for the protrait mode what would that entail | 21:08 |
uvos | ok | 21:08 |
uvos | sure | 21:08 |
Wizzup | maybe add context menu to switch between the UI windows | 21:08 |
Wizzup | (as opposed to various .desktop launchers) | 21:08 |
uvos | i like various .desktop launcher tbh | 21:08 |
uvos | and we need them anyhow | 21:09 |
Wizzup | a .desktop for new sms seems weird to me | 21:09 |
uvos | so you need to support the xdg intents thing | 21:09 |
Wizzup | we just have 'Conversations', which is for sms history and also writing new SMS | 21:09 |
uvos | so if an app wants to send sms: it uses xdg spec to locate the sms program | 21:09 |
uvos | that program has some magic in its .desktop file to make it work | 21:09 |
uvos | btw the fact that this suff is missing is a major pain for maemo apps | 21:10 |
Wizzup | I can skip the context menu if you want, but I think 6 launch icons is not very useful ux, even now, but I also don't feel strongly about it | 21:10 |
Wizzup | uvos: ok, but let's consider that a separate issue for now | 21:10 |
Wizzup | how did you get it in portrait mode for your screenshots | 21:10 |
uvos | i run forcerotation = 1 in hildon transition.ini | 21:11 |
Wizzup | uvos: also making buttons larger, like 'Send' and 'Cancel' in sms-new | 21:11 |
Wizzup | uvos: right | 21:11 |
uvos | that makes everything rotateable | 21:11 |
Wizzup | did you manage to send a sms yet? | 21:11 |
uvos | sure everything you propose makes sense | 21:11 |
Wizzup | I just get 'SMS send action failed' | 21:11 |
uvos | but i think we should fix the ofono stuff first | 21:11 |
uvos | no | 21:11 |
uvos | it uses a ofono interface thats mia | 21:11 |
Wizzup | ok | 21:12 |
freemangordon | Wizzup: dialer has theming | 21:12 |
freemangordon | I think it makes sence to use it | 21:12 |
freemangordon | *sense | 21:12 |
Wizzup | I don't know how theming works, but it seems like we can do that later | 21:12 |
uvos | also why would the dialer want to look diferent than system theme? | 21:12 |
Wizzup | uvos: I don't think he meant different | 21:13 |
freemangordon | :nod: | 21:13 |
uvos | then it makes no sense | 21:13 |
freemangordon | see https://github.com/maemo-leste/sphone/blob/master/src/keypad.c#L30 | 21:13 |
uvos | it follows the gtk2 theme | 21:13 |
uvos | so.. i dont understand | 21:13 |
freemangordon | actually no, look at what I linked ^^^ | 21:13 |
uvos | ok | 21:14 |
uvos | i dont think this is a big deal | 21:14 |
Wizzup | I think once we get basic things working, we'll just get PRs for things that are a big deal, and also for things that are not a big deal ;) | 21:14 |
tmlind | uvos: to clarify why we should move the voice call dts node, the voice call codec should not be a child of omap mcbsp like we have it right now, the voice all is all between cpcap and the modem | 21:15 |
uvos | tmlind: makes sense | 21:15 |
Wizzup | uvos: lol the style it uses is also white text on white/gray text input I think :-D | 21:16 |
Wizzup | like the qt5 stuff, but inverse | 21:16 |
uvos | tmlind: but i dont know how the dts structure results in dapm deciding what dai to power | 21:17 |
uvos | really the voice dai needs to be considerd powerd at all times | 21:17 |
uvos | since it is | 21:17 |
uvos | and the kernel dose not controll it | 21:17 |
uvos | tmlind: i sent you the email to sre for referance | 21:18 |
tmlind | uvos: ok, if the voice call codec is a child in dts of the cpcap voice codec, then it's also a child device in linux meaning voice call code will keep it's parent busy with pm runtime during use | 21:20 |
uvos | Wizzup: not sure what you mean | 21:21 |
uvos | Wizzup: i assume you found some theaming issue | 21:22 |
Wizzup | uvos: on the dialer, when you press the buttons, it renders white text in the text field | 21:23 |
uvos | ok | 21:23 |
uvos | maybe he hardcoded the color | 21:24 |
Wizzup | we'll see | 21:24 |
uvos | or our themes are broken | 21:24 |
Wizzup | progress at least | 21:24 |
uvos | our qt themes are broken | 21:24 |
uvos | which is why i fixed them at run time | 21:24 |
uvos | as you mentioned | 21:24 |
tmlind | good to see some voice call progress :) ttyl | 21:32 |
uvos | bye | 21:32 |
uvos | Wizzup: btw to get to the options you have to merge my branch | 21:34 |
uvos | i added the -c command for it | 21:34 |
Wizzup | uvos: feel free to merge it | 21:39 |
Wizzup | bbiab | 21:39 |
uvos | interestingly you can hotswap in a sim on a d4 | 23:01 |
uvos | motmdm detects this fine | 23:02 |
uvos | so the android userspace was the limiting factor on this | 23:02 |
stan | what does a power-led blinking 3 times a second mean when connected to usb power? | 23:32 |
stan | green, about 2.5x/sec | 23:32 |
stan | echo 800000 > /sys/class/power_supply/usb/input_current_limit made it stop | 23:33 |
uvos | Wizzup: btw on a diffrent sim now: no change to the bahavior, no grps/umts data | 23:58 |
uvos | this is on a fresh install + cellular stuff | 23:58 |
uvos | on devel | 23:58 |
uvos | so i think you could repo it by just using a fresh image | 23:58 |
Wizzup | ok | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!