<sicelo>
i hope the question wasn't worded in a way to favor one option over the other :-/
slep has left #maemo-leste [#maemo-leste]
slep has joined #maemo-leste
slep has quit [Quit: Gateway shutdown]
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #maemo-leste
fab_ has joined #maemo-leste
ceene has joined #maemo-leste
fab_ has quit [Quit: fab_]
fab_ has joined #maemo-leste
fab_ has quit [Quit: fab_]
ahmed_sam has quit [Ping timeout: 256 seconds]
uvos__ has joined #maemo-leste
<uvos__>
sicelo: i dont think its worded biased, i mean i would have made the argument that haveing one interface to proximitry sensors is a good thing, regardless of if it fits absolutly compleatly
<uvos__>
i really disagree that this split is sane, but ok
uvos__ has quit [Remote host closed the connection]
uvos__ has joined #maemo-leste
akossh has joined #maemo-leste
<uvos__>
maybe a reply explaining why we want to do this would be in order (ie we have some devices that definatly need to be on iio since they have >1b and would like to avoid having multiple interfaces to the same thing)
ac_laptop has joined #maemo-leste
<ac_laptop>
Hello people
<ac_laptop>
n900 went out of battery yesterday, I let it plugged all night, this morning: I boot it twice under lest, it shut down immediately, third time it didn't boot at all. I plugged it for a few minutes, could boot under leste : it says the battery is near 0%. I reboot it under fremantle: the battery indicates 60% or so
<ac_laptop>
I'm letting it charge now, I'll reboot it under leste when fremantle indicates 100%
<sicelo>
We need to see the uevent. Not much we can say until then
<ac_laptop>
sicelo: I will upload the uevent log file when I reboot under leste
<sicelo>
So far it sounds like a worn out battery
<sicelo>
Yes Fremantle will behave better. Since it draws as little as 4mA most of the time, compared with 50mA on Leste
<ac_laptop>
sicelo: this is a replacement battery I just bought, in case those problems were due to the original one.
<ac_laptop>
sicelo:better power management explains the slower battery consumption on fremantle. It doesn't explains why leste suddently believes the battery is at 0% when it clearly isn't.
<sicelo>
Unfortunately because these are old devices, "new" batteries tend to be just as bad (n900 or any other device)
<sicelo>
ac_laptop: a worn battery has higher resistance, then voltage drops in exactly the way you describe
<ac_laptop>
sicelo: I let the device run for a day and a half on fremantle without any trouble
<ac_laptop>
sicelo: why would it drop suddently only under leste ? is it because of the higher consumption of leste ?
<sicelo>
Yes, possibly
<ac_laptop>
I guess I'll buy a third battery then
<sicelo>
Maybe wait until you have the output we requested... the voltage will be visible there
<uvos__>
if you do buy a battery
<uvos__>
buy modern repoduction, not a original
<Wizzup>
polarcell has good ones
<ac_laptop>
yes, if you have any recommendations in brand I'll take them, because when I search for 'BL-5J' I get pretty much everything
<uvos__>
polarcell numbers are fairly grounded in reality
Pali has joined #maemo-leste
arno11 has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
sch has quit [Ping timeout: 255 seconds]
sch has joined #maemo-leste
ceene has quit [Ping timeout: 268 seconds]
fab_ has joined #maemo-leste
fab_ has quit [Ping timeout: 256 seconds]
sch has quit [Ping timeout: 256 seconds]
arno11 has joined #maemo-leste
ac_laptop has quit [Ping timeout: 276 seconds]
<Wizzup>
freemangordon: cool @ omp, ready for testing? :)
<freemangordon>
should be
<freemangordon>
well, qml part still does not work
<freemangordon>
also, someday I plan to implement transparent controls background, in video window
<freemangordon>
but besides that I am not aware of any issues
<freemangordon>
have to check the one that you reported though
<freemangordon>
(unknown album or whatever it was)
<freemangordon>
maybe we shall not display albums with 0 items in then, dunno
<Wizzup>
I think they do have items
<Wizzup>
it's just that the query doesn't work
<freemangordon>
hmm
<freemangordon>
do you know which query is that
<freemangordon>
like, could you stop mafw-tracker-source (/usr/bin/mafw.sh stop mafw-tracker-source) and then G_MESSAGES_DEBUG=all MAFW_LOG=all /usr/bin/mafw-dbus-wrapper mafw-tracker-source
<freemangordon>
you should get all the queries printed
<Wizzup>
yes, in a bit :)
<Wizzup>
upgrading first, and also getting a coffee first
<Wizzup>
but soon :)
<freemangordon>
ok
<freemangordon>
no hurry
<Wizzup>
uvos__: btw I finally got these set up https://wiki.dfrobot.com/Power_Module__SKU_DFR0205_ and will use them for a lab droid4 setup, hopefully with microsd extender cable and the pcb to switch microsd from the actual slot to usb
<freemangordon>
BTW, most if not all bugs I fixed in omp are fremantle legacy :)
<Wizzup>
heh
<Wizzup>
some details on it would be cool, I'd include that in our news post
<freemangordon>
see changelog
<Wizzup>
ok
<Wizzup>
should the video scale to d4 screen?
<freemangordon>
yes
<Wizzup>
hmm
<Wizzup>
it doesn't yet on my d4
<freemangordon>
hmm?
<Wizzup>
well, I went to videos, clicked play, and it plays at n900 res
<Wizzup>
like some parts of the screen are unused
<Wizzup>
btw we should maybe update the about of OMP to include ourselves
<Wizzup>
or you mostly I guess
<freemangordon>
did you select "fit ti screen"?
<Wizzup>
fit only makes it like 10px larger
<freemangordon>
weird
<freemangordon>
what video is that?
<freemangordon>
oh,wait
<freemangordon>
what is mafw-gst-renderer version?
<bencoh>
"Depends on the driver, OpenGL handles hardware accelerated scaling of video frames." from glimagesink. does this imply it might not be supported?
<Wizzup>
freemangordon: oh could it be not gles but gl
<ac_laptop>
There doesn't seem to be anything from the reboots of this morning that were followed by an immediate shutdown, I guess upower didn't even have the time to log anything
<sicelo>
these are not logged by upower
<sicelo>
so, looks like you had a shutdown somewhere around Mon Nov 20 00:51:01 CET 2023
<sicelo>
that was low voltage, and absolutely expected
<sicelo>
at least the few logs leading to that shutdown look ok to me.
<ac_laptop>
so that seems to support the hypothesis that both of my batteries are faulty ?
<sicelo>
not necessarily. maybe just give the whole thing time to calibrate to the true capacity
<ac_laptop>
sicelo: I can't get it to calibrate when it refuses to boot
<sicelo>
at the last log, the fuel gauge thought your battery is good for 1400mAh. more calibration cycles will bring it closer to the true capacity
<sicelo>
it calibrates even from fremantle ... it's just fremantle doesn't really use the fuel gauge data :-)
<sicelo>
at least vanilla fremantle doesnt. with cssu + power kernel, the fuel gauge is used
<ac_laptop>
sicelo: is there a way to "copy" the fremantle behavior into leste ?
<sicelo>
not really. the idea is to use the same frameworks everywhere (kernel + upower)
<sicelo>
plus, the fremantle stuff depended on some closed source stuff, bme
<sicelo>
there's really no problem with the fuel gauge in kernel.
<sicelo>
next time you find Leste refuses to boot, but Fremantle boots, show a `cat /sys/class/power_supply/rx51-battery/uevent` from Fremantle
<sicelo>
(correct the path if necessary)
<sicelo>
i guess this will take us one step closer to solving your mystery
<ac_laptop>
sicelo: I couldn't find any /sys/class/power_supply under fremantle
<sicelo>
on my N900 there is, but only rx51-battery
<arno11>
freemangordon: sorry but can't stop mafw, something is wrong, path seems incorrect
<freemangordon>
oh, sorry
<freemangordon>
it is /usr/bin/mafw.sh stop mafw-gst-renderer
<arno11>
i already tried but still not working (?!)
<arno11>
1 min
<freemangordon>
sorry, what does not work?
fab_ has joined #maemo-leste
<freemangordon>
I want logs from mafw-gst-renderer
<freemangordon>
so, you should stop the one started by the system and start manually, with logs enabled
<freemangordon>
G_MESSAGES_DEBUG MAFW_LOG=all /usr/bin/mafw-dbus-wrapper mafw-gst-renderer is the cpmmand to start the renderer
<freemangordon>
so, what does not work?
<arno11>
yep i understand but still not able to run mafw stop, i've checked in the sh file, it's ok but the command is not working
<freemangordon>
what do you mean "not working"?
<freemangordon>
what do you expect to happen?
<freemangordon>
what is the output of ps -ef | grep mafw
<arno11>
whatever i do it says command not found, maybe i'm tired or silly lol
<freemangordon>
do you have mafw-dbus-daemon installed?
<ac_laptop>
sicelo: Maemo 5 version: 20.2010.36-2
<arno11>
freemangordon: yep
<arno11>
let me few min to check what's going on on my device
<freemangordon>
ok
<freemangordon>
but mafw-dbus-daemon has /usr/bin/mafw.sh script
<freemangordon>
ok, seems gst shaders are suboptimal, mpv os way faster using gl vo
<freemangordon>
*is way
<freemangordon>
ttyl
<sicelo>
ac_laptop: ah ok. PR 1.3
<sicelo>
uvos__: there has been another reply, agreeing with the first. i guess ... it is what it is
<ac_laptop>
sicelo: do I need to do something ?
<sicelo>
no
<sicelo>
i guess rx51-battery comes with KP
Twig has joined #maemo-leste
<sicelo>
i think when Leste refuses to boot, but Fremantle does, you can run some hal commands to see what fremantle thinks of your battery, then we can compare. you can look on tmo for useful hal commands. i never really used that :-)
<freemangordon>
ok, seems glimagesink does not support I420 :(
<arno11>
freemangordon: ok i have to go but mafw-gst-renderer is installed but not working and not present in /usr/bin
<freemangordon>
heh
<arno11>
actually it is not running so impossible to stop
<freemangordon>
ok, lets continue tomorrow
<arno11>
and start
<arno11>
ah wait
<arno11>
failed to create opemgl context
<arno11>
*opengl
<arno11>
and other errors...but i have to go. ttyl or tomorrow
<freemangordon>
ok
arno11 has left #maemo-leste [#maemo-leste]
Twig has quit [Remote host closed the connection]
<ac_laptop>
sicelo: tmo ?
<freemangordon>
arno11: oh, your n900 is still on 16bpp? won;t work, you have to switch back to 24bpp
arno11 has joined #maemo-leste
<arno11>
freemangordon: nope the issue occured before switching to 16bpp
<freemangordon>
well, glimagesink does not work on 16bpp
<arno11>
i can try tomorrow if you want, no probs
<arno11>
yes i remember
<freemangordon>
yes, please
<arno11>
well i just need few min to test :) i do it now
arno11 has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
<arno11>
freemangordon: it works again if i start mafw-gst-renderer manually
<arno11>
otherwise same symptoms
<arno11>
in 24bpp ofc
<freemangordon>
mafw-gst-renderer should auto-start
<freemangordon>
lets continue tomorrow
<arno11>
yes ofc but that seems to be the issue
<arno11>
ok gn
<freemangordon>
gn
arno11 has left #maemo-leste [#maemo-leste]
akossh has quit [Ping timeout: 255 seconds]
uvos has joined #maemo-leste
<uvos>
sometimes i wonder how people mange to download currupt files all the time
<uvos>
this has essentally never happend to me...
<uvos>
and to somehow end up with a corrupt file from a git clone, you must have some serious bad luck, how dose that even happen.
<dsc_>
you repel cosmic rays
<uvos>
i would make a joke about my moms basement, but my parents dont have one.
<uvos>
and git checks the files after a clone, so how that happend is a mystery to me
<uvos>
or maybe his hdd/ssd is failing or something
<Wizzup>
ah
<Wizzup>
hmm
<Wizzup>
or he flashed the wrong one somehow
akossh has joined #maemo-leste
<Wizzup>
I am upgrading a d4 I have here and it's consistently failing with a dpkg-divert error on 85 input rules
<Wizzup>
I totally forgot how to fix that
<uvos>
rm the offending file
<uvos>
but it should not happen in the first place...
<Wizzup>
still happens somehow, even with file removed
<uvos>
huh ok
<uvos>
whats the error?
<Wizzup>
dpkg-divert: error: 'diversion of /lib/udev/rules.d/85-input-devices.rules to /lib/udev/rules.d/85-input-devices.rules.leste-orig by leste-config-droid4' clashes with 'diversion of /lib/udev/rules.d/85-input-devices.rules to /lib/udev/rules.d/85-input-devices.rules.leste-orig by leste-config-mapphone'
<Wizzup>
dpkg: error processing package leste-config-droid4 (--configure): installed leste-config-droid4 package post-installation script subprocess returned error exit status 2
<Wizzup>
dpkg: dependency problems prevent configuration of leste-config-mapphone: leste-config-mapphone depends on leste-config-bionic | leste-config-droid4 | leste-config-droid3; however:
<Wizzup>
I should manually run the post inst I guess
<uvos>
ok
<uvos>
so the solution to this
<uvos>
was to remove the divert
<uvos>
theres a tool for this
<uvos>
i dont quite remember what its called
<uvos>
maybe dpkg-divert
<Wizzup>
ah manually remove the diversion?
<uvos>
yeah
<Wizzup>
# dpkg-divert --list | grep input
<Wizzup>
diversion of /lib/udev/rules.d/85-input-devices.rules to /lib/udev/rules.d/85-input-devices.rules.leste-orig by leste-config-mapphone
<Wizzup>
ok
<Wizzup>
ty\
akossh has quit [Ping timeout: 252 seconds]
akossh has joined #maemo-leste
ac_laptop has quit [Ping timeout: 255 seconds]
mrkrisprolls has quit [Remote host closed the connection]