| buZz | ahh ok | 00:22 |
|---|---|---|
| mighty17[m] | what flags do i need to build maemo's mesa? https://github.com/maemo-leste-upstream-forks/mesa/blob/maemo/beowulf-devel/debian/rules ? | 12:02 |
| mighty17[m] | here there is nothing about pvr/omapdrm | 12:02 |
| Wizzup | meson.build contains that list | 12:05 |
| Wizzup | also our patches add it | 12:05 |
| Wizzup | see debian/patches | 12:05 |
| Wizzup | commit cc91f322fe12c60d661dc112b226eb82f4b03f7e | 12:05 |
| Wizzup | hm wait let me double check | 12:05 |
| Wizzup | I mean you'll definitely need the patch from that commit | 12:06 |
| Wizzup | yeah see | 12:06 |
| Wizzup | it adds the pvr driver | 12:06 |
| Wizzup | https://github.com/maemo-leste-upstream-forks/mesa/commit/cc91f322fe12c60d661dc112b226eb82f4b03f7e | 12:06 |
| Wizzup | so it's not in debian/rules, it's in meson.build | 12:06 |
| Wizzup | wait, it's also in debian/rule s:) | 12:07 |
| Wizzup | (waking up) | 12:07 |
| mighty17[m] | yeah i already apply your patches, i just wanted to check the build configs for meson | 12:07 |
| Wizzup | wait, so you're not just building our tree | 12:07 |
| Wizzup | ? | 12:07 |
| mighty17[m] | i am | 12:07 |
| mighty17[m] | just not on debian | 12:07 |
| Wizzup | ok | 12:07 |
| Wizzup | well the patch in debian/patches patches debian/rules | 12:07 |
| Wizzup | so assuming you have applie it you should see | 12:07 |
| Wizzup | - GALLIUM_DRIVERS += etnaviv kmsro lima panfrost tegra vc4 v3d | 12:07 |
| Wizzup | + DRI_DRIVERS += pvr | 12:07 |
| Wizzup | + GALLIUM_DRIVERS += etnaviv kmsro lima panfrost vc4 v3d | 12:07 |
| mighty17[m] | correct :D | 12:08 |
| Wizzup | ok | 12:08 |
| mighty17[m] | but my build system doesnt use rules :P | 12:08 |
| Wizzup | so what flags do you mean? | 12:08 |
| Wizzup | right | 12:08 |
| Wizzup | well, oyu'll need to set the DRI_DRIVERS and GALLIUM_DRIVERS I guess | 12:08 |
| Wizzup | DRI_DRIVERS := $(patsubst %,'%',$(DRI_DRIVERS)) | 12:08 |
| mighty17[m] | https://gitlab.com/pvrports/pvrports/-/merge_requests/3/diffs#7ad7275e6f960baa3165b9b143cb5984e676e684_65_75 | 12:08 |
| Wizzup | rules is just make | 12:08 |
| Wizzup | so it'd be -Ddri-drivers=pvr,etc,foo,bar | 12:09 |
| Wizzup | I think | 12:09 |
| Wizzup | but you can also check our CI | 12:09 |
| Wizzup | it might contain that info | 12:09 |
| Wizzup | (the build log) | 12:09 |
| Wizzup | https://phoenix.maemo.org/job/mesa-binaries/architecture=armhf,label=armhf/97/consoleText | 12:10 |
| mighty17[m] | ah thanks a lot! | 12:15 |
| mighty17[m] | it shows the output ig | 12:16 |
| Wizzup | uvos: maybe we should make share some amixer command sequence to fix the audio temporarily | 12:25 |
| Wizzup | sicelo: do you know who to ask if I want to change the maedevu.maemo.org dns | 12:39 |
| Wizzup | Would that be xes ? | 12:39 |
| Wizzup | I'm looking to host the server on my own infra | 12:39 |
| Wizzup | Will get rid of the space issues | 12:40 |
| sicelo | Wizzup, yes, iirc it's xes and warfare. joerg might know best | 14:17 |
| joerg | warfare | 14:18 |
| joerg | our DNS is the one domain I never looked into, no idea where and by whom it's hosted | 14:20 |
| _uvos_ | Wizzup: wdym amixer commands there no sutch commands, sphone sets the mixer up correctly | 14:20 |
| Wizzup | hm | 14:20 |
| Wizzup | but buzz reports no audio with sphone | 14:21 |
| Wizzup | I think | 14:21 |
| _uvos_ | to hack it to make it temorarily work you have to wirte to cpcap registers by patching the kernel to allow wirtes fromuserspace on the regmap | 14:21 |
| _uvos_ | and then just wirte the regs | 14:21 |
| _uvos_ | yes audio effectively dosent work | 14:22 |
| Wizzup | ah, so it can't be done with amixer | 14:23 |
| _uvos_ | no | 14:23 |
| _uvos_ | as soon as you switch to the call audio the kernel disabales all audio outputs because it thinks no sound is playing | 14:23 |
| _uvos_ | because it dosent know that it not playing audio dosent mean that the amps dont need power | 14:23 |
| _uvos_ | sine the modem is now playing audio | 14:24 |
| Wizzup | ok | 14:24 |
| _uvos_ | this is a fundamental limitation of the asoc framework | 14:24 |
| _uvos_ | when the generic card driver is used | 14:24 |
| Wizzup | can we write the registers from userspace? | 14:25 |
| _uvos_ | no, not without patching the kernel | 14:25 |
| _uvos_ | for some reason when you disable all audio outputs cpcap enables the speaker | 14:25 |
| _uvos_ | thats why speakerphone sortof works | 14:25 |
| _uvos_ | this is kinda a bug in cpcap hw | 14:25 |
| _uvos_ | but the amp for the mic remains disabled | 14:26 |
| _uvos_ | (thats why you only get one way audio) | 14:26 |
| Wizzup | hm | 14:26 |
| _uvos_ | the only fix for this is writing a new driver | 14:26 |
| _uvos_ | that dosent use the generic framework | 14:26 |
| _uvos_ | (aka the very hard way) | 14:27 |
| Wizzup | btw one downside with telepathy-gabble is that it doesn't do OMEMO for xmpp | 18:21 |
| Wizzup | not the end of the world but eh | 18:21 |
| Wizzup | uvos: wonder if we could consider some hack fix to the kernel | 18:22 |
| buZz | weird, looking at voltage and power_now over time, it seems maybe there's no CCCV charging? only CC? | 18:26 |
| buZz | seems that once it would normally switch to CV , it stops charging , leaving battery around ~3.9V for full | 18:27 |
| buZz | ^^^ kinda explains the constant re-charging once almost full, it will hit 4.2V , needs to switch to CV, doesnt, drop below 4.0v when charger disables (because its not full) , and then starts the CC charger again | 18:34 |
| bencoh | oh | 18:40 |
| bencoh | now that explains it indeed | 18:40 |
| buZz | i'm just catting /sys/class/power/battery/ stuff, not really monitoring properly | 18:41 |
| buZz | but this totally seems to be happening | 18:41 |
| buZz | also i guess the battery might be overheating because of this, the CC causes a lot more heat | 18:49 |
| buZz | which might be the cause of the 'droid4 on powersupply tends to poweroff after a while' | 18:50 |
| buZz | btw, anyone got syncevolution to actually work against a horde install ? :P | 19:08 |
| Wizzup | buZz: hm, horde? | 19:36 |
| buZz | its a 'groupware' nonsense thingy with SyncML and WebDAV and eh , addressbook, calendar, etc | 19:37 |
| buZz | https://www.horde.org/ | 19:37 |
| Wizzup | ought to work if it does caldav | 19:37 |
| buZz | i was trying SyncML , is caldav/webdav more mature? | 19:37 |
| Wizzup | idk | 19:38 |
| Wizzup | I haven't tried it | 19:41 |
| Wizzup | I just know I have instructions for caldav :) | 19:41 |
| buZz | :) welp, i'll just continue trying this stuff :P | 19:41 |
| uvos | buZz: thats not true | 19:59 |
| uvos | buZz: it charges cv at the end | 19:59 |
| uvos | slight problem is that the voltage drop is huge | 19:59 |
| uvos | if you mesure at the terminals you will see that it is indeed about 4.2v after cutoff | 20:00 |
| buZz | i see it charge -to- 4.2v and then directly stop, yes | 20:00 |
| uvos | no | 20:00 |
| buZz | i'm saying what i'm seeing :) | 20:00 |
| uvos | you looking at sysfs | 20:01 |
| uvos | if you mesure at the terminals its quite different | 20:01 |
| buZz | i'll need to fix up my DMM then, i guess | 20:01 |
| buZz | maybe i can make a sit-between measurement setup | 20:02 |
| uvos | also note that sysfs lies | 20:04 |
| uvos | (the current is a total lie) | 20:04 |
| buZz | well, its negative during charging and positive during discharging | 20:05 |
| buZz | at least that part seems correct then :P | 20:05 |
| uvos | right but its not messuring the real current | 20:05 |
| uvos | but what its intending to happen | 20:05 |
| uvos | that probubly made you think its cc charging | 20:05 |
| buZz | well, if its -intending- to pump 800mA into the battery, that doesnt sound like its intending to do CV | 20:06 |
| uvos | no | 20:06 |
| buZz | agreed | 20:06 |
| uvos | its telling cpcap that it shal pump 800mA into the battery | 20:06 |
| uvos | max | 20:06 |
| uvos | what it really dose is down to cpcap hw | 20:06 |
| uvos | which is a cc cv supply | 20:06 |
| uvos | buZz: check out the mc13783 datasheet | 20:11 |
| uvos | page 8-8+ | 20:11 |
| uvos | (this chip is register identical to cpcap wrt the charging block) | 20:11 |
| uvos | we just set ICHRG and VCHRG | 20:12 |
| uvos | it just pumps ICHRG into the battery untill it hits VCHRG | 20:12 |
| uvos | then it regulates VCHRG to be at the terminals | 20:13 |
| uvos | buZz: charge termination is is indicated by the charge termination irq | 20:13 |
| uvos | this fires when the current drops below a thresh | 20:14 |
| uvos | so yeah bascily all of this is handled in hw | 20:14 |
| uvos | (thresh is 30mA btw, also fixed in hw) | 20:17 |
| buZz | and we're charging to 4.3V ? | 20:17 |
| uvos | no 4.2 | 20:17 |
| uvos | but you can set it 4.3 in sysfs | 20:17 |
| uvos | and the battery is desined to take it | 20:17 |
| uvos | as its hvlipo | 20:18 |
| buZz | right, as the droid4 uses a 'high voltage' cell | 20:18 |
| uvos | right but we do 4.2 as a curtsy to people that replace the cell | 20:18 |
| uvos | by default | 20:18 |
| buZz | might be useful to put on the wiki :P there's quite some capacity thats lot there | 20:18 |
| uvos | right yeah | 20:19 |
| uvos | but its not that mutch | 20:19 |
| buZz | do you know offhand which sysfs entry to tell 4.3? | 20:19 |
| uvos | most of the cap of a hvlipo comes from the higher nominal voltage | 20:19 |
| uvos | above 4.2 is very little | 20:19 |
| uvos | constant_charge_voltage iirc | 20:20 |
| buZz | in cpcap-battery or cpcap-charger? | 20:20 |
| buZz | or are they the same | 20:21 |
| uvos | no they are not the same | 20:21 |
| uvos | i think in charger | 20:21 |
| uvos | def in charger | 20:21 |
| buZz | i cant seem to overwrite it ? 'echo 4300000 > constant_charge_voltage' , nor 'echo -n 4300000 > ...' | 20:22 |
| uvos | echo 4300000 > constant_charge_voltage | 20:24 |
| uvos | cat constant_charge_voltage | 20:24 |
| uvos | 4300000 | 20:24 |
| uvos | works fine here | 20:24 |
| buZz | yeah, thats what i did, sticks to 4200000 here | 20:24 |
| uvos | voltage_max_design? | 20:24 |
| buZz | ah, lets try that first i guess | 20:25 |
| uvos | no i mean | 20:25 |
| uvos | this limits constant_charge_voltage | 20:25 |
| uvos | if its 4200000 it wont work | 20:25 |
| uvos | there is some detection logic that i added that should take care of this | 20:25 |
| buZz | right, i dont think its working :P | 20:26 |
| uvos | well what is voltage_max_design? | 20:26 |
| buZz | thats saying 4200000 indeed , for a li+ thats labelled 'HV' | 20:26 |
| buZz | https://github.com/maemo-leste/droid4-linux/blob/master/drivers/power/supply/cpcap-battery.c#L372 , 4347000? :D | 20:28 |
| uvos | well it works by reading the battery eeprom | 20:28 |
| buZz | where is that code? | 20:28 |
| uvos | if it cant read the eeprom it defaults to 4.2 | 20:28 |
| buZz | https://github.com/maemo-leste/droid4-linux/blob/master/drivers/power/supply/cpcap-battery.c#L686 < 4351000 ? | 20:29 |
| uvos | apperantly it got lost | 20:29 |
| uvos | the detrection code is not in leste anymore | 20:29 |
| uvos | it seams | 20:29 |
| buZz | ahhh, a bug! :D | 20:30 |
| buZz | hehe | 20:30 |
| buZz | nice that we've caught that now | 20:30 |
| uvos | kinda | 20:35 |
| uvos | more of a missing feature | 20:35 |
| uvos | anyhow those voltages 4.351 etc are from android | 20:36 |
| buZz | yeah the code is aswell, i assume? | 20:36 |
| uvos | no | 20:36 |
| buZz | oh? just the comments then? | 20:36 |
| uvos | no nothing is | 20:36 |
| buZz | really should flash that android thingy back on this droid4 to check what cpcap does with this battery | 20:37 |
| uvos | just that the register values corrispond to voltages | 20:37 |
| uvos | and the reister values where chosen in mainline linux to be the same mostly | 20:37 |
| uvos | which implies thresholds etc | 20:37 |
| buZz | i'm not really following why what userland runs on a kernel matters for the values you get from the kernel | 20:38 |
| buZz | but ok | 20:38 |
| uvos | charging on android is implmentented mostly in userspaci iirc | 20:38 |
| uvos | and the cpcap driver is totaly different | 20:38 |
| buZz | the hw charger gets into different modes? | 20:39 |
| uvos | i dont follow | 20:39 |
| uvos | the charger switches from cc to cv automaticly in hw, other than "off" it has no other modes | 20:39 |
| buZz | eh, i mean, if the charging happens in hw, what does it matter if its happening in userspace? | 20:39 |
| uvos | (well tickle charging) | 20:39 |
| uvos | buZz: it dosent, why do you think it dose? | 20:40 |
| buZz | you just said it does? | 20:40 |
| buZz | O_o | 20:40 |
| uvos | ? no, you must have missunderstood me | 20:40 |
| buZz | oh ok, so charging works comparable in android? | 20:41 |
| uvos | yes | 20:41 |
| uvos | the register values of the hw charger where taken from android | 20:41 |
| uvos | and they are indeed the sam eif you diff them | 20:41 |
| uvos | so since its fully hw implemented | 20:42 |
| uvos | the behavior must be the same really | 20:42 |
| buZz | alright, so 4347000 / 4351000 is full? | 20:42 |
| uvos | well no, thats one thing we did change | 20:42 |
| uvos | by default | 20:42 |
| uvos | but other than that | 20:42 |
| uvos | is what i mean | 20:42 |
| buZz | so we've cut off max voltage, right | 20:42 |
| uvos | right | 20:42 |
| buZz | maybe i should just pull the kernel source to droid4 , and edit the 4200000 constant on it | 20:43 |
| uvos | the other thing thats different is how android computes state of charge | 20:43 |
| uvos | but thats just related to what it displays | 20:44 |
| uvos | mostly the android method mostly works | 20:44 |
| uvos | and the mainline method only sorta works :P | 20:44 |
| buZz | ehhh no 'fakeroot' or 'build-essential' on leste? ehhhh | 20:47 |
| sicelo | doesn't that come from devuan? | 20:47 |
| buZz | it should | 20:47 |
| uvos | it dose | 20:47 |
| uvos | you have a problem localy | 20:47 |
| buZz | wonder wtf | 20:47 |
| buZz | woa , 'apt update' is pulling in a ton O_o but whyyy | 20:48 |
| buZz | alright, works now | 20:49 |
| Wizzup | buZz: well I moved stuff over from devel to stable | 20:49 |
| Wizzup | so that causes version bumps | 20:49 |
| buZz | ah that might be what happened :) | 20:49 |
| buZz | are there source repos for the leste stuff? | 20:50 |
| Wizzup | source as in git, or source as in deb-src | 20:50 |
| buZz | the latter :) | 20:50 |
| Wizzup | yes | 20:50 |
| Wizzup | just use deb-src | 20:50 |
| buZz | alright | 20:51 |
| buZz | 'unable to find source pkg for linux-image-omap' | 20:52 |
| buZz | aw | 20:52 |
| buZz | ok, bbl | 20:55 |
| Wizzup | buZz: for that you can use git | 21:10 |
| Wizzup | it's better probably | 21:10 |
| Wizzup | buZz: but it should be there, but the src pkg is likely called differently | 21:10 |
| Wizzup | Source: omap-linux | 21:10 |
| buZz | it doesnt find that either | 21:36 |
| Wizzup | what do you run | 21:41 |
| buZz | -devel | 21:42 |
| buZz | 5.15.1-2+2m7.1 | 21:42 |
| buZz | oh, command? | 22:02 |
| buZz | apt-get build-dep omap-linux | 22:03 |
| buZz | 'linux-image-omap' gives same response | 22:03 |
| Wizzup | what about any other maemo package | 22:08 |
| buZz | lets see | 22:08 |
| buZz | ahhh, osso-terminal also nothing | 22:08 |
| buZz | pastebin.com/ErzdcnrF | 22:11 |
| buZz | isnt that setup correctly? | 22:11 |
| Wizzup | let me check | 22:23 |
| Wizzup | buZz: you did 'apt update' right? | 22:24 |
| buZz | yeah , bunch of times | 22:25 |
| Wizzup | let me check. | 22:25 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!