| Wizzup | btw, we passed the first round for nlnet funding, but there is another round, if we pass that, the organisation will get more funding | 00:58 |
|---|---|---|
| buZz | wow, this stardict has a LOT of dicts available O_o | 04:19 |
| buZz | Wizzup: sweet! :) | 04:19 |
| buZz | stardict-Britannica_Pocket_Encyclopedia-2.4.2.tar.bz2 stardict-Oxford_Dictionary_of_Quotations-2.4.2.tar.bz2 stardict-CIAWorldFactbook2007_1.0-2.4.2.tar.bz2 stardict-The_Oxford_World_Encyclopedia-2.4.2.tar.bz2 | 04:20 |
| buZz | stardict-Australian_Slang-2.4.2.tar.bz2 stardict-Dictionary_of_Phrase_and_Fable1.1-2.4.2.tar.bz2 stardict-Microsoft_Computer_Dictionary-2.4.2.tar.bz2 | 04:21 |
| buZz | endless | 04:21 |
| buZz | stardict-Obscene_language_En-Ru-2.4.2.tar.bz2 lol | 04:37 |
| buZz | ah yes stardict-Urban_Dictionary_P1-2.4.2.tar.bz2 :D | 04:37 |
| buZz | annnd mirror is up @ http://space.nurdspace.nl/~buzz/maemo/stardict-dic/ | 04:40 |
| buZz | horrible mess of weird indexes :P but it works | 04:40 |
| freemangordon | uvos__: DND flag is needed as mce starts inactivity timeout when vtklock is shown | 08:15 |
| freemangordon | so, if tklock time displaying unlock screen is bigger than blanking period, we'll have dim and re-lock and whatnot else | 08:16 |
| uvos__ | freemangordon: ok you could also disable inactivity in tklock mode here https://github.com/maemo-leste/mce/blob/5db7a12f02fbc7205a94ad99e85d662c2e6b79d7/src/modules/inactivity.c#L95 | 08:24 |
| uvos__ | but fixing DND is fine too ofc | 08:24 |
| freemangordon | I think it is better to not add (more) special code in mce only for tklock | 08:24 |
| uvos__ | sure lock-tklock is a big mess allready | 08:25 |
| buZz | tklock is the application with the swipe to the right for unlock, right? | 08:27 |
| uvos__ | if only it was only that xD | 08:27 |
| buZz | if you're modifying that, could you add a 'turn off screen if you press powerbutton again' :D | 08:27 |
| uvos__ | it has tenticals | 08:27 |
| buZz | every time i press it by accident , screen is on, but needs to unlock plus lock again before i can force it off | 08:28 |
| uvos__ | i found that annoying too | 08:28 |
| freemangordon | hmm, what? | 08:28 |
| buZz | :) wonder if that was on n900 aswell | 08:28 |
| freemangordon | it re-lock in 4 seconds | 08:28 |
| freemangordon | *re-locks | 08:28 |
| buZz | oh? | 08:28 |
| uvos__ | yes | 08:28 |
| uvos__ | but you have to wait afaik | 08:28 |
| uvos__ | on n900 you can use slider | 08:29 |
| buZz | 4 seconds and not press something in between perhaps? | 08:29 |
| freemangordon | yes | 08:29 |
| buZz | or touchscreen | 08:29 |
| freemangordon | yes | 08:29 |
| buZz | thats hard to do in a pants pocket :D | 08:29 |
| freemangordon | it is capacitive, what is the issue? | 08:29 |
| buZz | hehe, no issue, just slight annoyance | 08:29 |
| freemangordon | no, I mean - it is capacitive, does not matter if it is in a pocket or not, no accident presses are registered | 08:30 |
| uvos__ | buZz: you can use lock-generic and just avoid the thing if you do like it | 08:30 |
| uvos__ | thats what i do | 08:30 |
| uvos__ | freemangordon: depends | 08:30 |
| buZz | lock-generic isnt hildon/maemo, you mean? | 08:30 |
| uvos__ | i get random presses though my pocket | 08:31 |
| buZz | freemangordon: eh, no , i mean when my hand is in pocket for something else | 08:31 |
| freemangordon | buZz: you don;t want to, you'll be missing missed calls/emails/etc on the lock screen | 08:31 |
| uvos__ | buZz: its a mce mdoule that triggers xdg-screensaver instead of tklock | 08:31 |
| buZz | freemangordon: oh? it can show that? :D | 08:31 |
| buZz | that would be awesome | 08:31 |
| freemangordon | it *does* show that | 08:31 |
| uvos__ | it cant atm | 08:31 |
| freemangordon | why do you think so? | 08:31 |
| uvos__ | becasue we dont tell it | 08:31 |
| freemangordon | for sure it should work for emails | 08:32 |
| freemangordon | modest tells it | 08:32 |
| buZz | i just havent seen it | 08:32 |
| uvos__ | sure emails might work, but everything else dosent | 08:32 |
| freemangordon | at least it should | 08:32 |
| freemangordon | also conversations will do, once it is finished | 08:32 |
| uvos__ | sure | 08:32 |
| uvos__ | but rn, no | 08:32 |
| buZz | btw if you want a test XMPP contact, i'm almost always online with droid4 on buzz@space.nurdspace.nl | 08:32 |
| freemangordon | also, if sphone starts adding missed calls in rtcom db, those will appear too | 08:33 |
| uvos__ | nope | 08:33 |
| uvos__ | it dose do so | 08:33 |
| uvos__ | you need to trigger tklock by hand in sphone iiuc | 08:33 |
| buZz | atm best 'missed calls' view for me is osso-abook's 'recent' :) | 08:33 |
| buZz | also 'missed sms' | 08:33 |
| freemangordon | uvos__: https://github.com/maemo-leste/osso-systemui-tklock/blob/master/visual-tklock.c#L304 | 08:34 |
| uvos__ | thats not the rtcom database | 08:34 |
| freemangordon | so it is notifications | 08:34 |
| uvos__ | right | 08:34 |
| freemangordon | right, but still the same | 08:34 |
| uvos__ | sphone saves to rtcom-el | 08:34 |
| freemangordon | if you call libnotify, it will start working | 08:35 |
| * buZz afk for most the day , bye | 08:36 | |
| uvos__ | anyhow i still also disklike how tklock is implemented | 08:36 |
| uvos__ | but thats another story | 08:36 |
| freemangordon | yeah, it can be better | 08:36 |
| freemangordon | and I'll make it better when it comes to it | 08:37 |
| freemangordon | including plugins and what not | 08:37 |
| freemangordon | but for now, I would say it is good enough | 08:37 |
| uvos__ | btw plase add a bug for the mce dbus while dimmed problem | 08:38 |
| uvos__ | just a copy of the irc log at the time is fine | 08:38 |
| freemangordon | ok | 08:39 |
| freemangordon | uvos__: what is this? https://github.com/maemo-leste/mce/commit/5a7c111790ecf9b15bf6e7a05a671255de8cae6c | 08:43 |
| freemangordon | and why it is not in master | 08:43 |
| freemangordon | ? | 08:43 |
| uvos__ | oh thats something that slipped into there by accident (i have a branch where lock-generic dose proximity lock) | 08:45 |
| freemangordon | shall I revert? | 08:45 |
| freemangordon | well, actually reset to master | 08:45 |
| freemangordon | and force-push? | 08:45 |
| freemangordon | well, I will do | 08:46 |
| uvos__ | if you like, but really its fine no and fixes some warnigs about triggers not remvoed on exit | 08:46 |
| uvos__ | the only problem here is the commit it comes with | 08:46 |
| uvos__ | not the code | 08:46 |
| freemangordon | that one too | 08:47 |
| uvos__ | please keep the diff | 08:47 |
| freemangordon | keep it where? some other branch? | 08:47 |
| uvos__ | no in master | 08:47 |
| freemangordon | ah, you want to cherry-pick in master? | 08:47 |
| uvos__ | the additions of remove_input_trigger_to_datapipe are nessecary | 08:47 |
| uvos__ | they fix a real issue (runtime warnings) | 08:48 |
| uvos__ | how you keep the diff, i dont care | 08:48 |
| freemangordon | diff == commit? | 08:48 |
| uvos__ | the changes themselfs | 08:48 |
| freemangordon | ok, but what whould be the correct commit message? | 08:48 |
| uvos__ | lock-generic: fix warnings on exit about datapipes still haveing registered triggers. | 08:49 |
| freemangordon | ok | 08:49 |
| freemangordon | uvos__: this commit don;t even compile | 09:01 |
| freemangordon | /build/mce-1.10.0+2m7/src/modules/lock-generic.c:198:60: error: 'proximity_sensor_trigger' undeclared (first use in this function); did you mean 'proximity_sensor_pipe'? | 09:02 |
| freemangordon | so I'll remove it for now | 09:02 |
| uvos__ | ok | 09:03 |
| uvos__ | ill look at it when it do the other stuff | 09:03 |
| uvos__ | just nix it now then | 09:03 |
| freemangordon | mhm | 09:03 |
| Wizzup | buZz: cool | 10:30 |
| Wizzup | buZz: got some doc / maybe wiki page? | 10:30 |
| freemangordon | uvos__: you shouldn't have removed that https://github.com/community-ssu/mce/blob/88a69e02c61e24aa272e1f63971e03424c051b09/modules/display.c#L1367 | 12:17 |
| freemangordon | without this display blanks before h-d had started | 12:18 |
| freemangordon | going to restore it | 12:18 |
| freemangordon | unless you have some other idea | 12:18 |
| freemangordon | I don;t really understand why did you remove all that code, I see nothing wrong with it, could you elaborate? | 12:26 |
| uvos__ | im not sure what all that code is for you | 12:44 |
| uvos__ | also note that the display module was split and stuff was implemented elswehere that was implemented there before | 12:44 |
| uvos__ | also some behavior changes where nessecary for the mce but not hildon usecase | 12:44 |
| uvos__ | i cant a-prioi say where that bit whent | 12:45 |
| uvos__ | it def dosent belong in display anymore | 12:45 |
| uvos__ | the splitting and compartmentailzation of module functions was done with the goal of allowing you to load different modules where required for different devices and wms | 12:47 |
| uvos__ | pretty sucessfully i think | 12:47 |
| uvos__ | *a priori | 12:48 |
| uvos__ | btw i dislike that you incremented the minor version as oposed to patch, i only want to do that for breaking changes | 12:50 |
| uvos__ | mce 1.9.0 broke the use of the fremantle kenrel | 12:50 |
| uvos__ | we cant increment the major version at all | 12:50 |
| uvos__ | because it clashes wih sfos mce | 12:51 |
| buZz | Wizzup: doc/wiki about the stardict? | 13:26 |
| buZz | mstardict* | 13:26 |
| buZz | ? | 13:26 |
| buZz | its really quite minimal , but i guess i could write something yeah | 13:26 |
| Wizzup | buZz: we try to have a wiki page for every extra pkg | 13:29 |
| Wizzup | there's a few already | 13:29 |
| Wizzup | with template | 13:29 |
| buZz | ooo very nice | 13:30 |
| buZz | Wizzup: i also wanted to attempt to upgrade sfeed, as the lead(? are there others)-dev is in #nurds since recently | 13:32 |
| buZz | he made a issue for a upgrade | 13:32 |
| freemangordon | uvos__: ugh, that netsplit lost my reply :( | 14:05 |
| freemangordon | (14,55,28) freemangordon: uvos__: well, we have API change (breaking or not), so I think it makes sense to increase the minor | 14:06 |
| freemangordon | (14,56,53) freemangordon: I am not saying that split was a bad thing, the point is that because of the split it is impossible (or I don;t know how) to track when a particular piece of code was changed or removed | 14:06 |
| freemangordon | (14,57,53) freemangordon: and now it is very hard to my to play the "find the differences" game when I see obvious difference in behaviour compared to fremantle | 14:06 |
| freemangordon | (14,58,47) freemangordon: see, I am not complaining, I am just trying to understand the reasoning behind some decisions you made | 14:06 |
| freemangordon | (14,59,46) freemangordon: especially when those decisions change how mce behaves and were made by you alone, most probably | 14:06 |
| uvos__ | "well, we have API change (breaking or not), so I think it makes sense to increase the minor" i have added a lot of apis to mce, so its at the very least not consistant now. anyhow its not a big deal - its just breaking the covention i had been using | 14:07 |
| freemangordon | ok, sorry, will keep in mind for the future | 14:11 |
| * buZz hugs uvos__ and freemangordon | 14:20 | |
| buZz | :) | 14:20 |
| uvos__ | freemangordon: wrt the other porblem yeah i can see it makes it harder, but genneraly it was nessecary to support all the configureations mce now dose. | 14:21 |
| uvos__ | buZz: xD | 14:21 |
| buZz | :) | 14:21 |
| uvos__ | freemangordon: so what issue are you seeing, if you set mce to a really shot timeout it blanks on boot before tklock can lock the blanking out via dnd? | 14:22 |
| sicelo | freemangordon: is that how your time is displayed normally? HH,MM,SS (commas) :-o | 14:28 |
| freemangordon | sicelo: this is how pidgin displays it, no idea why but not a biggie | 15:55 |
| freemangordon | uvos__: the issue I am seeing is that if charge mode is entered, and then exited (via the power button) display gets blanked before h-d starts | 15:55 |
| freemangordon | this might or might not be a consequence from removing the code in question | 15:56 |
| uvos__ | mce dosent run in charge mode | 15:57 |
| uvos__ | so the time spent in charge mode is immaterial | 15:57 |
| freemangordon | right | 15:57 |
| freemangordon | but somehow it manages do blank the screen after that | 15:57 |
| uvos__ | i doubt mce starts >30s before h-d/systemui | 15:57 |
| uvos__ | so i doubt its this | 15:58 |
| uvos__ | freemangordon: ok | 15:58 |
| uvos__ | dose the log say why | 15:58 |
| freemangordon | didn;t look at | 15:58 |
| freemangordon | :) | 15:58 |
| uvos__ | maybe its picking up the power button press? | 15:58 |
| uvos__ | somehow | 15:58 |
| freemangordon | lemme take the log | 15:58 |
| uvos__ | you need to make it verbose for it to be usefull | 15:58 |
| freemangordon | it is | 15:59 |
| freemangordon | but it become huge | 15:59 |
| uvos__ | i also dont see this | 15:59 |
| freemangordon | is there any way to force-enter charge mode? | 15:59 |
| uvos__ | no | 15:59 |
| norayr | Wizzup, may it be i can blacklist something on droid3 to test if that can make it more stable? | 15:59 |
| freemangordon | ok, then it will take time | 15:59 |
| freemangordon | I have to deplete the battery first | 15:59 |
| uvos__ | ok | 15:59 |
| uvos__ | so i dont see this problem | 16:00 |
| norayr | oh, on the battery, so 'capacity' in 'upower' means that the battery has so much of its original capacity? | 16:00 |
| uvos__ | so i suspect tklock/systemui interactions again | 16:00 |
| freemangordon | could be | 16:00 |
| norayr | i have 37 with this battery. | 16:00 |
| freemangordon | uvos__: we shall decide on what to do with voltage_now | 16:01 |
| uvos__ | filter the thing in upower (imo) | 16:01 |
| uvos__ | unless you mean in kernel | 16:01 |
| freemangordon | give that this is a hack in upower, I don;t think it is good idea mce to use it at all | 16:01 |
| freemangordon | *given | 16:01 |
| uvos__ | voltage? | 16:02 |
| freemangordon | I mean in general | 16:02 |
| freemangordon | yes, this was added by artur to upower | 16:02 |
| uvos__ | stock upower provides voltagae or? | 16:02 |
| freemangordon | no | 16:02 |
| freemangordon | it does not | 16:02 |
| uvos__ | we just added voltage charge estimateion | 16:02 |
| freemangordon | no, sec | 16:02 |
| uvos__ | *er charge from voltage estimation | 16:02 |
| freemangordon | uvos__: https://github.com/maemo-leste-upstream-forks/upower/commit/13edc4622d19056c934bab196661145de8cbce01#diff-fd1d7bb87e9710b1369c61c5704be6e31408c3480e66f119fc67ea3e0fa859acR683 | 16:05 |
| * freemangordon checks in upstream | 16:08 | |
| freemangordon | yep, no voltage I see in upstream: | 16:09 |
| freemangordon | https://gitlab.freedesktop.org/upower/upower/-/blob/master/src/linux/up-device-supply.c#L309 | 16:09 |
| uvos__ | https://github.com/freedesktop/upower/blob/0e256ece04a98d3d202ed9640d33c56aaaeda137/src/linux/up-device-supply.c#L790 | 16:10 |
| freemangordon | this is from 2017 | 16:11 |
| uvos__ | https://github.com/freedesktop/upower/blob/0e256ece04a98d3d202ed9640d33c56aaaeda137/src/linux/up-device-supply.c#L797 | 16:11 |
| uvos__ | right | 16:11 |
| uvos__ | ok | 16:11 |
| uvos__ | so its gohne | 16:12 |
| freemangordon | mhm | 16:12 |
| freemangordon | we have percentage and state | 16:12 |
| uvos__ | ok | 16:12 |
| freemangordon | I don;t think this is good though | 16:12 |
| uvos__ | well that dosent really help with the modules mission statment | 16:12 |
| uvos__ | of saveing mapphones from bootloops | 16:12 |
| freemangordon | agree | 16:12 |
| freemangordon | but, all this will break as soon as we switch to chimaera | 16:13 |
| uvos__ | ok | 16:13 |
| freemangordon | that's why "(17,01,12) freemangordon: uvos__: we shall decide on what to do with voltage_now" :) | 16:13 |
| uvos__ | well not sure what to do about this | 16:13 |
| freemangordon | oh, wait | 16:15 |
| freemangordon | seems there is new UpDeviceSupplyBattery | 16:16 |
| Wizzup | norayr: I don't think so | 16:19 |
| rafael2k | I updated my libcamera mirror repo intended for maemo use: https://github.com/rafael2k/libcamera | 16:22 |
| rafael2k | Mobian just rebased the PP* patches to 5.15.68 | 16:23 |
| rafael2k | So as soon as we test the PR I sent past week and it is all good, I'll PR the 5.15.68 rebase for the pine64 maemo kernel | 16:24 |
| rafael2k | hopefully I'll be able to get back to my camera lift up work | 16:25 |
| freemangordon | uvos__: and it does not suppoert voltage | 16:28 |
| freemangordon | what's wrong with those guys? | 16:28 |
| uvos__ | freemangordon: dident you know, batteries dont have voltages | 16:28 |
| freemangordon | yeah | 16:28 |
| freemangordon | it got dropped here https://gitlab.freedesktop.org/upower/upower/-/commit/6fedd0f20a64b9996226d0a2d26682a95aa7adb2 | 16:29 |
| uvos__ | i gues mce needs to read the kernel itself then | 16:29 |
| uvos__ | then it can also filter | 16:29 |
| uvos__ | but ugh polling | 16:29 |
| freemangordon | I think mce shall filter on battery low signal | 16:29 |
| uvos__ | or maybe we just have the kernel filter the low battery signal | 16:30 |
| uvos__ | sound sane ish to do in the kernel | 16:30 |
| uvos__ | noise is a hw problem | 16:30 |
| freemangordon | it is not low signal the issue | 16:31 |
| freemangordon | but how mce decides to do shutdown | 16:31 |
| uvos__ | also we have the problem | 16:31 |
| uvos__ | that voltage low | 16:31 |
| uvos__ | er battery low | 16:31 |
| uvos__ | dosent really mean battery at state where mapphone bootloader setup will survive boot | 16:32 |
| freemangordon | well, I don;t think we shall try to support batteries that are so worn they have 500 mAh or less capacity left | 16:32 |
| freemangordon | also, we may think of initrd | 16:33 |
| freemangordon | but, starting shutdown on 3.4 V is not sane to me | 16:33 |
| freemangordon | ok, I feel too stupid today to find a solution | 16:35 |
| freemangordon | https://gitlab.freedesktop.org/upower/upower/-/issues/212 | 16:50 |
| freemangordon | this is crazy, really | 16:50 |
| uvos | i dont think initrd helps us that mutch | 17:21 |
| uvos | the android kernel, kexecboot and the mainline kernel itself takes long to boot | 17:21 |
| uvos | userspace to charge-mode is very fast | 17:22 |
| uvos | also mbm takes suprizingly long | 17:22 |
| uvos | (probubly checksuming stuff) | 17:22 |
| uvos | im my expierance you have to shutdown at 3.25V at the very latest to have any change for it to survive, it afterall needs to stay above 3v all the way until userspace settels and 500mA becomes enough to power the device | 17:24 |
| uvos | and then we have the problem that mapphones currently use a good chunk of power even when off | 17:24 |
| uvos | if powered off via the mainline kernel | 17:25 |
| uvos | for reasons unkown (and realy hard to debug) | 17:25 |
| uvos | so thats where the 3.35v current target comes from | 17:25 |
| uvos | please also note the typical battery discharge curve | 17:26 |
| uvos | below 3.5v theres not alot at low discharge currents so at 3.3 ish volts we are not loosing mutch really | 17:26 |
| buZz | norayr: i think this was correct , yes | 18:41 |
| buZz | > 16:00:20 < norayr> oh, on the battery, so 'capacity' in 'upower' means that the battery has so much of its original capacity? | 18:41 |
| buZz | but! we cannot read out 'design capacity' reliably yet! , so its a percentage of a predetermined amount (probably wrong) | 18:41 |
| sicelo | freemangordon: upower is the weirdest fd.o project i've seen, and the one i will be glad to see obsoleted by something else asap. stock upower also bombs out on uncalibrated N900 battery | 20:01 |
| Wizzup | great, then we can port all our code -again- to the next fandy fdo thing ;p | 20:02 |
| Wizzup | fancy* | 20:02 |
| sicelo | anyway, any N900-interested folks here with a 1/2-cycle to spare? (freemangordon, tmlind perhaps?). https://paste.debian.net/1254489/ - any clues on the musb/usb issues there? | 20:03 |
| * sicelo is still bisecting however ... but any ideas/pointers will be welcome. i'm new to this thing and atm am not even sure if i'm on right track. currently git bisect has taken me to 5.17-rc6. however i know 5.18.x tagged kernels don't have the problem | 20:04 | |
| sicelo | Wizzup: the main problem i have with upower is that it tries to be too smart sometimes, and maintainers don't want anything contrary to their ideas. e.g. many people, including myself, would like to have a setting where upower doesn't take any action when it reaches the point it thinks is battery is critically low. there have even been MRs to that effect, but they're rejected with no clear reasons | 20:07 |
| * sicelo also wishes upower could be told (without forking) what voltage to consider critically low | 20:08 | |
| buZz | hmhm | 20:17 |
| sicelo | git bisect finished ... and pointed me to a completely unrelated commit :p | 21:03 |
| sicelo | here's the bisect log, https://paste.debian.net/1254497/ | 21:03 |
| Wizzup | sicelo: wrt critically low, I think that is only with elogind, no? | 21:03 |
| Wizzup | or systemd-logind | 21:03 |
| sicelo | possible | 21:10 |
| sicelo | guess i'll restart the bisection ... this is painful ): | 21:11 |
| sicelo | Wizzup: where/how do we bring up usb networking in ML? | 22:14 |
| sicelo | tried checking on GH, but couldn't find it | 22:14 |
| sicelo | i believe kernel-side it's via configfs, but i can't find where we actually do the required configfs stuff | 22:15 |
| Wizzup | hildon-usb-gadgets and ke-recv iirc | 22:21 |
| Wizzup | or ke-recv-extra I always forget | 22:21 |
| sicelo | thanks. will look | 22:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!