<unic0rn>
devel seems to repeat already sent sms after reboot
<unic0rn>
sent one test message from conversations earlier in the day, just got it again after reboot
<Wizzup>
this is not specific to devel but rather a modem kernel or userspace issue that happens sometimes
<Wizzup>
I don't get it very often at all but sometimes it does happen
Daanct12 has joined #maemo-leste
<unic0rn>
now this is interesting
<unic0rn>
noticed that when I connect d4 to my chromebook to charge it, on d4's side usb0 shows up as a network interface
<unic0rn>
figured "why bother with wifi when this will be faster"
<unic0rn>
and indeed it works, I have both wifi connection to the internet and local usb ethernet to phone
<Wizzup>
yes, this works fine, but when the droid4 is fully charged it will start dropping the usb0 connection every 30 seconds or so, jfyi
<Wizzup>
bedtime for me, almost 3am
<Wizzup>
tomorrow I hope to fix the audio issue, and maybe look at either volume status applet for call volume or perhaps improve the notifications some depending on fmg's progress
<unic0rn>
yeah, 2:40am here as well
_whitelogger has quit [Remote host closed the connection]
_whitelogger_ has joined #maemo-leste
nmdv has joined #maemo-leste
DADFP has quit [Quit: Leaving]
nmdv has quit [Ping timeout: 264 seconds]
Daanct12 has quit [Quit: WeeChat 4.3.0]
Juest has quit [Ping timeout: 255 seconds]
Juest has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<unic0rn>
question, is there a fine-tuned cpufreq configuration for d4 in leste, or is it just using default ondemand?
<unic0rn>
I'm trying https://pastebin.com/Va8adZXM - it's a bunch of settings I've defined by trial and error on my old amd A8-7600 desktop
<unic0rn>
from my experience on that cpu at least, by default ondemand ramps up way too fast, which is supposed to be nice for performance, but the cost is in the loss of power efficiency
<unic0rn>
same is likely true for other cpus. back then I was checking it with software video decode, because the goal was to avoid having an audible fan noise while watching movies
<unic0rn>
ondemand caused cpu frequency to spike all over the place, it was constantly up and down
<unic0rn>
my conservative settings settle down on lower frequency - it's going up a bit slower to avoid overshooting the required by load frequency, but then it goes down slower as well.
<unic0rn>
the result was more or less constant cpu frequency during video playback, lower than the average generated by ondemand
<unic0rn>
those settings were defined few years ago, but I assume nothing has changed in that governor's settings
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
fab__ has joined #maemo-leste
ceene has joined #maemo-leste
fab__ has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 255 seconds]
plazmonii has joined #maemo-leste
fab__ has joined #maemo-leste
akossh has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<freemangordon>
unic0rn: I don;t think we use any custom cpufreq config
<freemangordon>
maybe use your tuned config and report if there is a change in battery life compared to stock ondemand
<unic0rn>
I am using it, but my usage is irregular and battery is weak, so it's hard to tell, other than perhaps checking how long it'll survive on idle - but I don't really let it idle for too long
<freemangordon>
idle is not really an issue on leste
<freemangordon>
while usage is
<gnarface>
hmmm... you know, i recently observed on some of my other ARM hardware that default ondemand behavior is all over the board even at idle, which is distinctly different from the behavior i've observed on amd64 hardware
<unic0rn>
then it should help, depending how heavy the usage is
<gnarface>
what i'm saying, unic0rn, it it may not be an issue specific to just your d4
<unic0rn>
default ondemand according to kernel docs, just goes up to max freq as soon as there's load
<unic0rn>
which is, in case of a phone, not exactly optimal
<gnarface>
oh, to be clear, i never caught it doing that correctly either, without heavy tuning, even on amd64
<freemangordon>
well, I think we'll appreciate custom cpufreq tunnings :)
<gnarface>
what actually does that right, is powernowd (using the userspace governor)
<gnarface>
but that's what i actually want out of it
<unic0rn>
the way I tested the settings above was simple, video playback with sudden bitrate spikes
<gnarface>
what i've observed it doing on ARM hardware though, is fluttering around amongst multiple speeds at apparently sub-second frequency
<gnarface>
...which isn't useful
<freemangordon>
ugh
<unic0rn>
default conservative wasn't keeping up with the load, leading to dropped frames, so I've tuned it so that there was no performance loss vs ondemand, but the clocks were more stable and lower
<unic0rn>
gnarface: oh yes, those changes are VERY fast
<gnarface>
i don't think it's specific to the d4, or even to maemo-leste, i think it's something suspect in the upstream kernel ondemand implementation, and where i tested it at least, schedutil was doing it too, but i haven't tested kernels older than 6.1 to see if it was always this way
<unic0rn>
ondemand just has adhd
<unic0rn>
it was that way on 5.x kernels in manjaro iirc
<gnarface>
what i'm wondering is if it's different for ARM hardware, since i haven't tested it on the x86 ones either
<gnarface>
...not since before 6.1 anyway
<unic0rn>
it was that way on a8-7600 for me, desktop apu from amd
<gnarface>
hmmm
<unic0rn>
so yeah, it's just the way ondemand is
<gnarface>
or maybe newer hardware in general? the other thing is, most my hardware is pretty old....
<unic0rn>
it's jumping all over the place
<unic0rn>
a8-7600 is old
<unic0rn>
that's kaveri, waaaaay before ryzen
<gnarface>
not doing it on my FX or phenom chips
<gnarface>
though they have a different issue where they kinda individually drift a few mhz off the target speed setting...
<gnarface>
the actual state changes don't "flutter"
<unic0rn>
older amds were a mess
<gnarface>
i think that's actually an artifact of some power saving thing i've got enabled in the bios...
<unic0rn>
cool'n'quiet?
<unic0rn>
as in, "we're just frying those eggs, no need to burn them in 5 seconds"
<gnarface>
no, unrelated to the fans
<gnarface>
"C1e" or "c1E" or something?
<gnarface>
the capitalization might matter
<unic0rn>
could be, no idea why it would affect frequencies
<unic0rn>
but then, if the hardware is old, I would check voltages
<unic0rn>
if they're not stable... well. things may happen
System_Error has quit [Ping timeout: 260 seconds]
<gnarface>
anyway, on the ARM hardware though, (pine64+ A64 SoC boards but you can probably reproduce this on a pinephone) i was seeing the current frequency feathering around among i think the bottom 3 speeds even while at basically 0% load, which seems... wrong
<unic0rn>
with ondemand?
<gnarface>
yea, default settings. not sure if that's related to what you're seeing
<unic0rn>
I'm surprised it didn't go to max
<gnarface>
i'm not using systemd
<unic0rn>
lol
<gnarface>
:D
<unic0rn>
also, perhaps I wasn't clear. I wasn't really checking the frequency spikes on my d4, although when issuing random frequency info or anything, current clock was usually higher than minimum at idle
<unic0rn>
I was just copying some stuff to d4, including various scripts, and I found those custom settings
<unic0rn>
checked what leste is using, added the script to rc.local and that's it. figured it won't hurt and should actually help
<unic0rn>
since ondemand is usually going bonkers with the clocks
<unic0rn>
on any platform
<unic0rn>
but as I've said, from my experience on that cpu - meaning a8-7600
<unic0rn>
I would be surprised if omap behaves any better though
<freemangordon>
Wizzup: ok, gabble looks for jabber:x:delay, which is superseeded by xep 203
System_Error has joined #maemo-leste
pere has quit [Ping timeout: 268 seconds]
plazmonii has quit [Ping timeout: 250 seconds]
pere has joined #maemo-leste
<Wizzup>
freemangordon: check
<Wizzup>
freemangordon: I think with message markers we might not even need xep 203 , do we?
<Wizzup>
does anyone else find the droid4 vibration too strong in sound?
<Wizzup>
funnily enough the hw a vibrates very different from the hw b it seems
<Wizzup>
lowering the speed from 180 to 80 made it a bit better for me IMO
<freemangordon>
Wizzup: inxep 203 it is urn:xmpp:delay
<freemangordon>
Wizzup: so, we are becoming upstream for tp-gabble?
<Wizzup>
freemangordon: I think we should make contact with the mailing list
<Wizzup>
nlnet also said they'd appreciate it if we are a bit more public about or telepathy fixing efforts
<Wizzup>
it might also help with other distros keeping it around
<Wizzup>
I think gentoo was trying to remove certain telepathy related packages due to lack of maintenance
<Wizzup>
freemangordon: so the modernxmpp website, I think this is really worth checking
<Wizzup>
as it says there's over 500 XEPs and many are no longer in use
<Wizzup>
it would be sensible to look at some modern clients (prosody, dino, conversations on android etc) and see which ones they implement
<Wizzup>
there's probably also a lot of code already out there, for example for pidgin there are many plugins which do say omemo or mam and they're actually suprisingly few lines of code
<Wizzup>
I would suggest to look at how much has changed and estimate just how long it will take to reimplement all of it, and for what :)
<freemangordon>
how to know what has changed for 3 years?
<Wizzup>
not three years
<Wizzup>
It was already super lagging behind in 2014
<Wizzup>
now it's 2024
<freemangordon>
hmm
<Wizzup>
it's not about when there was last a commit, but no features were adding, no new XEPs, since forever
<freemangordon>
so, the plan should be to drop wocky?
<freemangordon>
or to drop gabble, or?
<Wizzup>
or bring it up to date with all modern xmpp xep's, per the website I linked earlier and by looking at what the various clients/lbis implement (qxmpp, kaidan, dino, profanity-im)
<freemangordon>
ok, do we want *everything* implemented?
<Wizzup>
well there's (1) upgrade wocky (2) switch gabble to different lib than wocky and bring it up to date otherwise (3) make a new cm like tp gabble with a new lib
<freemangordon>
(3) would be a nightmare
<Wizzup>
well we don't need everything implement now, but I think that multi device, message archives and omemo are all pretty standard now
<freemangordon>
so I would try with 1
<Wizzup>
I think we just need to take stock of how much work each option would be before deciding
<freemangordon>
implementing couple of missing functionalities should be easier than starting from scratch
<Wizzup>
just keep in mind that many of these modern xmpp libraries get funding for years and continue to work on it, so it's not a small undertaking
<freemangordon>
hmm, ok
<Wizzup>
I think I disagree but I don't think either of us have done the necessary homework :P
<freemangordon>
right
<freemangordon>
so, do we have library to use instead of wocky?
<freemangordon>
not qt based, please
<Wizzup>
well this is what I was trying to research above
<freemangordon>
right
<freemangordon>
hmm, actually, if it does not link to QApplication/GUI, it should not ba that bad
<Wizzup>
yes, it is not bad
<Wizzup>
it looks like dino is vala, so not C
* freemangordon
reconsiders
<Wizzup>
prosody-im is C but they don't have a library, their xmpp implementation is in-line
<Wizzup>
my current preference would be looking at qxmpp since it seems to have nice looking docs and enough abstractions that it could match tp nicely
<Wizzup>
yes that is a good option too
<Wizzup>
but then you'd have to figure out how to link against it I guess
<Wizzup>
profanity will probably lack all things for audio and video calls, since it's a ncurses client
<freemangordon>
what would be the issue?
<freemangordon>
(linking)
<Wizzup>
I mean you could copy-paste the code but then how to do keep up to date
<freemangordon>
ah
<Wizzup>
or git submodule it somehow link against the objects
<freemangordon>
no, that should be submodule
<Wizzup>
but there's no 'libprofanity' as far as I can see
<freemangordon>
so, you think qxmpp?
<Wizzup>
I think so, but I don't know if that would be (2) or (3), I guess probably (3), which is, eh, but maybe better
<freemangordon>
no, better 2
<freemangordon>
well, depends who implements it
<Wizzup>
so would you mix C and C++ and glib and qt them in the CM?
<freemangordon>
if it is me, I would go for 2
<Wizzup>
ok
<freemangordon>
what is the issue?
<freemangordon>
(mixing)
<freemangordon>
qt uses glib
<Wizzup>
not a lot I suppose, just convoluted code wise
<Wizzup>
O'
<Wizzup>
I'm fine either way, but qxmpp seems to support all modern stuff, likely will be maintain going forward, and the APIs/abstractions seem nice
<Wizzup>
whether we use telepathyqt connection manager or glib connection manager I don't really care about so much
<Wizzup>
I just saw that gabble is 75k lines of code
<freemangordon>
hmm, maybe creating tp-qxmpp is really a better option
<freemangordon>
Wizzup: but that includes wocky
<Wizzup>
oh it does? ok, I just did wc -l src/*.c
<freemangordon>
in lib
<Wizzup>
ah I see, wocky is just copied into it
<freemangordon>
mhm
<Wizzup>
well, anyway, so I do think (3) is easier, but maybe we need to do a bit of exploration to find out
<Wizzup>
I need to water the plants :)
<freemangordon>
:)
<Wizzup>
one thing, in regards to a main to send to tp, what shall I say
<Wizzup>
like, hi, ewe're here, we're using tp and fixing things, can we get acess to maintain things? or?
<freemangordon>
something like
<freemangordon>
or, is there maintainer, we want to colaborate, dunno
<Wizzup>
ok
<freemangordon>
we already did some things, (insert link here) ...
<freemangordon>
Wizzup: but, until we do something better, I think to fix our gabble for at least simple things
<freemangordon>
like backscroll etc
<Wizzup>
ok
<Wizzup>
freemangordon: anyone I should CC?
<Wizzup>
for TP
<freemangordon>
...
<Wizzup>
I sent you a draft
<freemangordon>
no idea
<Wizzup>
ok
<freemangordon>
maybe pavel?
<Wizzup>
I could add random contributors
<Wizzup>
from TP I mean
<freemangordon>
yeah, mail looks fine to me
<Wizzup>
maybe just check the draft and if it's ok I will send it
<Wizzup>
ok
<Wizzup>
then I'll just mail more people if nobod responds
<Wizzup>
(later)
<freemangordon>
I think cc-in Palvel is good idea
<freemangordon>
*cc-ing
<Wizzup>
too late :)
<Wizzup>
but I can send him a copy
<sicelo>
i don't think pavel is interested in TP
<Wizzup>
probably not, but I emailed him anyway, he might be interested in our recent maemo developments
<sicelo>
however, i wonder if you could also have included debian's tp team
<Wizzup>
I think they should be on that list, but if there's no reply in a few days I will reply to the mail, assuming it goes through the ML, and include them in a reply
<sicelo>
sure. i was looking at debian's ofono package recently, and it's 'housed' by the tp team.
<Wizzup>
right
<Wizzup>
arno11: sorry I forgot about pcsx yesterday, let's take a look today
Madda has quit [Ping timeout: 264 seconds]
Madda has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
arno11 has joined #maemo-leste
<arno11>
Wizzup: vibration is really too strong on N900 too.
<arno11>
for pcsx, no rush
<arno11>
but once pcsx is ok i can work on pierogi (easy stuff) and Drnoksnes (more complicated)
pere has joined #maemo-leste
<Wizzup>
yeah I think we just reduce the power in mce.ini
<arno11>
ok
<dsc_>
arno11: re: yt-dlp, do you output in a certain resolution (ffmpeg pass?)
<dsc_>
can imagine you dont want 4k on the n900
<arno11>
yeah ofc i use 360p max
<Wizzup>
already got one reply on my TP mail :)
<sicelo>
guess they replied to you directly? i don't see it in ML (even though i received your initial mail)
<Wizzup>
yes
<Wizzup>
btw, it might be worth trying wpa_supplicant from bullseye-backports to see if the host mode works again
fab__ has quit [Quit: fab__]
xmn has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
<sicelo>
so what are they saying? TP alive? :-)
<Wizzup>
just copying the messages to some other folks
ceene has quit [Remote host closed the connection]
nmdv has joined #maemo-leste
arno11 has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
parazyd has quit [Ping timeout: 240 seconds]
parazyd has joined #maemo-leste
<freemangordon>
Wizzup: I guess I'll have to implement more smart own account matching
<freemangordon>
but for now should be ok
parazyd has quit [Ping timeout: 240 seconds]
<Wizzup>
ok
parazyd has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Ping timeout: 256 seconds]
fmg_d4 has joined #maemo-leste
parazyd has quit [Ping timeout: 268 seconds]
parazyd has joined #maemo-leste
ac_laptop has joined #maemo-leste
Livio has joined #maemo-leste
fmg_d4 has quit [Ping timeout: 264 seconds]
Livio has quit [Ping timeout: 256 seconds]
parazyd has quit [Ping timeout: 264 seconds]
parazyd has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
dsc_: btw for 360p stream, i usually run 'python3 yt-dlp --get-url -f 18 https//www.youtube.com/watch?v=blablabla' and then copy the link provided directly in smplayer (and disable compo + fullscreen)
<dsc_>
ah cool
<arno11>
a direct pipe works but a way slower
<arno11>
available resolution can be checked with -F command
<arno11>
this python tool is a bit slow to start but really powerful
<dsc_>
i know yt-dlp pretty well, was just wondering how you were using it
<arno11>
ok :P
antranigv has joined #maemo-leste
antranigv has quit [Remote host closed the connection]