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