| norayr | MStarDict::onDownloadDictionariesMenuItemClicked(GtkButton *button, | 01:11 |
|---|---|---|
| norayr | MStarDict *mStarDict) | 01:11 |
| norayr | goes to: | 01:11 |
| norayr | http://xdxf.revdanica.com/down2/index.php?down_format=StarDict | 01:11 |
| norayr | which doesn't exist anymore | 01:11 |
| norayr | similar issue was with msid, which i ported, but one of the sites it was linked to was still available and accessible via, not http, but https. | 01:12 |
| norayr | revdanica does not exist anymore, so i don't know what to do... don't even know what was the answer of this request. | 01:12 |
| norayr | that function calls osso_rpc_run(mStarDict->osso_context, | 01:13 |
| norayr | "com.nokia.osso_browser", | 01:13 |
| norayr | "/com/nokia/osso_browser", | 01:13 |
| norayr | "com.nokia.osso_browser", | 01:13 |
| norayr | "open_new_window", | 01:13 |
| norayr | do we have com.nokia.osso_browser now? | 01:14 |
| freemangordon | how am I supposed to calibrate the battery on d4, give that device shuts down on 3.5V? | 07:58 |
| freemangordon | *given | 07:58 |
| uvos__ | it shuts down at 3.35v wich is below the cal threshold | 08:54 |
| uvos__ | "uvos__: what about "display stay lit while charging" setting?" is not implemented. it got lost when spinal replaced the old battery handling with the upower module. the upower module is without functionatliy (its interfaces are used nowhere and it dose nothing internaly besides read upower (except the battery guard module i added later that dose shutdown on low voltage)) | 08:57 |
| uvos__ | i plan to reintroduce the feature by taking the uevent code from kerecv, but have not done so | 08:58 |
| uvos__ | also in defense fo spinal the old code dident work either beacuse it read a sysfs file. | 08:58 |
| uvos__ | anyhow mce dosent know or do anything with charging or usb state really, the bug might be related to the banner appearing (this kicks mce via the dbus if iirc) | 09:01 |
| uvos__ | otherwsie idk, i have never seen it bug out at all, please give steps to repo | 09:02 |
| rafael2k | morning | 09:30 |
| rafael2k | I dont see the updated PP kernel in the repo, something happened in the build? | 09:31 |
| freemangordon | uvos__: IIRC upower module was pulled by me from nemo/mer/sailfish, but I might be wrong, it was long time ago :). Not important though. | 09:56 |
| freemangordon | ok, I'll capture a video next time it happens and will try to gather some dbus traces, maybe | 09:56 |
| freemangordon | re battery it seems there are some temporary voltage drops which lead to those shutdowns | 09:57 |
| freemangordon | maybe some spike filtering shall be done, dunno | 09:58 |
| freemangordon | now charging in android, to see what it will do | 09:58 |
| freemangordon | uvos__: also, do you know which module/code reads battery eeprom in android? | 09:59 |
| Wizzup | rafael2k: I didn't do it yet, sry, had other things on my mind | 10:49 |
| Wizzup | freemangordon: the kernel also has its own force shutdown on low battery afaik | 11:05 |
| Wizzup | which might be more sensitive to spikes | 11:05 |
| uvos__ | freemangordon: battd its a closed source motorola thing | 11:07 |
| uvos__ | freemangordon: the eeprom is extremly unlikely to be usefull | 11:07 |
| uvos__ | freemangordon: it dose not contain any callibration | 11:08 |
| uvos__ | freemangordon: as it is read only it can not | 11:08 |
| rafael2k | Wizzup: ? | 11:11 |
| uvos__ | freemangordon: indeed the kernel has its own force shutdown too and its not filered at all. the battery voltage is a bit sensetive to spikes in mce too but filtering that is really upowers resposability. | 11:12 |
| uvos__ | please also note that pulling the battery below 3.0 under load causes damage, its not the open circut volage thats relevant. | 11:13 |
| uvos__ | a problem here is that the d4 has a massive resistance between the battery and cpcaps voltage probe, for some reason | 11:13 |
| uvos__ | (an aditional) | 11:13 |
| * sicelo also just had that shutdown fmg is referring to | 11:23 | |
| freemangordon | uvos__: well, battery voltage is measured by cpcap, so a temp spike on *that* voltage should not lead to immediate shutdown | 11:24 |
| freemangordon | also, this shutdown seems to happen @ < 3.2V | 11:24 |
| freemangordon | that would guarantee that the battery itself is well above 3.0, no? | 11:24 |
| uvos__ | yes we dont shutdown early beacuse it would damage the battery | 11:24 |
| freemangordon | umm, sorry, can't parse | 11:25 |
| uvos__ | we shoutdown early beacuse the user cant easly recover from the state wehre the device is fully discarged | 11:25 |
| freemangordon | ah | 11:25 |
| uvos__ | becasue of bootloader trouble | 11:25 |
| freemangordon | that's fine | 11:25 |
| uvos__ | not really | 11:25 |
| uvos__ | but its the best we can do atm | 11:25 |
| freemangordon | the point is that IMO we shall not shutdown as soon as we see < 3.2 | 11:25 |
| uvos__ | yeah thats a kernel thing | 11:26 |
| uvos__ | upower dose filter the spikes | 11:26 |
| uvos__ | if its enough idk | 11:26 |
| freemangordon | mhm, we shall filter too | 11:26 |
| freemangordon | IIUC | 11:26 |
| freemangordon | in the kernel driver that is | 11:26 |
| uvos__ | sure | 11:26 |
| freemangordon | shall I implement some filtering there? | 11:27 |
| sicelo | yessss please :-) | 11:27 |
| uvos__ | yes sure | 11:27 |
| uvos__ | but atm this would change nothing in leste | 11:27 |
| sicelo | battery issues are the main reason i don't enjoy using my the d4 | 11:27 |
| uvos__ | but still yes | 11:27 |
| freemangordon | it will prevent random shutdowns | 11:28 |
| uvos__ | i dont think the kernel ever hits its shutdown | 11:28 |
| uvos__ | atm | 11:28 |
| uvos__ | its .3v away | 11:28 |
| uvos__ | it certenly dosen for me | 11:28 |
| freemangordon | it does, when you stop mce :D | 11:28 |
| uvos__ | (kernel shutdown = no white light) | 11:28 |
| uvos__ | ok | 11:28 |
| uvos__ | sure yeah then | 11:28 |
| uvos__ | ;) | 11:28 |
| freemangordon | also, to me 3.5V is too high | 11:29 |
| uvos__ | mce is 3,35 | 11:29 |
| freemangordon | why don;t we shutdown @ 3.25? | 11:29 |
| uvos__ | mce is 3.35 | 11:29 |
| uvos__ | freemangordon: we shoutdown early beacuse the user cant easly recover from the state wehre the device is fully discarged | 11:29 |
| freemangordon | well,, I guess spikes again | 11:29 |
| uvos__ | when are you mesureing 3,5v | 11:29 |
| uvos__ | if thats afterwards its useless you need to measure under load | 11:30 |
| freemangordon | even with charge mode? | 11:30 |
| uvos__ | yes | 11:30 |
| uvos__ | charge mode helps only a little | 11:30 |
| freemangordon | ok, 3.35 then | 11:30 |
| uvos__ | the problem is the device dieing before the kenrel finishes booting | 11:30 |
| uvos__ | (and the android kernel and kexecboot it all just takes to long) | 11:30 |
| freemangordon | but, we stall shall filter better | 11:30 |
| uvos__ | and no pm during that time either | 11:30 |
| uvos__ | sure | 11:30 |
| uvos__ | upower dose filter as i saied | 11:30 |
| freemangordon | even in mce, if needed | 11:30 |
| uvos__ | but maybe to fast | 11:30 |
| freemangordon | does not seem enough | 11:30 |
| freemangordon | yeah | 11:31 |
| sicelo | no idea how possible this is - but i really don't mind 3.5v or any other voltage *IF* the shutdown is not initiated immediately, but we test over a couple of seconds to be sure the voltage has really dropped (it's not just a spike) | 11:31 |
| uvos__ | mce cant really filter | 11:31 |
| uvos__ | iirc | 11:31 |
| uvos__ | becasue it gets voltage changed events | 11:31 |
| uvos__ | not some polling rate | 11:31 |
| freemangordon | but, if we filter in kernel, then upower will filter the already filtered value :) | 11:31 |
| uvos__ | no | 11:31 |
| uvos__ | dont filter the voltage_now value | 11:31 |
| uvos__ | that breaks spec | 11:31 |
| uvos__ | its defined as a snapshot | 11:32 |
| uvos__ | the kernel can filter for its shutdown thresh | 11:32 |
| uvos__ | not uapi | 11:32 |
| uvos__ | check if voltage_avg is a thing (current_avg) exists | 11:32 |
| uvos__ | in uapi | 11:32 |
| uvos__ | then filter that, as its defined to be the filtered value | 11:32 |
| uvos__ | anyhow ttyl | 11:33 |
| * freemangordon looks at how mce takes shutdown decisions | 11:35 | |
| Wizzup | rafael2k: the kernel build | 11:36 |
| freemangordon | uvos__: yes, it can filter, just not the voltage, but the state | 11:40 |
| freemangordon | like, it receives 'empty' message with voltage < threshold from upower and starts timer. if after the timer expires we didn;t receive anything from upower with voltage > threshold we initiate shutdown | 11:42 |
| freemangordon | if voltage comes that is > threshold, then we abort "shutdown sequence" | 11:43 |
| freemangordon | and yes, it was me to add battery-upower module https://github.com/maemo-leste/mce/commit/9f89035dd53ccb30d6984f9cc7ea433cf84ae599 :) | 11:45 |
| freemangordon | so here https://github.com/maemo-leste/mce/blob/master/src/modules/battery-upower.c#L196 | 11:47 |
| sicelo | +1 on the timer proposal | 11:47 |
| freemangordon | I will try to implement somwthing | 11:47 |
| freemangordon | some hysteresis algo | 11:48 |
| rafael2k | Wizzup: lemme know if there is something wrong | 11:53 |
| sicelo | Wizzup: wiki down again | 11:56 |
| freemangordon | uvos__: re battery eeprom - at least we'll be able to understand if this is high voltage battery or not and charge properly | 11:56 |
| freemangordon | iven if not @ 4.35, but 4.25 or 4.3 sounds sane to me | 11:57 |
| freemangordon | *even | 11:57 |
| rafael2k | uvos__: the "speaker" button in sphone does not change the audio output to the speakers in the PP | 11:57 |
| Wizzup | sicelo: hm looks like the vm freezes | 11:58 |
| Wizzup | sicelo: that's not great :) | 12:00 |
| freemangordon | DoS attack? | 12:01 |
| Wizzup | maybe | 12:02 |
| Wizzup | not likely I think | 12:02 |
| Wizzup | but we'll see | 12:02 |
| Wizzup | hm I think it froze again already | 12:03 |
| Wizzup | even the vnc session of qemu disappears | 12:04 |
| Wizzup | well, it hangs | 12:04 |
| Wizzup | well, I don't understand atm :) | 12:08 |
| Wizzup | I will have to debug this later today | 12:09 |
| Wizzup | I will keep it down for now | 12:11 |
| uvos__ | freemangordon: this is allready implemented @hv voltage or not | 12:13 |
| uvos__ | freemangordon: its just that we cant modprobe the one wire bus driver | 12:13 |
| uvos__ | freemangordon: becasue it blocks idle | 12:13 |
| uvos__ | freemangordon: also theres a small bug in the code that makes it work on only some phones, but thats small fry and i could fix it immidatly if the other issue is solved | 12:14 |
| uvos__ | rafael2k: probubly ucm issue | 12:15 |
| rafael2k | uvos__: indeed. Will try to debug this a bit | 12:17 |
| uvos__ | freemangordon: sure you could do that @ timeout, but thats sortof a hack vs just filtering the voltage itself so its not so noisy | 12:21 |
| uvos__ | i also have to note thtat i dont have the "noisy battery voltage" problem at all | 12:26 |
| uvos__ | mine shuts down very reliably at 3.3 ish volts | 12:26 |
| uvos__ | i gues that may be becasue my battery is new and the really old degraded batteries have greateer internal resistance | 12:27 |
| uvos__ | thus having great magnitude spikes when the load changes | 12:27 |
| uvos__ | in your filtering please also note that spikes upwards might also exitst | 12:29 |
| uvos__ | when for instance the phone enters ret for a tiny period of time while otherwise loaded | 12:29 |
| uvos__ | this may cause you to shutdown to late (again the closed circut voltage is important, not the open circut one) | 12:30 |
| uvos__ | your timer proposal would be subject to this problem | 12:30 |
| freemangordon | uvos__: sure the issue appears because of my old battery | 12:55 |
| freemangordon | then again - if you say filtering VOLTAGE_NOW will break the specs, I am not sure which voltage to filter | 12:57 |
| uvos__ | freemangordon: so cpcap gives the kernel a voltage low irq | 12:57 |
| freemangordon | ah | 12:58 |
| uvos__ | freemangordon: (btw we should throttle it, it comes way to often below a thresh) | 12:58 |
| freemangordon | @ what voltage? | 12:58 |
| uvos__ | hw defined | 12:58 |
| uvos__ | 3.3 or so i think | 12:58 |
| freemangordon | I see | 12:58 |
| uvos__ | but it comes repeatably below that thresh | 12:58 |
| uvos__ | and then the driver checks the voltage when the irq fires | 12:58 |
| freemangordon | so you think we shall filter in irq | 12:58 |
| uvos__ | i think it dose that 3 times and makes a avg | 12:59 |
| freemangordon | handler | 12:59 |
| uvos__ | allready | 12:59 |
| uvos__ | iirc | 12:59 |
| uvos__ | but it needs to be longer i gues | 12:59 |
| freemangordon | I see | 12:59 |
| freemangordon | well, counting to 3 is wrong I would say :) | 12:59 |
| freemangordon | if irq rises every ms | 12:59 |
| uvos__ | sure but i think the irq handler dose 3 mesurements by itself | 13:00 |
| freemangordon | ahaaa | 13:00 |
| uvos__ | iirc, but dont have the code infront of me rn | 13:00 |
| * freemangordon ckecks the code | 13:00 | |
| freemangordon | I see no filtering whatsoever, maybe I can;t find it | 13:03 |
| uvos__ | ok | 13:03 |
| uvos__ | maybe the 3 mesruements was for someting else (callibration maybe) | 13:03 |
| uvos__ | anyhow that needs filtering somehow (irq handler) | 13:03 |
| uvos__ | also throtteling, while at it | 13:03 |
| freemangordon | do we have some standard API to do that? or we shall invent it | 13:07 |
| freemangordon | or, you mean we shall not call power_supply_changed() more than once every few seconds? | 13:08 |
| freemangordon | from the irq handler that is | 13:09 |
| uvos__ | throtteling is achived by disabeling the irq for some seconds | 13:09 |
| uvos__ | by changing cpcaps irqmask | 13:09 |
| freemangordon | ok | 13:10 |
| freemangordon | do you know how often does it come now? | 13:11 |
| uvos__ | not exactly if you want a ms number | 13:11 |
| uvos__ | very often sometimes | 13:11 |
| uvos__ | btw the thing is qutie suspect to me anyhow | 13:12 |
| uvos__ | im not srue cpcap even guarentees the irq will fire ever again after thresh | 13:12 |
| uvos__ | it might just because noise | 13:12 |
| uvos__ | anyhow tmlind obviously thought it did | 13:12 |
| uvos__ | maybe he can enlighten us | 13:13 |
| freemangordon | yep, I'll pester him on that one | 13:13 |
| uvos__ | i get the fealing maybe we should just disable the irq after geting it once and poll after that, untill we shtudown or the charger is plugged | 13:13 |
| freemangordon | lemme see in the logs, yesterday I had mce stopped | 13:14 |
| freemangordon | so I should have several "low" messages in dmesg | 13:14 |
| uvos__ | dmsg absolutly spamms you will low becasue of the irq below a thresh | 13:15 |
| uvos__ | s/will/with | 13:15 |
| freemangordon | umm, then I don't understand "im not srue cpcap even guarentees the irq will fire ever again after thresh" | 13:15 |
| uvos__ | the code as is | 13:15 |
| uvos__ | assumes that cpcap will fire the low irq repeadbly after crossing the threshold | 13:16 |
| uvos__ | in reality i suspect its just a comperator | 13:16 |
| uvos__ | that will fire only when the voltage passes thresh | 13:16 |
| uvos__ | that means the kernel may never shutdown | 13:16 |
| freemangordon | it did yesterday | 13:16 |
| uvos__ | if the irq fires, the kernel thinks voltage is high enoguh and cpcap thinks its low and has done its duty | 13:17 |
| uvos__ | freemangordon: right so tmlinds assumption was wrong | 13:17 |
| uvos__ | and wee nedd to " i get the fealing maybe we should just disable the irq after geting it once and poll after that, untill we shtudown or the charger is plugged" | 13:17 |
| freemangordon | yep, I see irq storm in th elogs | 13:18 |
| freemangordon | about low battery | 13:19 |
| freemangordon | what is weird though is the voltage | 13:19 |
| freemangordon | I see battery low @ 3661 mV | 13:19 |
| uvos__ | oh ok | 13:19 |
| uvos__ | i never see it before 3.3 or so | 13:20 |
| uvos__ | i gues its old battery spikes again | 13:20 |
| uvos__ | seeing it very early is not that unusual if your battery is really bad i gues | 13:20 |
| freemangordon | ok, but @ 3.6V :) | 13:20 |
| uvos__ | the irq is unfiltered ofc and very fast | 13:20 |
| freemangordon | yeah | 13:20 |
| uvos__ | that means your droping below 3.3 | 13:20 |
| freemangordon | I guess this drains it even faster :) | 13:20 |
| uvos__ | even while mostly charged | 13:21 |
| freemangordon | right | 13:21 |
| uvos__ | thats bad | 13:21 |
| uvos__ | that means your droping > .3 volts | 13:21 |
| uvos__ | d4 hw has ram erros below 2.9 or so | 13:21 |
| uvos__ | so you might be even flipping bits with that | 13:21 |
| freemangordon | the storm continues for 5 seconds | 13:22 |
| freemangordon | and then it stops | 13:22 |
| freemangordon | seems irq is triggered every 20-30 ms though | 13:22 |
| freemangordon | hmm, no | 13:23 |
| freemangordon | it is not on interval | 13:23 |
| uvos__ | its probubly triggering on noise after that, is my suspicion | 13:23 |
| uvos__ | not a time | 13:23 |
| freemangordon | mhm | 13:24 |
| freemangordon | why do we need to start poling once we have 'low' irq? | 13:25 |
| uvos__ | becasue how would you know when to shutdown? | 13:25 |
| uvos__ | you can rely on noise triggering the irq again | 13:25 |
| freemangordon | we have 2 irqs | 13:25 |
| freemangordon | one for low and one for empty | 13:26 |
| uvos__ | i dont think we use the empty one directly | 13:26 |
| uvos__ | iirc | 13:26 |
| freemangordon | sure we do | 13:26 |
| uvos__ | without mesrueing the voltage? | 13:26 |
| freemangordon | wit measuring | 13:26 |
| uvos__ | right | 13:26 |
| freemangordon | *with | 13:26 |
| uvos__ | the problem is | 13:26 |
| uvos__ | empty irq fires | 13:26 |
| freemangordon | well, it uses the last measurement | 13:27 |
| uvos__ | we messure voltage | 13:27 |
| uvos__ | we think its ok to not shutdown | 13:27 |
| uvos__ | now what? | 13:27 |
| uvos__ | the irq may never come agian | 13:27 |
| freemangordon | obviously it comes | 13:27 |
| uvos__ | because of noise | 13:27 |
| freemangordon | does not matter | 13:27 |
| uvos__ | idk if you cna rely on that | 13:27 |
| freemangordon | hmm, I see | 13:27 |
| uvos__ | even if it mostly works | 13:28 |
| uvos__ | the voltage may be very clean for some reason | 13:28 |
| freemangordon | what we can do: | 13:28 |
| uvos__ | phone is is continuous off mode or whatever | 13:28 |
| freemangordon | once we have "empty" irq, start polling every 10 seconds or so | 13:29 |
| uvos__ | right | 13:29 |
| uvos__ | thats what i said :) | 13:29 |
| freemangordon | if we see voltage < 3.2, shutdown | 13:29 |
| uvos__ | "i get the fealing maybe we should just disable the irq after geting it once and poll after that, untill we shtudown or the charger is plugged" | 13:29 |
| freemangordon | you were talking abot "low" not "empty" :) | 13:29 |
| uvos__ | well both | 13:29 |
| freemangordon | no | 13:29 |
| uvos__ | both have the sam eproblem | 13:29 |
| freemangordon | we should disregard empty | 13:29 |
| freemangordon | once it comes | 13:30 |
| freemangordon | we shall not start poll on "low" only on "empty" | 13:30 |
| uvos__ | if you want the low indicated to uapi to be realiable | 13:30 |
| uvos__ | you have to do the same thing to it too | 13:30 |
| uvos__ | its not as important i gues | 13:30 |
| uvos__ | but otherwise it holds | 13:30 |
| freemangordon | obviously it went below the threshold, no? | 13:30 |
| uvos__ | sure | 13:30 |
| freemangordon | so it is low | 13:30 |
| uvos__ | but yours is obviously totaly bonkers | 13:30 |
| freemangordon | sure | 13:31 |
| freemangordon | the point is that it does not really matter how much "low" it is, from the shutdown perspective | 13:31 |
| uvos__ | sure | 13:31 |
| freemangordon | so, once we detect low, we disable the irq and enable it back only on charger connected | 13:31 |
| uvos__ | or reboot yes | 13:32 |
| freemangordon | well, power-up will enable it for us, obviously :) | 13:32 |
| freemangordon | hmm, wait | 13:32 |
| uvos__ | well avoid writeing the state to nvmem xD | 13:32 |
| freemangordon | you are right we shall start some polling for couple of seconds | 13:33 |
| freemangordon | or not? | 13:33 |
| * freemangordon checks how mce decodes to shutdown | 13:33 | |
| freemangordon | *decides | 13:33 |
| uvos__ | mce just gets the voltage from upower | 13:33 |
| uvos__ | and descides to shutdown on thresh | 13:33 |
| uvos__ | not by default at all btw | 13:34 |
| uvos__ | its a device specific config activated on mapphones | 13:34 |
| freemangordon | it receives UP_DEVICE_STATE_EMPTY | 13:34 |
| uvos__ | it dosent use that | 13:34 |
| uvos__ | it uses the voltage | 13:34 |
| uvos__ | and decides itself | 13:34 |
| freemangordon | both | 13:34 |
| uvos__ | right both but the voltage is allways sooner | 13:34 |
| freemangordon | if (upowbat.state == UP_DEVICE_STATE_EMPTY || upowbat.voltage < private.min_voltage && !mcebat.charger_connected) | 13:35 |
| freemangordon | right | 13:35 |
| freemangordon | ok, so upower does not filter enough | 13:35 |
| * freemangordon is afk for few minutes | 13:36 | |
| freemangordon | uvos__: ok, what I think I will implement for now, is to disable 'low' interrupt for 30 seconds and then re-anable | 13:44 |
| freemangordon | *re-enable | 13:44 |
| uvos__ | freemangordon: ok well thats not really a final solution, but may at least defer the problem so that its not too annoying for people with batteries that are close to death | 14:22 |
| freemangordon | sure, this is just the first step | 14:22 |
| freemangordon | at least to fix the irq storm | 14:23 |
| freemangordon | uvos__: https://pastebin.com/T3A9yyd5 | 14:27 |
| uvos__ | looks good | 14:28 |
| buZz | hehe yeah, that 'low battery' poweroff is kinda annoying, i even had it happen on ~80% charge | 14:47 |
| freemangordon | thats upower misbehaving, but that's another story | 14:52 |
| freemangordon | uvos__: oh, BTW, I checked GFX domain and it enters OFF when screen is on | 14:53 |
| uvos__ | freemangordon: i mean yeah it should, but it dident in the past at some point post ddk 1.9 | 14:56 |
| uvos__ | so good | 14:56 |
| freemangordon | for sure it does now | 14:56 |
| uvos__ | also iirc on android dss enters off too | 14:56 |
| uvos__ | and dosent on leste | 14:56 |
| uvos__ | (screen on) | 14:56 |
| freemangordon | did you check? | 14:56 |
| uvos__ | sure yeah when i was debugging power things | 14:56 |
| uvos__ | 1 year ago | 14:57 |
| uvos__ | so its more of a check this again, not a its broken | 14:57 |
| freemangordon | yeah, it stays ON | 14:58 |
| uvos__ | ok i gues the android kernel has special handlig for the command mode dsiplay | 14:58 |
| uvos__ | on a regular display dss cant be off ofc | 14:58 |
| freemangordon | hmm, wait | 14:58 |
| freemangordon | I am playing video :) | 14:58 |
| uvos__ | lol | 14:58 |
| freemangordon | lemme stop it | 14:58 |
| uvos__ | ok | 14:58 |
| uvos__ | another problem is | 14:59 |
| uvos__ | that we have just one gfx clock | 14:59 |
| uvos__ | while android scalles it | 14:59 |
| uvos__ | we just have off and full blast | 14:59 |
| freemangordon | yeah | 14:59 |
| uvos__ | android ussually never even needs full sgx clock in the ui | 14:59 |
| freemangordon | uvos__: hmm actually OFF counter increases when the display is on | 15:01 |
| freemangordon | so I guess this is some artificial VSYNC that's going on | 15:01 |
| freemangordon | not that it is good, I will have a look at it | 15:01 |
| uvos__ | ok | 15:04 |
| uvos__ | well that means the code path at least is sorta there | 15:04 |
| uvos__ | to suspend dss with cm mode pannel | 15:04 |
| freemangordon | ok, I see no ioctls with display enabled | 15:06 |
| freemangordon | DRM ioctls that is | 15:06 |
| freemangordon | well, there are few, every 10 seconds or so | 15:06 |
| freemangordon | but nothing to keep it ON | 15:06 |
| freemangordon | maybe gsm signal strenght gets updated | 15:07 |
| uvos__ | maybe check if its sill a poblem in a vt | 15:08 |
| uvos__ | (disable the cursor ofc ;)) | 15:08 |
| freemangordon | will do | 15:08 |
| freemangordon | but not now | 15:08 |
| uvos__ | ok | 15:08 |
| freemangordon | lets first see the battery low patch | 15:08 |
| buZz | :) oh that display thing is weird too | 15:30 |
| buZz | sometimes it seems X thinks the screen is turned off, and you need to press a button for it to 'turn on' before the button arrives at (say) xterm , but the screen would already be on | 15:31 |
| buZz | feels kinda like DPMS is enabled but not supported, or something | 15:31 |
| buZz | wow did something in charging change? i see d4 charging a lot faster now | 15:33 |
| buZz | hmmz, wiki seems offline, or at least superslow | 15:35 |
| rafael2k | btw, I have a very strange behavior with the screen backlight when I connect a USB mouse, the screen starts to dim, until it turns off. | 15:37 |
| rafael2k | also, most likely a WiFi regression, maemo does not connect to an available network, but always try to connect to the latest network, even if it is not available | 15:37 |
| rafael2k | I dunno if it was always like this, but it does not seems right | 15:38 |
| buZz | rafael2k: hm? thats kinda normal? i mean 'dimming and then off' is the normal maemo 'idle screen off' | 15:38 |
| buZz | ohhh, you mean, its still turning off even though you are giving external inputs? | 15:39 |
| buZz | that connection stuff is about auto-connecting to wifi? | 15:39 |
| rafael2k | buZz: no no, as soon as I connect a USB mouse, it starts to dim off | 15:39 |
| buZz | huh | 15:39 |
| buZz | thats bizar, lemme try :D | 15:39 |
| rafael2k | indeed, very bizar | 15:39 |
| buZz | *digs around for a usb mouse* | 15:40 |
| rafael2k | buZz: auto-connecting to wifi - yes - it has a problem | 15:40 |
| rafael2k | it does not try to connect to an available network, but to the last one | 15:40 |
| buZz | initially? or all the time? does it never get on the available one? | 15:42 |
| rafael2k | I need to manually choose the available one | 15:42 |
| buZz | eh, i just connected a usb mouse, and screen doesnt dim | 15:43 |
| buZz | rafael2k: you're using a d4 aswell? | 15:43 |
| rafael2k | strange, here the issue starts imediatelly | 15:43 |
| rafael2k | nope, just the PP | 15:43 |
| buZz | oh ok, i dont have a usb-c mouse or adapter | 15:43 |
| rafael2k | USB is indeed working fine, apart of this issue... I dunno if when we have usbnet back things will keep working | 15:44 |
| buZz | aha! screen did dim -eventually- like from normal timeout on maemo | 15:44 |
| buZz | BUT , moving usb mouse does not undim! | 15:44 |
| rafael2k | indeed! | 15:44 |
| buZz | tapping screen -does- undim directly | 15:44 |
| buZz | weird issue :P but feels related to my eh 'screen is on but needs a keypress before working' | 15:45 |
| rafael2k | but the strange thing for me is that just plugin the USB mouse triggers the dimming | 15:45 |
| buZz | hmhm, i'm not using PP a lot | 15:45 |
| buZz | was great to see the GPU finally getting somewhat fast though :) | 15:46 |
| rafael2k | also, the mouse wheel makes lots of system clicks sounds... unless I set the system to be silent | 15:46 |
| rafael2k | : ) | 15:46 |
| rafael2k | not a big issue thou | 15:46 |
| buZz | hmhm? well 'mousewheel' usually is >1 button, isnt it? | 15:46 |
| buZz | its 'down X lines' or something | 15:46 |
| buZz | i'll try to make a issue from this topic | 15:47 |
| rafael2k | I dunno, but mouse wheel movements makes the same system sound as a left or right click | 15:47 |
| rafael2k | at least with the USB mouse | 15:47 |
| rafael2k | mouse wheel are mouse buttons afaik | 15:48 |
| buZz | i -think- there's no issue describing the dimming/locking already on https://github.com/maemo-leste/bugtracker/issues | 15:50 |
| rafael2k | right, may be I'll open an issue there with the kernel log | 15:50 |
| buZz | > 15:47:15 < buZz> i'll try to make a issue from this topic | 15:50 |
| buZz | but if you want to , thats fine too :P | 15:51 |
| buZz | i -think- that 'dim on usb connect' is a PP specific issue | 15:52 |
| rafael2k | I think so | 15:55 |
| rafael2k | will do some more debug before opening it | 15:55 |
| rafael2k | I opened one for sphone "Speaker" button: https://github.com/maemo-leste/bugtracker/issues/637 | 15:56 |
| buZz | yeah that regressed, it was working briefly before | 15:59 |
| buZz | oh, it does work on d4 running -devel | 16:00 |
| buZz | rafael2k: are you on -devel? | 16:03 |
| freemangordon | rafael2k: what does it mean "does not connect to the available network?" it connects only to networks that are in the connections list | 16:03 |
| freemangordon | like, you should have connected at least once | 16:04 |
| freemangordon | *manually* | 16:04 |
| rafael2k | buZz: yes, on -devel | 16:08 |
| rafael2k | freemangordon: it was connected to a known network, then this network goes out of range, the phone does not connect to a known available network automatically | 16:09 |
| freemangordon | hmm, weird | 16:11 |
| freemangordon | is it set to do it? | 16:11 |
| freemangordon | in settings | 16:11 |
| buZz | 'autoconnect' isnt tested a lot yet, btw | 16:13 |
| buZz | i guess i should enable it now that gprs is working so well <3 <3 | 16:13 |
| freemangordon | it is not tested, but at least on my d4 it works fine | 16:14 |
| buZz | rafael2k uses a PP | 16:14 |
| buZz | rafael2k: you autoconnect to 'any' or just wifi? | 16:14 |
| buZz | rafael2k: do they, by chance, share the same SSID? | 16:21 |
| freemangordon | uvos__: I see absolutely no filtering done in upower https://github.com/maemo-leste-upstream-forks/upower/blob/master/src/linux/up-device-supply.c#L684 | 16:23 |
| freemangordon | if you see one, please LMK | 16:24 |
| buZz | if (voltage < 0.01) | 16:24 |
| buZz | lol, thats a low voltage :D | 16:24 |
| freemangordon | well, it plays games with float | 16:24 |
| buZz | right, but why even use voltage_now , that drops a ton even if you just turn on the screen | 16:24 |
| buZz | voltage_avg is the filtered one | 16:25 |
| freemangordon | not everyone supports it it seems | 16:25 |
| freemangordon | d4 for example :) | 16:25 |
| buZz | it does? | 16:25 |
| freemangordon | where? | 16:26 |
| buZz | wait, i think it does | 16:26 |
| freemangordon | nope | 16:26 |
| freemangordon | see /sys/class/power_supply/battery | 16:26 |
| buZz | oh, indeed | 16:26 |
| freemangordon | buZz: BTW I know rafael2k uses PP, it is just that icd2 does not care if it is PP or d4 | 16:27 |
| buZz | maybe we could add a voltage_avg output to cpcap-charger.c ? | 16:27 |
| buZz | or cpcap-battery.c | 16:27 |
| buZz | just eh. average of last X samples | 16:27 |
| freemangordon | that wouldn;t help upower | 16:27 |
| buZz | yeah , not as-is, unless we flip _now and _avg on the lines you linked | 16:27 |
| freemangordon | oh, this is again spinal | 16:28 |
| buZz | (afaics) | 16:28 |
| freemangordon | "Subject: [PATCH] Add voltage estimated percentage fallback" | 16:29 |
| freemangordon | "This is common code for status-area-applet-battery and mce" | 16:29 |
| freemangordon | so, I think we shall fix that by trying _avg first and if there is no, average _now | 16:31 |
| freemangordon | or, provide both voltage_avg and voltage_now and leave users decide what they prefer | 16:33 |
| buZz | does upower even support providing both? | 16:33 |
| freemangordon | upower supports neither | 16:33 |
| freemangordon | this is code added by spinal.by at gmail.com | 16:34 |
| freemangordon | the same guy that made a rage quit | 16:34 |
| freemangordon | because I 'stole' *his* clutter code | 16:35 |
| freemangordon | anyway | 16:35 |
| buZz | rofl | 16:38 |
| uvos__ | so the scrollwheel making sounds is as designed | 16:43 |
| uvos__ | thats the mousebutton click in mis | 16:43 |
| uvos__ | the mouse not undiming the screen is probubly mce misscharacterizing the mouse as a keyboard | 16:44 |
| uvos__ | could you post the evtes output of that mouse | 16:44 |
| uvos__ | idk whats going on with the display dimming when you insert a mouse but just on pp | 16:44 |
| uvos__ | mabybe this is a hw interaction between vbus and the light sensor or sometheing | 16:45 |
| uvos__ | no idea | 16:45 |
| freemangordon | could be the same issue I see on d4 | 16:45 |
| uvos__ | maybe run mce with --verbose --verbose and give me the output | 16:45 |
| uvos__ | freemangordon: at least buZz repoted it dident happen to him | 16:45 |
| freemangordon | I am seeing it when I connect a charger | 16:46 |
| freemangordon | hmm, lemme try to repro and see the logs | 16:46 |
| buZz | freemangordon: your screen dims when you connect a charger? | 16:47 |
| buZz | not here, indeed | 16:48 |
| freemangordon | when I disconnect it | 16:48 |
| buZz | not here either | 16:48 |
| buZz | do you have 'screen on when charging' set? | 16:48 |
| freemangordon | yes | 16:48 |
| buZz | i dont | 16:48 |
| uvos__ | pretty wierd behavior | 16:48 |
| uvos__ | all around | 16:48 |
| freemangordon | does not happen all the time though | 16:48 |
| buZz | uvos__: you want me to post something about a usb mouse? | 16:49 |
| uvos__ | yeah | 16:49 |
| uvos__ | evtest | 16:49 |
| uvos__ | the list of events it supports | 16:49 |
| buZz | alright | 16:49 |
| buZz | hmmm , i dont have evtest, what package is that in? | 16:50 |
| uvos__ | i think evtest | 16:51 |
| buZz | indeed :) | 16:51 |
| * buZz waits for dpkg lock to release after connecting wifi -_- | 16:53 | |
| buZz | how do i disable that behaviour? :D | 16:53 |
| buZz | funny, a mouseclick does undim screen , movement just doesnt | 16:55 |
| freemangordon | uvos__: hmm, you said 'screen on when charging' does nto work, but it seems it works now | 16:55 |
| freemangordon | it does not work correctly (like, it does not turn the display on when charger is connected), but at least display stays lit when connected | 16:56 |
| uvos__ | unless i forgot that i partally implmented this again (very unlikely), its not mce | 16:58 |
| buZz | uvos__: https://paste.debian.net/1254362 | 16:58 |
| uvos__ | but anything could hold a lock | 16:58 |
| buZz | does that help? should i put that in the issue rafael2k made? | 16:58 |
| uvos__ | buZz: it probubly helps but i cant check now | 16:59 |
| buZz | oh, there isnt one yet | 16:59 |
| buZz | ok | 16:59 |
| uvos__ | most likley mce thinks a mouse/ts needs an absolute axis or soemthing | 16:59 |
| buZz | uvos__: where do you want this paste stored then? a new issue? | 16:59 |
| uvos__ | (this is why we should have libinput filter the event types but yeah) | 16:59 |
| uvos__ | buZz: sure new issue is good | 16:59 |
| buZz | alright | 16:59 |
| buZz | https://github.com/maemo-leste/bugtracker/issues/638 <- there you go | 17:02 |
| buZz | (pretty weird to see so many buttons reported, it doesnt have so many) | 17:02 |
| Wizzup | hm, my d4 thinks there is no sim now | 17:10 |
| Wizzup | (ofono) | 17:10 |
| freemangordon | what happened? like, out of the blue? | 17:11 |
| buZz | Wizzup: i get that sometimes aswell, mostly after shaking phone hard :P | 17:14 |
| Wizzup | well we were in the car | 17:15 |
| Wizzup | buZz: ah maybe that's it | 17:15 |
| freemangordon | uvos__: it is getting better :) | 17:15 |
| buZz | when i put some cardboard behind sim, its usually better | 17:15 |
| freemangordon | if I run mce --verbose --verbose --verbose and connect usb cable display gets unlocked | 17:15 |
| buZz | nearly -always- after dropping phone on something i see 'sim registration failed' or something | 17:15 |
| Wizzup | hmm, I don't usually drop my phone | 17:16 |
| buZz | on a couch? | 17:16 |
| freemangordon | if I just run /etc/init.d/mce start, nothing happens if I connect the cable | 17:16 |
| buZz | or if its in my backpack and i plonk it on the ground | 17:16 |
| norayr | folks do we have "/com/nokia/osso_browser" now? | 17:16 |
| freemangordon | no | 17:16 |
| norayr | what is used instead? | 17:16 |
| freemangordon | xdg browse | 17:16 |
| freemangordon | *browser | 17:16 |
| freemangordon | not that it is implementd | 17:17 |
| buZz | i just run chromium :P qtwebbrowser is such a hell | 17:17 |
| freemangordon | right | 17:17 |
| norayr | when we press that button in mstardict | 17:17 |
| norayr | osso_rpc_run() gets called | 17:17 |
| freemangordon | does it try to open url? | 17:18 |
| norayr | its first argument is "com.nokia.osso_browser" | 17:18 |
| norayr | yes | 17:18 |
| norayr | with exact request | 17:18 |
| norayr | "http://xdxf.revdanica.com/down2/index.php?down_format=StarDict" | 17:19 |
| norayr | which doesn't exist now. | 17:19 |
| Wizzup | nothing listens for it | 17:19 |
| norayr | it's in src/mstardict.cpp | 17:20 |
| norayr | you are free to replace the code. | 17:20 |
| norayr | to call the default browser | 17:20 |
| norayr | or i can do that but i don't know how to call the default browesr. | 17:20 |
| norayr | and i'll use some sourceforge url probably. | 17:20 |
| norayr | but the dictionaries as i understand must be manually downloaded and put to ~/MyDocs/mstardict | 17:21 |
| freemangordon | oh, great, I have mce logs from when it was buggy, now I only need to find them | 17:21 |
| buZz | ioh, right, i wanted to setup a new mirror for those dicts that isnt poopslow | 17:26 |
| freemangordon | uvos__: look at this https://pastebin.com/8k558SEX | 17:27 |
| freemangordon | maybe related to https://github.com/maemo-leste/mce/blob/master/src/modules/battery-upower.c#L256 | 17:33 |
| freemangordon | hmm, no, that sets it to be active | 17:35 |
| Wizzup | aah ok, the vm needs more space | 17:37 |
| Wizzup | I think this is the problem | 17:37 |
| buZz | Wizzup: and maybe wipe some logs / setup logrotate? | 17:42 |
| Wizzup | the problem is the qemu raw image grew too 300GB | 17:42 |
| Wizzup | I'm fixing it now, the problem is not logrotate | 17:43 |
| buZz | holy | 17:43 |
| Wizzup | we run jenkins on it | 17:43 |
| Wizzup | and for years we kept all the archives | 17:43 |
| Wizzup | it's not a surprise | 17:43 |
| buZz | :) | 17:43 |
| Wizzup | and there is no way to 'return' the bits of raw images | 17:43 |
| buZz | we can move archives to archive.org ? | 17:43 |
| Wizzup | I'd have to resort to filling in parts that the fs doesn't use to 0's etc | 17:43 |
| Wizzup | oh | 17:44 |
| Wizzup | I meant artifacts | 17:44 |
| Wizzup | not archives | 17:44 |
| buZz | we can move whatever we dont need from years ago to archive.org ? | 17:44 |
| buZz | :D | 17:44 |
| buZz | :D:D | 17:44 |
| freemangordon | Wizzup: you should be able to reclaim the free space back to host OS | 17:45 |
| Wizzup | freemangordon: yes, but it's not triival | 17:46 |
| freemangordon | well, at least vbox and vmware support that | 17:46 |
| freemangordon | I know | 17:46 |
| dreamer | lala, finally charge was full enough to boot this poor droid. now how do I update the apt keys again? :P | 17:46 |
| Wizzup | freemangordon: https://unix.stackexchange.com/questions/448603/shrink-unused-space-in-raw-image | 17:46 |
| Wizzup | dreamer: just apt-get upgrade twice | 17:46 |
| Wizzup | we worked around devuans problem | 17:47 |
| dreamer | but the update fails | 17:47 |
| dreamer | certificate chain is expired | 17:47 |
| Wizzup | dreamer: yes, for devuan | 17:47 |
| Wizzup | not for us | 17:47 |
| Wizzup | so just pull in the partial upgrade | 17:48 |
| Wizzup | and we will ship the new devuan key | 17:48 |
| dreamer | upgrade says there are 0 packages | 17:48 |
| dreamer | maybe my sources list is too old? | 17:48 |
| Wizzup | our own last key expiry problem is a long time ago I think | 17:48 |
| freemangordon | Wizzup: is this key in -stable? | 17:49 |
| freemangordon | devuan one | 17:49 |
| Wizzup | yes | 17:50 |
| freemangordon | ok | 17:50 |
| Wizzup | I think.. | 17:50 |
| buZz | dreamer: its ok, it will fail on devuan , not maemoleste | 17:50 |
| buZz | dreamer: and updating maemoleste should get you the newer devuan keys | 17:50 |
| dreamer | buZz: no, it fails on everything | 17:50 |
| buZz | it shouldnt? | 17:51 |
| Wizzup | freemangordon: I just imported it with reprepro | 17:51 |
| buZz | afaik maemo keys didnt change at all | 17:51 |
| Wizzup | dreamer: what's your droid 4 time set to? | 17:51 |
| dreamer | there are 0 updates to install according to apt | 17:51 |
| buZz | eh? | 17:51 |
| dreamer | oh wow, november 2021? o.O | 17:51 |
| buZz | lol | 17:51 |
| buZz | that would prevent ssl from working :P | 17:51 |
| dreamer | I have for certain booted this only a few months ago | 17:52 |
| dreamer | like ~3 | 17:52 |
| buZz | but did you ntpsync ? :D | 17:52 |
| dreamer | (was a busy summer) | 17:52 |
| dreamer | not yet :) | 17:52 |
| buZz | hehe | 17:52 |
| dreamer | any suggested servers? | 17:53 |
| buZz | ntp.bit.nl | 17:54 |
| buZz | we run one at nurdspace too :P but its 'flok accurate' ;) | 17:55 |
| dreamer | er, `CLOCK: adj_systime: Invalid argument` | 17:57 |
| dreamer | or, how the hell do I type a `:`? | 17:58 |
| dreamer | it gives me `>` instead .. | 17:58 |
| dreamer | ok ssh | 17:59 |
| buZz | dreamer: press 'ok' then '.' | 18:00 |
| buZz | like on n900 | 18:00 |
| dreamer | so did a manual set of the date | 18:01 |
| buZz | alright, and time? :) | 18:01 |
| dreamer | now I just get python errors when I use ntpdate directly .. | 18:01 |
| dreamer | yes | 18:01 |
| dreamer | date+time | 18:01 |
| buZz | python errors? i didnt know ntpdate was python | 18:01 |
| buZz | its not .. | 18:01 |
| dreamer | I dunno: `TypeError: 'gaierror' object is not subscriptable` | 18:02 |
| dreamer | frome `/usr/bin/ntpdig` | 18:03 |
| buZz | gai = getaddrinfo | 18:03 |
| dreamer | anyway, apt gets a tiny step closer | 18:03 |
| buZz | maybe dns isnt working? | 18:03 |
| dreamer | 152 packages can be upgraded. Run 'apt list --upgradable' to see them. | 18:03 |
| buZz | or you changed hostname on d4? | 18:03 |
| dreamer | I did not | 18:03 |
| buZz | ¯\_(ツ)_/¯ | 18:03 |
| dreamer | The following packages have unmet dependencies: libegl1-sgx-omap4 : Conflicts: libegl1 (>= 1.3.0-1) | 18:03 |
| freemangordon | dreamer: do apt-get dist-upgrdae | 18:03 |
| freemangordon | *dist-upgrade | 18:04 |
| buZz | yeah you're updating almost a full year of updates :P | 18:04 |
| dreamer | freemangordon: thnx <3 | 18:04 |
| dreamer | full year? that can't be. I ran this not too long ago and did updates then .. | 18:04 |
| dreamer | heuhm | 18:04 |
| buZz | nov 2021? :D | 18:04 |
| dreamer | no that date isn't correct | 18:04 |
| dreamer | that's not the last time I booted it | 18:04 |
| buZz | indeed ;) | 18:04 |
| dreamer | as said, this was a couple months ago | 18:05 |
| dreamer | anyway, churning away :) | 18:05 |
| buZz | \o | 18:05 |
| * dreamer go make diner and see where this ends up later | 18:05 | |
| freemangordon | uvos__: I think the issue is there https://github.com/maemo-leste/mce/blob/master/src/modules/inactivity.c#L300 | 18:31 |
| freemangordon | we see MCE_DISPLAY_ON in /build/mce-1.9.17+2m7/src/modules/display.c display_on_req_dbus_cb 446, which in turn calls display_state_filter | 18:32 |
| freemangordon | however, noone sets inactivity to FALSE | 18:33 |
| freemangordon | also, why is dbus call allowed to turn display on unconditionally? | 18:35 |
| freemangordon | hmm, it is the same on fremantle | 18:49 |
| freemangordon | besides that it does not reset inactivity to false on OFF | 18:49 |
| freemangordon | ok, I was able to repro: if you send display on request while it dims | 18:53 |
| freemangordon | dbus-send --system --type=method_call --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_display_state_on | 18:53 |
| uvos | freemangordon: ok ill fix it | 19:04 |
| uvos | can you make a bug? | 19:04 |
| uvos | what is sending req_display_state_on btw | 19:04 |
| uvos | seams wierd that something would force mce to turn the display on on usb unplugging | 19:05 |
| freemangordon | trying to find who sends that | 19:06 |
| uvos | that behavior should probubly be added to mce while reimplmenting the keep display on while charging thing | 19:06 |
| uvos | and removed where its now | 19:06 |
| freemangordon | there is no such code in stock mce | 19:06 |
| freemangordon | I guess it is you that added it at some stage | 19:06 |
| uvos | no what code? | 19:06 |
| freemangordon | but, that's not the point | 19:06 |
| freemangordon | display_state_filter | 19:07 |
| freemangordon | in inactivity | 19:07 |
| uvos | right yes i split the display module into several | 19:07 |
| freemangordon | still, that's not important | 19:07 |
| uvos | no and i wasent asking that | 19:07 |
| freemangordon | I think there are no other issues, besides that there is some problem while it dims | 19:08 |
| freemangordon | also, "stay lit while charging' works when started from ssh session | 19:08 |
| freemangordon | but not when started as a service | 19:08 |
| freemangordon | at least this is waht I saw | 19:08 |
| freemangordon | but I'll investigate later | 19:08 |
| freemangordon | after I find who TF sends req_display_blanking_pause on unlock | 19:09 |
| uvos | tklock prob | 19:09 |
| uvos | i dont see it | 19:09 |
| uvos | (and i dont run tklock) | 19:09 |
| freemangordon | why tklock shall send that to mce? | 19:09 |
| uvos | no idea | 19:09 |
| freemangordon | no way, afaik | 19:10 |
| * freemangordon checks | 19:10 | |
| uvos | im just checking whats different | 19:10 |
| freemangordon | do you know how to find pid from service id? | 19:10 |
| uvos | no | 19:10 |
| sicelo | buZz: re _avg, i think the kernel api says sysfs shall only contain what is reported by device/hardware ... not extrapolated data. so if cpcap has no concept of _avg, then it shouldn't exist in sysfs. at least that's how i understand it | 19:10 |
| uvos | that is correct | 19:10 |
| uvos | altho the cpcap modules allready violate that | 19:11 |
| uvos | in other places | 19:11 |
| freemangordon | method call time=1663607001.687722 sender=:1.32 -> destination=com.nokia.mce serial=173 path=/com/nokia/mce/request; interface=com.nokia.mce.request; member=req_display_blanking_pause | 19:11 |
| freemangordon | who is :1.32?!? | 19:11 |
| sicelo | buZz: 14:53 * buZz waits for dpkg lock to release after connecting wifi -_- ... you *might* be able to disable it by telling ham to auto-check for new packages less regularly. https://wiki.maemo.org/Customizing_Maemo#Disabling_Auto_Updates_Check | 19:14 |
| freemangordon | ugh | 19:15 |
| freemangordon | this is hildon-desktop | 19:15 |
| freemangordon | WTF? | 19:15 |
| uvos | freemangordon: line/file | 19:15 |
| uvos | ? | 19:15 |
| freemangordon | sec | 19:16 |
| sicelo | what are you chasing? display coming on? | 19:16 |
| freemangordon | BTW, FYI: | 19:16 |
| freemangordon | dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID 'string::1.32' | 19:16 |
| freemangordon | this is how we get PID from connection ID | 19:16 |
| freemangordon | hd_dbus_disable_display_blanking | 19:18 |
| freemangordon | sicelo: not only that | 19:19 |
| freemangordon | uvos: hd_comp_mgr_check_do_not_disturb_flag() | 19:19 |
| buZz | sicelo: i think even the wattage is already extrapolated | 19:20 |
| freemangordon | someone sets HD_ATOM_HILDON_DO_NOT_DISTURB | 19:20 |
| buZz | tnx for maemo wiki link , this'll improve my live | 19:20 |
| buZz | wait, there's no disable? O_o | 19:21 |
| buZz | yeah ok 5 years should be fine, but -never- would be much nicer | 19:21 |
| freemangordon | ok, have to cook dinner, ttyl | 19:22 |
| uvos | freemangordon: hildon_gtk_window_set_do_not_disturb(GTK_WINDOW(vtklock->window), TRUE); | 19:22 |
| uvos | its tklock | 19:22 |
| freemangordon | why the hell it does this? | 19:23 |
| uvos | i have no idea | 19:23 |
| freemangordon | lemme check | 19:23 |
| uvos | but this is also what breaks <30sec timeouts | 19:23 |
| freemangordon | < 60 I would say | 19:23 |
| uvos | becasue req_display_blanking_pause is for at least 60 sec | 19:23 |
| uvos | right | 19:24 |
| uvos | 60 | 19:24 |
| freemangordon | ok, but why it works on fremantle | 19:24 |
| uvos | it dosent | 19:24 |
| uvos | its broken on freemantle too | 19:24 |
| uvos | try 10s timeout | 19:24 |
| freemangordon | anyway, we find 2 issues | 19:24 |
| freemangordon | yes | 19:24 |
| uvos | and unlock via vtklock | 19:24 |
| freemangordon | it could be my REing | 19:24 |
| freemangordon | have to check what stock code is doing | 19:24 |
| uvos | rught ill fix mce issue later | 19:25 |
| uvos | and buZz's mouse issue to | 19:25 |
| freemangordon | great, thanks | 19:25 |
| uvos | that one looks easy | 19:25 |
| buZz | <3 not my issue uvos , just confirmed and described it ;) | 19:25 |
| freemangordon | uvos: maybe there is issue in mce | 19:29 |
| freemangordon | I will check in fremantle mce how it decides to stop blank prevention | 19:30 |
| dreamer | generating locales took a while so I went to do other things. now after the dist-upgrade I rebooted. now the wifi connection doesn't seem to work any more. cannot bring up the internet connection widget | 20:33 |
| dreamer | s/widget/selector-thingy | 20:34 |
| dreamer | any changes in this in the last months? | 20:34 |
| dreamer | actually, the keyboard also doesn't respond | 20:35 |
| dreamer | terminal closes after starting .. | 20:35 |
| dreamer | so. I guess I'll just have to reflash the damn thing .. | 20:35 |
| Wizzup | dreamer: sounds like a bad upgrade experience for sure | 20:49 |
| dreamer | Wizzup: my role as "dumb user that upgrades once every couple months" pays off again ;) | 20:53 |
| dreamer | (in generally a pretty good metric for how stable an OS is for the general public, imo) | 20:54 |
| * sicelo has burned image only once. everything else is just apt-get (dist-)upgrade | 20:55 | |
| freemangordon | uvos: https://github.com/community-ssu/mce/blob/88a69e02c61e24aa272e1f63971e03424c051b09/modules/display.c#L1367 | 20:56 |
| freemangordon | this is missing in the new module | 20:56 |
| freemangordon | you shaved too much code | 20:59 |
| freemangordon | MCE_TRANSITION_SUBMODE is also nowhere to be found | 20:59 |
| freemangordon | well, in tklock | 21:00 |
| freemangordon | hmm, my bad | 21:00 |
| freemangordon | scratch that | 21:01 |
| freemangordon | I think to extend MCE_PREVENT_BLANK_REQ with an additional, optional, "enable" parameter | 21:19 |
| freemangordon | so h-d to be able to tell mce that it no longer needs blaanking prevention | 21:20 |
| Wizzup | dreamer: yeah we're still in alpha | 21:44 |
| freemangordon | uvos: what about this? https://pastebin.com/WWvLiqyj | 21:46 |
| freemangordon | h-d will require changes as well, but noit a biggie | 21:48 |
| freemangordon | *not | 21:48 |
| freemangordon | that way setting DND on a window will enable blanking when the window is gone | 21:48 |
| Wizzup | sicelo: freemangordon: leste.maemo.org and phoenix.maemo.org should be back | 21:50 |
| Wizzup | it's on a different storage for now until I have more time to migrate it and also make the image smaller | 21:51 |
| buZz | boo, rockbox-as-a-SDL-application kinda requires gcc4.x for ARM :( | 21:52 |
| freemangordon | https://git.kernel.org/pub/scm/network/ofono/ofono.git/log/ :) | 21:57 |
| Wizzup | saw the mails, nice | 21:58 |
| freemangordon | yeah | 21:58 |
| freemangordon | nice that they are not picky | 21:58 |
| * sicelo impressed | 21:59 | |
| sicelo | the commonly stated reason for migrating away from ofono to MM within mobile linux communities has been 'ofono development is slow and they do not accept contributions' | 22:01 |
| dreamer | Wizzup: hmhm. will reflash when I have time :) | 22:01 |
| uvos | freemangordon: the display module is nolonger involved in the blaning inhibit | 22:31 |
| uvos | i move that to its own module | 22:31 |
| uvos | freemangordon: so your adding a new interface that allows you to remove the blaning pause? | 22:31 |
| uvos | ok, by why dose tklock need to do this at all | 22:31 |
| freemangordon | yes | 22:31 |
| uvos | it gets its own submode in mce anyhow | 22:31 |
| freemangordon | it sets DND on tklock window | 22:31 |
| uvos | so mce could just do whatever beavior wise | 22:31 |
| uvos | no dnd needed | 22:31 |
| uvos | and infact it dose | 22:32 |
| uvos | i think the tklock module disables blanking anyhow while in vtklock | 22:32 |
| freemangordon | well, it is not about tklock, but about hildon_gtk_window_set_do_not_disturb() | 22:32 |
| uvos | sure, im just questioning why tklock needs to call this | 22:33 |
| freemangordon | every application that calls this will break blanking period for 60 seconds | 22:33 |
| freemangordon | not sure | 22:33 |
| uvos | yes i know | 22:33 |
| uvos | the patch is fine | 22:33 |
| freemangordon | So, my fix is in that regard | 22:33 |
| freemangordon | we may remove hildon_gtk_window_set_do_not_disturb() from vtklock, but that's another story | 22:34 |
| freemangordon | ok, so I'll push that to mce and will fix h-d to use the new interface | 22:34 |
| freemangordon | uvos; what will happen if some application requests MCE_DISPLAY_OFF while vtklock is active? maybe this is why they set DND | 22:36 |
| freemangordon | realy hard to say what did they have in mind | 22:36 |
| uvos | mce should/could ignore it in tklock mode anyhow | 22:37 |
| uvos | dnd or no | 22:37 |
| freemangordon | yes, but does it ignore it now? maybe that pisece was/is missing so that's why they set DND | 22:37 |
| uvos | anyhow it was broken in fremantle so im not sure they had something sane in mind. | 22:37 |
| freemangordon | *piece | 22:37 |
| freemangordon | could be | 22:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!