freemangordon | Wizzup: why is not connui-cellular beowulf-devel not merged to master? shall I merge it? | 16:55 |
---|---|---|
Wizzup | freemangordon: lots of wip commits | 16:55 |
Wizzup | eventually it needs to be merged yeah | 16:55 |
freemangordon | shall I merge now? | 16:56 |
freemangordon | as I am going to call pinui from status menu plygin | 16:56 |
freemangordon | *plugin | 16:58 |
freemangordon | Wizzup: shall we revert https://github.com/maemo-leste/connui-cellular/commit/67a318dd198a98d8c3279f6078c083e9fc4cdb7b ? | 17:16 |
freemangordon | removing sleep 15 | 17:16 |
freemangordon | OTOH, maybe it does not make much sense to call it at all, given hot-plug functionality | 17:20 |
Wizzup | freemangordon: this also removes the call to the startup pin entry | 17:21 |
Wizzup | freemangordon: do you mean https://github.com/maemo-leste/connui-cellular/commit/fcc709919a836a9aa6d5833697b36627a035ba20 | 17:21 |
freemangordon | umm... | 17:22 |
freemangordon | I mean both it seems | 17:22 |
freemangordon | as 67a318dd198a98d8c3279f6078c083e9fc4cdb7b disables strtup-pin-query | 17:22 |
freemangordon | I remember there was some issue on n900 | 17:22 |
freemangordon | is it still there? | 17:22 |
Wizzup | well, one just waits | 17:25 |
Wizzup | the other stops calling pinentry alltogether | 17:25 |
freemangordon | mhm | 17:31 |
Wizzup | depending on how you do it in status applet I am fine with removing the xession | 17:32 |
Wizzup | xsession* | 17:33 |
freemangordon | I think it is better to stay | 17:34 |
freemangordon | but, I'll have to do some flock() trickery | 17:34 |
Wizzup | why? | 17:34 |
Wizzup | to prevent having two run at once? | 17:34 |
freemangordon | otherwise it will become racy | 17:34 |
freemangordon | mhm | 17:34 |
Wizzup | then just remove it from xsession imho | 17:34 |
Wizzup | I think the main thing is that this is for matchbox (non h-d) workflow | 17:34 |
Wizzup | where it shows pinentry and nothing else is started | 17:34 |
Wizzup | but on several of our devices this is not feasible due to how slow modem is to see sim | 17:35 |
freemangordon | IIUC, the xsession thingie is to prevent you from using the device with sim | 17:35 |
freemangordon | that's pin-locked that is | 17:35 |
Wizzup | then just take out the sim :) | 17:36 |
Wizzup | and you get the device | 17:36 |
freemangordon | sure | 17:36 |
freemangordon | yeah, lets remove xsession script | 17:36 |
freemangordon | still, we may have race | 17:37 |
freemangordon | between control panel and status menu | 17:37 |
Wizzup | well the main UX problem is that we will randomly have startup pinentry run | 17:37 |
freemangordon | it seems thats what android does | 17:37 |
freemangordon | I tried it | 17:37 |
Wizzup | ok | 17:37 |
freemangordon | and TBH I cannot come up with any better idea | 17:37 |
freemangordon | if you have one, please share | 17:38 |
freemangordon | lets count on that by the time status menu starts, SIM will already be there | 17:38 |
freemangordon | so it will be more or less similar to xsession | 17:39 |
freemangordon | still, some flock will be needed | 17:40 |
freemangordon | or exclusive open | 17:40 |
freemangordon | or not? | 17:41 |
Wizzup | 17:38 < freemangordon> lets count on that by the time status menu starts, SIM will already be there | 17:55 |
Wizzup | that won't be the case jfyi | 17:55 |
freemangordon | on n900 it will be | 17:55 |
Wizzup | the xsession also doesn't work in the d4 because it takes over two minutes after module probe | 17:55 |
freemangordon | will see | 17:56 |
freemangordon | but anyway, I think we already agreed to remove xsession, no? | 17:56 |
Wizzup | sure | 17:56 |
freemangordon | I think it will happen way faster if we online the modem | 17:58 |
freemangordon | an dI guess we can keep that in xsession | 17:58 |
freemangordon | hmm, actually it is better to keep it there | 17:59 |
freemangordon | as it asks you to exit flight mode | 17:59 |
freemangordon | so I will add a parameter | 18:00 |
freemangordon | whether to wait for sim or not | 18:00 |
Wizzup | ok | 18:00 |
freemangordon | and if not in flightmode to online the modem | 18:00 |
Wizzup | instead of icd2? | 18:01 |
freemangordon | well, icd onlines the modem only if you open the connections dialog, no? | 18:01 |
freemangordon | we want modem online way earlier | 18:02 |
freemangordon | also, IIRC icd2 does it only if needed | 18:02 |
freemangordon | so we will want to keep the code there | 18:02 |
freemangordon | example: | 18:02 |
freemangordon | flightmode on boot, you say "do not exit flightmode" to SPQ, then you select connections dialog and wat to exit flightmode | 18:03 |
freemangordon | s/wat/want | 18:03 |
freemangordon | icd2 onlines the modem | 18:03 |
freemangordon | makes sense? | 18:03 |
Wizzup | ok | 18:09 |
uvos | android dosent randomly have pinentry run btw | 18:10 |
uvos | this is a quirk of the motorola implementation | 18:10 |
freemangordon | how does it handle sim swap? | 18:11 |
uvos | it runs "randomly" (well directly after sim insertion) | 18:11 |
uvos | but on statup it waits | 18:11 |
uvos | so that the device cant be used with locked sim | 18:11 |
freemangordon | same | 18:12 |
uvos | but imo this bhavior is sensless security theater | 18:12 |
freemangordon | mhm | 18:12 |
freemangordon | ugh, ofono crashed | 18:17 |
Wizzup | uvos: directly after sim insertion, or two minutes after sim insertion? | 18:18 |
uvos | pretty fast | 18:18 |
uvos | not 2 minutes | 18:18 |
uvos | several seconds | 18:18 |
uvos | but its incosistant | 18:18 |
uvos | i have seen it not see the sim for quite some time on boot for instanve | 18:19 |
uvos | *instance | 18:19 |
uvos | but usualy its fairly fast | 18:19 |
uvos | i dont think i have ever seen android take 2 minutes | 18:19 |
uvos | more like 30s tops but usally <10 | 18:20 |
freemangordon | uvos: I think mce shall send SCRN on startup as well | 18:21 |
freemangordon | not only on unlock | 18:21 |
uvos | dose the modem start with scrn=0? | 18:21 |
uvos | then sure yes | 18:21 |
freemangordon | I guess | 18:21 |
freemangordon | as it is offline | 18:21 |
uvos | but i dose send scrn=1 or? | 18:22 |
freemangordon | no | 18:22 |
uvos | since the display datapipe is triggerd on startup | 18:22 |
uvos | it should i think | 18:22 |
freemangordon | lemme paste | 18:22 |
uvos | the question is if we want mce to do this directly at all | 18:22 |
uvos | or if ofono can somehow abstract it? | 18:23 |
uvos | mabye it has modem idle states? | 18:23 |
uvos | that we could wire up | 18:23 |
freemangordon | see https://pastebin.com/7H3atLkC | 18:23 |
freemangordon | well, I guess we can write ofono plugin (like the one for upower) | 18:23 |
freemangordon | that handles screen lock/unlock | 18:23 |
uvos | sure | 18:23 |
uvos | if we can teach ofono to abstract scrn | 18:24 |
uvos | that would then be best since it would work on other devices too | 18:24 |
freemangordon | it shoudl already have some support for power states | 18:24 |
freemangordon | mhm | 18:24 |
freemangordon | see pastebin^^^ | 18:24 |
freemangordon | this is boot log | 18:24 |
freemangordon | SCRN comands you see are screen lock/screen unlock | 18:24 |
freemangordon | immediately after SCRN=1 you have MSIM | 18:25 |
uvos | and modem dosent send rssi after onlineing it? | 18:25 |
freemangordon | it is offline | 18:25 |
uvos | if you dont set SCRN=1 | 18:25 |
uvos | by hand | 18:25 |
freemangordon | I modem is offline | 18:25 |
uvos | sure but if you dont start mce at all and online the modem | 18:25 |
uvos | dose it then start reporting rssi | 18:25 |
uvos | i think it dose iirc | 18:25 |
freemangordon | I don;t care about RSSI | 18:25 |
freemangordon | but about MSIM | 18:25 |
uvos | but thats what scrn dose mainly no? | 18:26 |
uvos | enable disable rssi? | 18:26 |
freemangordon | not so sure | 18:26 |
freemangordon | maybe it affects MSIM as well | 18:26 |
uvos | hmm | 18:26 |
freemangordon | see the log | 18:26 |
freemangordon | about a second after SCRN:OK we have MSIM | 18:26 |
freemangordon | could be coincidence, but I doubt | 18:27 |
uvos | that might just be scrn kicking the modem | 18:27 |
uvos | try issueing something else | 18:27 |
freemangordon | lemme keep it unlocked and see | 18:27 |
freemangordon | right | 18:28 |
freemangordon | it is kicking the modem | 18:28 |
uvos | Wizzup seeing sim after 2 min | 18:29 |
uvos | is probubly mces 2min kick timer | 18:29 |
uvos | (it also explicitly kicks it at this interval) | 18:29 |
freemangordon | if he relock he will see sooner :) | 18:29 |
uvos | so the kernel is missing an irq or something is going on | 18:30 |
freemangordon | mhm | 18:30 |
freemangordon | Wizzup: what is the cheapest (code-wise) way to call "online-modem"? | 19:10 |
freemangordon | hmm, do we plan to support hot-plugging of modems? | 19:15 |
uvos | we must for pp | 19:15 |
uvos | because of the kill switch | 19:16 |
uvos | iiuc | 19:16 |
freemangordon | The more I think about that, the more I am getting convinced we must have a daemon that takes care of modems | 19:16 |
uvos | thats kinda ofono tho no? | 19:16 |
freemangordon | Not really | 19:17 |
freemangordon | you shoudl explicitly enable and online the modems | 19:17 |
freemangordon | unless we are in flight mode | 19:17 |
freemangordon | Wizzup: shall I extend icd2 ofono plugin? | 19:17 |
freemangordon | to take care of flight mode and online/offline modems according to it? | 19:18 |
Wizzup | that is possible, but I think we should also think if we should maybe have one thing 'manage' most of this, and if that should be icd2 | 19:28 |
Wizzup | the icd2 one if libgofono atm | 19:29 |
Wizzup | one if -> one is | 19:29 |
Wizzup | I know how to make the context code work well now I think, but I didn't write it yet | 19:29 |
freemangordon | Wizzup: that's why I want to implement onlining the modem in icd2 ofono plugin | 19:45 |
freemangordon | ah, "if that" | 19:45 |
freemangordon | well... | 19:46 |
freemangordon | icd2 already has lots of code for that | 19:46 |
freemangordon | but yeah, we shall decide on it | 19:47 |
freemangordon | whether to write some daemon or extend icd2 | 19:47 |
Wizzup | right | 19:52 |
freemangordon | honestly, I think daemon is the correct thing to do | 19:52 |
freemangordon | cellulard? celld? | 19:54 |
Wizzup | freemangordon: I would just make it part of some daemon imho | 20:14 |
Wizzup | maybe mce | 20:14 |
Wizzup | or maybe just icd2 | 20:14 |
Wizzup | but I suppose uninstalling icd2 internet context plugin should not break modem | 20:14 |
freemangordon | I don't think mce is tha correct place | 20:15 |
freemangordon | *the | 20:15 |
freemangordon | why not dedicated daemon? | 20:15 |
Wizzup | I don't really like more daemons I suppose, but I guess we can | 20:17 |
Wizzup | I guess nokia had its own daemon | 20:17 |
Wizzup | (csd?) | 20:17 |
freemangordon | mhm | 20:17 |
freemangordon | and not only | 20:17 |
Wizzup | and all this would do it power and online modem depending on offline mode? | 20:17 |
Wizzup | would do is* | 20:17 |
freemangordon | mhm | 20:18 |
Wizzup | I mean it feels a bit much to have a modem just for that | 20:18 |
freemangordon | I guess you mean 'daemon just...' | 20:18 |
Wizzup | online/offline "mode" might fit mce's mode plugins | 20:18 |
Wizzup | freemangordon: yes | 20:18 |
freemangordon | but then we shall teach mce to talk to ofono | 20:18 |
Wizzup | in a plugin over dbus, right | 20:19 |
freemangordon | and mce shall run in actdead as wll | 20:19 |
Wizzup | I suppose it also saves some ram if we do it this way | 20:19 |
Wizzup | I don't mind the separate daemon, but yeah | 20:19 |
freemangordon | not really, as it will be .launch anyway | 20:19 |
freemangordon | so there will be almost no overhead, if any | 20:19 |
sfa | Hello | 20:20 |
freemangordon | hello | 20:20 |
freemangordon | Wizzup: so, cellulard? | 20:20 |
Wizzup | freemangordon: if you ask me mce is a good fit really | 20:20 |
Wizzup | but I am fine with either I suppose | 20:20 |
sfa | I just installed Maemo-Leste on my Pinephone .... I used to ues Maemo on my N810 many years ago. | 20:20 |
freemangordon | no, please, lets not make yet another systemd | 20:20 |
freemangordon | I mean... | 20:21 |
Wizzup | freemangordon: it's literally a mode for the mode control entity, but ok | 20:21 |
Wizzup | again, no strong opinions either way | 20:21 |
sfa | I'm guessing there's no default cellphone app on maemo-leste and I'll need to insteall something like ofono? | 20:21 |
sfa | Is there a recommended app for phone and texting? | 20:21 |
freemangordon | sfa: what we are discussing ATM is exactly cellular stuff | 20:21 |
Wizzup | sfa: there is a call app, but the app and the other packages are not included in the standard repo | 20:21 |
freemangordon | but, all this is in development | 20:21 |
sfa | freemangordon: ah I see | 20:22 |
Wizzup | I haven't tried it yet on my PP recently | 20:22 |
Wizzup | but our stuff works good enough for call/text on the droid 4, so I imagine it might work | 20:22 |
sfa | Wizzup: cool thansk, I guess I need the "extra" repo? | 20:22 |
Wizzup | no, beowulf-devel | 20:22 |
sfa | ah okay | 20:22 |
Wizzup | I don't know if instructions exist, we're trying to get it all to stable so we don't need to provide the instructions :) | 20:22 |
sfa | Wizzup: nice! | 20:22 |
freemangordon | Wizzup: re mce - if we go that route, we shall also write wifi module tehre | 20:23 |
freemangordon | *there | 20:23 |
Wizzup | one of these days we'll get the meta package set up and such, right now I don't have the right answer atm, I can look later today or tomorrow or a package list | 20:23 |
Wizzup | freemangordon: wifi isn't really an on/off mode I think | 20:23 |
Wizzup | but I am fine if you want a separate daemon | 20:23 |
freemangordon | does not matter. it still shall obey flightmode | 20:23 |
freemangordon | ok, will write cellulard then | 20:24 |
Wizzup | sfa: you want beowulf-devel repo and then at least install hildon-connectivity-mobile | 20:24 |
Wizzup | sfa: to be clear beowulf-devel supplements regular beowulf repo from us | 20:24 |
sfa | Wizzup: awesome! let me go try that! Thanks! | 20:24 |
freemangordon | sfa: don;t expect miracles though :) | 20:25 |
freemangordon | as I said - this is still WIP | 20:25 |
sfa | it's probably better than default image that comes with the pinephone that is horrible. :) | 20:26 |
Wizzup | maemo leste should work pretty smooth, especially if you upgrade from -devel repo | 20:26 |
Wizzup | (faster 2d/3d) | 20:26 |
freemangordon | Wizzup: maybe we shall push that to stable | 20:26 |
freemangordon | mesa/clutter that is | 20:27 |
sfa | deb https://maedevu.maemo.org/leste beowulf-devel main contrib non-free <device_name> where devicename = {droid4 or pinephone or whatever} is that correct? | 20:28 |
freemangordon | Wizzup: hmm, wouldn't ofono-cellulard be more appropriate name? | 20:28 |
Wizzup | freemangordon: I think it is more maemo specific than ofono specific, well, I guess both | 20:31 |
freemangordon | ok, will see | 20:31 |
Wizzup | sfa: yeah just copy the maedevu beowulf line, paste it, and make it beowulf-devel | 20:31 |
sfa | cool thanks. | 20:33 |
Wizzup | freemangordon: yeah, there is more to push to stable I think | 20:35 |
freemangordon | Wizzup: all calls to g_variant_print() in wpaicd.c leak memory | 21:55 |
Wizzup | freemangordon: yikes | 22:08 |
freemangordon | Wizzup: could you help me with thos gvariant things | 22:09 |
freemangordon | I have a dbus signal, and g_variant_print() results in "signal ('normal',)" | 22:10 |
freemangordon | how shall I get the value? | 22:10 |
freemangordon | g_variant_get (value, "s", &result); | 22:10 |
freemangordon | or g_variant_get (value, "g", &result); | 22:10 |
Wizzup | need a moment to dive back into this | 22:11 |
Wizzup | is this in wpasupplicant? | 22:12 |
freemangordon | no | 22:12 |
freemangordon | this is in my code | 22:12 |
Wizzup | freemangordon: ah yeah I think that's hidden behind the debug compile, maybe I didn't fix it because of that | 22:13 |
freemangordon | yeah, but still | 22:13 |
freemangordon | anyway, can you help with "signal ('normal',)" | 22:13 |
Wizzup | so do you know what type the variant is> | 22:13 |
freemangordon | what is 'signal' in terms of GVariant | 22:13 |
freemangordon | it is string | 22:13 |
freemangordon | this is MCE_DEVICE_MODE_SIG signal | 22:14 |
Wizzup | what are the old gnome doc links | 22:14 |
Wizzup | old-developer | 22:14 |
Wizzup | no | 22:14 |
Wizzup | developer-old | 22:14 |
freemangordon | this https://www.freedesktop.org/software/gstreamer-sdk/data/docs/latest/glib/glib-GVariant.html | 22:14 |
Wizzup | https://developer-old.gnome.org/glib/stable/glib-GVariantType.html | 22:14 |
freemangordon | ? | 22:14 |
Wizzup | so I think you need to know the type to get the value | 22:15 |
Wizzup | you can probably print the type of the variant as well | 22:15 |
freemangordon | well, "signal ('normal',)" is the result of g_variant_print() | 22:16 |
freemangordon | so I guess the type is signal :) | 22:16 |
Wizzup | there is no such type in gvarianttype iiuc | 22:16 |
Wizzup | https://developer-old.gnome.org/glib/stable/glib-GVariant.html#g-variant-get-type | 22:17 |
freemangordon | well, why it prints it then? | 22:17 |
freemangordon | maybe dbus signature? | 22:17 |
Wizzup | maybe you need to unpack the dbus variable first to get the gvariant? | 22:18 |
Wizzup | I don't really know, maybe it's a custom registered variable | 22:19 |
freemangordon | ok | 22:19 |
Wizzup | sorry | 22:20 |
freemangordon | np | 22:20 |
freemangordon | Wizzup: ugh, I am stupid :) | 22:21 |
freemangordon | this 'signal' thingie is just a string I printf() ;) | 22:22 |
freemangordon | the signature is (s) otherwise | 22:22 |
Wizzup | ha | 22:22 |
uvos | mce runs in actdead anyhow | 22:24 |
uvos | in fremantle | 22:24 |
freemangordon | yes, thats why I don;t want to pull ofono stuff into it | 22:25 |
uvos | but i would strongly strongly strongly STRONGLY suggester never to use the "actdead" method of implementing what actdead implements in fremantle | 22:25 |
uvos | its an extreamly lame implementation | 22:25 |
freemangordon | well, we shall have some runlevel that implements that | 22:25 |
uvos | right | 22:25 |
freemangordon | I think we already agreed on that :) | 22:26 |
uvos | in this runlevel you just dont run the deamon (whatever onlines the modem) | 22:26 |
uvos | and this deamon offlines the modem on exit | 22:26 |
uvos | so when runlevel is switched to "actdead" | 22:26 |
uvos | modem offlines and thats that | 22:26 |
uvos | or do we need it? | 22:27 |
freemangordon | ok | 22:27 |
freemangordon | I think no | 22:27 |
freemangordon | basically we show alarms (or charge there) | 22:27 |
uvos | right | 22:27 |
uvos | i honestly think icd is the most sane | 22:29 |
uvos | since as you point out wifi also has to obay flightmode | 22:29 |
freemangordon | it already does | 22:30 |
uvos | and icd is the most sane place to put that | 22:30 |
uvos | and then icd reacts to flight mode, and it handles cellular too for data | 22:30 |
uvos | so it allready has all bits | 22:30 |
uvos | so just add this one little thing | 22:30 |
uvos | i dont think voice has to work without icds cellular module really | 22:30 |
uvos | i also kinda think a deamon just to online the modem is overkill | 22:32 |
freemangordon | let me finish what I started already, I think it will be some 100 LOC | 22:32 |
freemangordon | not really, as .launch will make it more or less free for us | 22:32 |
uvos | uh mameo-launcher dosent make a process context any cheaper | 22:35 |
uvos | freemangordon: btw should we even have a "flight mode" | 22:45 |
uvos | freemangordon: i dont think so | 22:45 |
freemangordon | what? | 22:45 |
freemangordon | wtym? | 22:45 |
uvos | freemangordon: we should just have 2 toggle switches, one for wifi one for mobile data | 22:45 |
uvos | well flight mode is sensless | 22:45 |
freemangordon | no | 22:45 |
Wizzup | I don't think flight mode is about mobile data | 22:45 |
uvos | it used to make sense because it was a thing required in flight | 22:45 |
freemangordon | all radios shall be turned off | 22:45 |
Wizzup | uvos: they still do | 22:46 |
uvos | but its not true anymore | 22:46 |
freemangordon | it is | 22:46 |
Wizzup | all the planes I go on anyway | 22:46 |
uvos | no they require cellular radios to be of | 22:46 |
uvos | thats a different thing | 22:46 |
freemangordon | at least was last time I was on-board (an year ago) | 22:46 |
Wizzup | that's not the same as mobile data? | 22:46 |
uvos | android no longer turns all radios off in flight mode | 22:46 |
uvos | it turns just the cellular modem off | 22:46 |
Wizzup | uvos: so can you be called in flight? | 22:46 |
freemangordon | how noce | 22:46 |
uvos | no | 22:46 |
freemangordon | *nice | 22:46 |
Wizzup | I think we're saying the same thing? | 22:46 |
uvos | xno | 22:46 |
Wizzup | uvos - are you talking about bluetooth or something? | 22:46 |
uvos | so on old phones and old android | 22:46 |
uvos | flight mode = all radios off | 22:46 |
uvos | now flight mode = just cellular modems off (gsm utms lte 5g etc) | 22:47 |
uvos | becuase thats how the laws changed | 22:47 |
Wizzup | that's mostly what our flight mode would do | 22:47 |
freemangordon | and what is on? wifi/bt? | 22:47 |
uvos | yes any other radio | 22:47 |
freemangordon | what other radio? | 22:47 |
uvos | that includes wifi bt | 22:47 |
freemangordon | ah | 22:47 |
Wizzup | freemangordon: fm I suppose | 22:47 |
uvos | so flight mode is just a wierd name of cellular off now | 22:47 |
uvos | we could ditch that | 22:48 |
freemangordon | well, actually mce supports normal/flight/offline modes | 22:48 |
uvos | and just call it what it is | 22:48 |
uvos | and have 3 toggle switches somewhere | 22:48 |
freemangordon | no, please | 22:48 |
uvos | Ie cellular off, bt off wifi off and fm off | 22:48 |
freemangordon | this will become nightmare | 22:48 |
Wizzup | uvos: we already have bt off, we have wifi off (through applet), we have flight mode which is cellular | 22:48 |
Wizzup | I think we're there already | 22:49 |
uvos | yeah but flight mode turns off all radios | 22:49 |
Wizzup | uvos: well, "we" don't have bt off yet, but we will once we have the fremantle stuff in place | 22:49 |
uvos | (as was required by law untill 2012 or so) | 22:49 |
uvos | but that means we have no state where wifi and bt and so on can be on | 22:49 |
uvos | but cellular is off | 22:49 |
freemangordon | ok, but right now, noone turns cellular radios off | 22:49 |
freemangordon | so, this is what I am implementing | 22:49 |
Wizzup | freemangordon: btw regarding the wpaicd.c memleak, do you have a recommendation on how to fix it other than make a tmp var, and free it after the print? | 22:50 |
freemangordon | and, as I said, we support 3 modes | 22:50 |
freemangordon | Wizzup: not really | 22:50 |
Wizzup | ok | 22:50 |
freemangordon | uvos: so, lemme implement what flightmode is supposed to do in terms of cellular | 22:50 |
uvos | sure | 22:51 |
uvos | i was just suggesting renameing it | 22:51 |
freemangordon | then we can think of changing other daemons to listen for "offline" mode and acti accordingly | 22:51 |
freemangordon | *act | 22:51 |
uvos | since the name is a legacy artifact | 22:51 |
freemangordon | it is not, we still need 'flight' mode. maybe it is not correctly handled ATM, but this is another story | 22:51 |
uvos | if your flight mode just turns off cellular sure | 22:53 |
uvos | since thats all thats requried in flight | 22:53 |
Wizzup | freemangordon: https://github.com/maemo-leste/libicd-network-wpasupplicant/commit/ea027fa16da11b61d9b93a1c86a705f5eba27aba | 22:53 |
uvos | otherwiese its a name thats also wrong and should just be call all offline or radios off or something | 22:53 |
freemangordon | right | 22:53 |
freemangordon | Wizzup: ^^^ | 22:53 |
Wizzup | fine by me | 22:53 |
freemangordon | but I would create a macro | 22:54 |
Wizzup | I considered it but didn't want to | 22:54 |
Wizzup | :D | 22:54 |
Wizzup | if there were more I would have | 22:54 |
freemangordon | well... up to you :) | 22:54 |
Wizzup | I know it's not that clean, I'll remove the prints later in any case | 22:54 |
Wizzup | there is one more bug I have to hunt for | 22:54 |
freemangordon | uvos: I understand your reasoning and agree with it | 22:54 |
uvos | btw do we really have wifi off? | 22:56 |
uvos | where is it? | 22:57 |
uvos | @Wizzup since you mentioned it | 22:57 |
freemangordon | in icd2 | 22:58 |
Wizzup | uvos: bencoh made the applet | 22:59 |
uvos | ah its not preinstalled | 22:59 |
Wizzup | right, it's also (I suppose) a bit more clunky than something in settings | 22:59 |
uvos | ok sure | 22:59 |
sicelo | freemangordon: in the 3 modes, what's difference between flight and offline mode? | 23:16 |
freemangordon | in flight mode only cellular is off | 23:17 |
sicelo | as for flight mode in old android, there's still flight mode (with a plane icon) on my Android One (Android 12) phone. so not sure about "old android" | 23:18 |
freemangordon | the point is that it turns only cellular radios off | 23:19 |
freemangordon | wifi/bt remain intact | 23:19 |
sicelo | i guess what you call flight mode is what people on tmo call 'tablet mode' | 23:20 |
freemangordon | that would be "offline" mode | 23:20 |
freemangordon | I guess | 23:21 |
sicelo | no. offline is what you get on power key. that one turns everything off. you can't even enable wifi or bt in offline mode | 23:21 |
freemangordon | mhm | 23:21 |
sicelo | ah, actually you can enable bt, but not wlan. trying to connect to wlan pops up a request to exit offline mode | 23:22 |
sicelo | scratch that ... you can't even enable bt. that results in request to exit offline mode too | 23:22 |
sicelo | anyway i think we're all in agreement with the 3 proposed modes :-) | 23:23 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!