vagag has left #maemo-leste [Error from remote client]
pere has quit [Ping timeout: 260 seconds]
Pali has quit [Ping timeout: 248 seconds]
alex1216 has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
pere has joined #maemo-leste
mardy has joined #maemo-leste
noidea_ has quit [Remote host closed the connection]
noidea_ has joined #maemo-leste
alex1216 has quit [Ping timeout: 276 seconds]
alex1216 has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
ceene has quit [Ping timeout: 260 seconds]
<buZz>
mornin'
<Wizzup>
yo
<buZz>
oh man, i realized i own a second droid4 last night
<buZz>
tried it out for battery behaviour a bit, seems -tons- better than the 'new' battery in my other one
<buZz>
-but- dmesg still shows unable to detect the battery type
<buZz>
yet both are legit EB41 , as far as i can tell
<buZz>
android is happy with the batteries too, so i'm starting to think that cpcap-battery.c detection isnt working
<buZz>
Wizzup: do you have leste running on a droid4 with legitimate EB41? could you give dmesg output? i'm curious , or pastebin /sys/class/power_supply/battery/uevent or something
<Wizzup>
I don't have one with EB41 here atm
<buZz>
alrighty, maybe someone else?
<buZz>
or droid3 with original battery perhaps?
<Wizzup>
I will have to check
<buZz>
no hurry
ceene has joined #maemo-leste
Guest9450 has quit [Quit: Konversation terminated!]
_j has joined #maemo-leste
_j is now known as Guest3158
xmn has joined #maemo-leste
<buZz>
i wonder what the 'POWER_SUPPLY_TEMP' even means
<buZz>
'336' its outputting here during a charge
<Wizzup>
probably 37C
<Wizzup>
err
<Wizzup>
33C
xmn has quit [Remote host closed the connection]
<buZz>
oh, /10 , yeah that could work
xmn has joined #maemo-leste
Guest3158 has quit [Changing host]
Guest3158 has joined #maemo-leste
Guest3158 has quit [Quit: Konversation terminated!]
Guest9871 has joined #maemo-leste
Guest9871 has quit [Changing host]
Guest9871 has joined #maemo-leste
Guest9871 is now known as joerg
joerg is now known as Guest3028
Guest3028 is now known as joerg
joerg has quit [Quit: Konversation terminated!]
_j has joined #maemo-leste
_j is now known as Guest9278
Guest9278 has quit [Client Quit]
_j has joined #maemo-leste
_j is now known as Guest5951
Guest5951 has quit [Client Quit]
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
<buZz>
anyone else online with a recent leste that would like to share dmesg or /sys/class/power_supply/battery/uevent ?
<buZz>
specifically while aware of batterytype
<buZz>
oh impressive
<buZz>
'mplayer -nosound -fs -loop 0 bla.mp4' seems to almost fully lockup a droid4?
<buZz>
ah, its using 'gl_nosw' as video output :)
<buZz>
-vo sdl works :)
ceene has quit [Remote host closed the connection]
pere has quit [Ping timeout: 256 seconds]
arno11 has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
<buZz>
pff, this battery in my second droid4 is somekinda superbattery?
<buZz>
or maybe i'm finally seeing all those powersavings work :D
<buZz>
been playing video on fullscreen with sw decoding and scaling for 90 minutes , with screen always on
<buZz>
battery still at ~50%
<bencoh>
so basically ... ~550mA for video decoding + display
<buZz>
seems so, just put up backlight to max brightness
<buZz>
trying to get a full calibration cycle in ;)
<bencoh>
don't you use the gpu video output btw?
<bencoh>
scaling is gpu-accelerated
<bencoh>
(and it works great)
<buZz>
eh, i use -vo x11 now even
<buZz>
which gpu video output did you mean?
<buZz>
-vo xv?
<buZz>
i dont usually play video on the droid4
<buZz>
bencoh: do you run leste on your device?
<buZz>
16:20:42 < buZz> anyone else online with a recent leste that would like to share dmesg or /sys/class/power_supply/battery/uevent ?
<buZz>
16:20:55 < buZz> specifically while aware of batterytype
<buZz>
^^
<bencoh>
buZz: yeah, I run leste
uvos has joined #maemo-leste
<bencoh>
I should share my mpv config file (not now though)
<Wizzup>
uvos: btw did you saw my q yersterday about why the audio would work for tmlind ?
<buZz>
but that request?
<buZz>
bencoh: i'm trying to see the cpcap-battery.c work well for anyone to detect a battery :)
<bencoh>
I don't have it right now - oh and I use stable, not -devel
<buZz>
thats ok, should be in stable too
<bencoh>
well, will see when I get a hold of it then :)
<bencoh>
(do ping me in a few hours)
<uvos>
hi Wizzup
<uvos>
no sorry
<uvos>
ill read the logs
<uvos>
buZz: eeprom is exposed in sysfs
<buZz>
eeprom? did you mean nvmem?
<buZz>
there's no nvmem exposed in sysfs on the cpcap entries
<uvos>
its a eeprom chip
<uvos>
but yeah its exposed via nvmem if
<buZz>
did you know the cpcap driver isnt even depending on nvmem?
<uvos>
yes i know
<uvos>
wait ill try to explain
<buZz>
error even specifically says 'NULL device, cant find battery'
<uvos>
yes i know
<buZz>
on legitimate EB41
<uvos>
i added that
<buZz>
i'm gonna add 'detected EB41' stuff to it aswell, once i can see it even detect something :P
<uvos>
no dont
<uvos>
i allready did
<buZz>
oh, its not in the code
<uvos>
it just got lost
<uvos>
yeah i know it got lost
<buZz>
i ment adding it to the code
<uvos>
i have pachtes
<uvos>
im currently preparing 5.16 for lestee
<uvos>
buZz: we cant parse anything from the eeprom, its some unkown binary format thats processed by a propriary deamon on android, that motorola replaced the normal android one with
<uvos>
buZz: additionally we also blacklist the one wire bus driver that the eeprom is on
<Wizzup>
maybe we need to update the issue since even speakerphone doesn't fully work right
<Wizzup>
ah you wrote that before
<uvos>
anyhow geting this behave right is quite the exercise in alsa expertise, i havent been able to make it work
<uvos>
and the fokls on the alsa/asoc ml where not able to help unfortionalty
<uvos>
or maybe im just missing how this is supposed to be implemented
<uvos>
no driver in mainline seams to have this setup
<uvos>
as far as i can tell
<uvos>
but other devices must have the same problem
<uvos>
like the pp should have the same issue iiuc how it works in hw, havent look at its driver
<Wizzup>
ok
<Wizzup>
>
<Wizzup>
Anyhow if you patch the kernel to allow writes on regmaps and set CPCAP_REG_RXCOA appropriately while in a call the call audio will work absolutely fine in every way.
<Wizzup>
I guess that would be worth a shot
<Wizzup>
Do you have a patch to that effect somewhere
<uvos>
Wizzup: no but if you look in the kernel where the regmap debugfs is implemented
<uvos>
the file has a really obivous name but i dont recall
<uvos>
theres a comment and a line you need to uncomment to make the regmaps wirtable from userspace
<freemangordon>
this would be a terrible hack
<uvos>
sure yeah
<uvos>
its just for debuging
<freemangordon>
what I don;t understand is why kernel assumes voice if to be not used
<uvos>
it has no way of knowing its used
<freemangordon>
so, modem is using it without kernel knowing that?
<uvos>
yeah the kernel cant tell when the modem is playing something
<uvos>
really whenever the kernel routes the audio to the modem it must assume that the modem is doing something
<uvos>
but the framework dosent make this easy
<freemangordon>
ok, but does modem have sound driver?
<uvos>
no and the concept dosent make sense, the modem audio isent connected to cpu
<freemangordon>
how,s that related?
<freemangordon>
(connected to cpu)
<uvos>
how is it not related?
<uvos>
what would a kernel driver for modem audio even do?
<freemangordon>
provide the bits needed to control power etc
<uvos>
power to what?
<uvos>
the modem
<uvos>
the modem driver dose that
<freemangordon>
not only
<uvos>
anyhow in a way yes the solution is to write a modem audio driver sorta
<uvos>
just one that dosent really comunicate with the modem
<uvos>
but makes the framework happy
<freemangordon>
mhm
<uvos>
as i wrote in the bug
<Wizzup>
freemangordon: of course it's a hack but if it helps just -testing- to see if voice calls work, I think that's nice...
<Wizzup>
and also something I could use :)
<freemangordon>
ah
<bencoh>
is the mic directly connected to modem on d4? or only the speaker?
<uvos>
both mics are directly connected ot the modem
<freemangordon>
vute :)
<freemangordon>
*cute
<uvos>
however the modem cant use them
<uvos>
without the cpus consent
<uvos>
the cpu neds to setup the route in cpcap
<bencoh>
which is nice
<bencoh>
(no spying modem)
<freemangordon>
well...
<uvos>
on d4 and bionic (but not d3)
<uvos>
the lte modem can setup the routes and route the mic to the modem
<uvos>
but it cant route the mic to itself
<bencoh>
gah ...
<uvos>
only to the qcom modem
<uvos>
(3g)
<bencoh>
sounds silly
<uvos>
so only the d3 is truely safe if the modems coperate
<uvos>
bencoh: its just by accident
<bencoh>
haha
<uvos>
bencoh: the 3g modem has its own pmic
<uvos>
the 4g modem is connected to cpcap because it uses it as its pmic
<uvos>
btw the 4g modem's regulator is off on mainline
<uvos>
so really it cant do anything
<bencoh>
I see :)
<Wizzup>
uvos: ok well if you have any hints re: what file that'd be heplful
Pali has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
<uvos>
* This can be dangerous especially when we have clients such as
<uvos>
* PMICs, therefore don't provide any real compile time configuration option
<uvos>
* for this feature, people who want to use this will need to modify
<uvos>
* the source code directly.
<uvos>
*/
uvos has quit [Remote host closed the connection]
<Wizzup>
ok
<Wizzup>
maybe we need to enable this for us
vagag has joined #maemo-leste
pere has joined #maemo-leste
sunshavi_ has joined #maemo-leste
sunshavi has quit [Ping timeout: 256 seconds]
vagag has left #maemo-leste [#maemo-leste]
<sicelo>
callaudiod could possibly be used to toggle the register(s) when a call is established
<Wizzup>
what is this?
<sicelo>
Previously it was wys. It's used to handle calls when you need more than just routing audio
<Wizzup>
wys?
<sicelo>
Yes. Librem5 used it in the early stages of phosh
<Wizzup>
ok, I don't know what wys is still
<Wizzup>
uvos: ok so I guess we just change the undef into define
<DPA>
Essentially, wys pipes some audio audio inputs to some audio outputs when there is a call (which it knows using dbus), and uses pulseaudio to do so. THe oudio devices involved are usually the modem, the speakers, and the microphone.
<DPA>
I think callaudiod just changes some audio controls / routing instead, and may not be applicable everywhere, but I'm not entirely sure.
xmn has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
this is not applicable to mapphones no real routing has to be done by cpu or pulse or pipewire, its all in hw
norayr has joined #maemo-leste
<uvos>
i dont think enabling writable regmaps is sane for anything except on a dev machine to write a better audio dirver/ setup
<uvos>
looking at source: callaudio just switches around pulse mixer values
<uvos>
same thing sphone allready dose
<uvos>
there is no problem with this part, see phinephone