<stan>
uvos: what's the best candidate for a maemo-friendly podcast client? i think gpodder once was maemo-ized, no?
<uvos>
i just use firefox
<uvos>
you can use rss extensions
<uvos>
and play your podcast with ff
<stan>
i think the browser doesn't automatically download the episodes
pere has quit [Read error: Connection reset by peer]
<freemangordon>
stan: uvos is not the best person to ask for maemo specific applications, he has not been a maemo/fremantle user
<uvos>
thats right
<freemangordon>
uvos: hi! Seems there was some progress on libsdl, at least I was left with that impression by reading TMO. hmm?
<uvos>
no
<uvos>
i tried the sdl1.2 -> sdl2 shim
<uvos>
nothing else was done
<freemangordon>
I see
<stan>
major improvement was recent - the half-screen-down shift in fullscreen mode was alleviated
<stan>
I also now get keyboard input in fullscreen mode
<freemangordon>
oh, seems -devel stuff has been moved to -stable
<freemangordon>
that explains it
<stan>
32-bit arm could also benefit from the NEON accelerated SDL, but these additions were taken out of upstream in 2019
<stan>
afaik the reason they were pulled was that some apps were broken on 64-bit arm systems
pere has joined #maemo-leste
Pali has joined #maemo-leste
tvall has quit [Quit: Bridge terminating on SIGTERM]
scops has quit [Quit: Bridge terminating on SIGTERM]
ajr has quit [Quit: Bridge terminating on SIGTERM]
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
venji10[m] has quit [Quit: Bridge terminating on SIGTERM]
asriel_dreemurr has quit [Quit: Bridge terminating on SIGTERM]
<uvos>
tmlind: so the problem is that Voice Playback stream is never considerd active by DAPM
<uvos>
tmlind: when starting a call cpcap_voice_set_tdm_slot ins run but /sys/kernel/debug/asoc/Mapphone\ Audio/cpcap-codec.0/dapm/Voice\ Playback remains "Off" so all downstream widgets remain off too, including the PGA
<uvos>
so snd_soc_dapm_route is fine
<uvos>
but the "Voice Playback" snd_soc_dai_driver remains off in call
<Wizzup>
Danct12: are you on -devel?
Pali has quit [Ping timeout: 252 seconds]
<sicelo>
Danct12: perhaps show us your sources.list (including the HAM sources.list)
<stan>
my use-case is for a home device on ethernet to pull the feeds, then i push those to my portable devices via script
<stan>
running /etc/init.d/droid4-wlanconfig restart when transferring a sd to a new device seemed to help wlan
<uvos>
that dose absoulty nothing except the first time
<uvos>
and it should run on first boot
<uvos>
oh wiht transfering a sd to a new deivce you mean some old install running on a different d4
<stan>
yes, what should i run to re-calibrate wlan
<uvos>
yeah then you must rerun that (or maserati-callibrate directly)
<stan>
ok ty
<stan>
it didn't see my AP. now it does.
<uvos>
yes running the fem parameters from some other deivce is not a good idea
<stan>
that could be a warning on the wiki (to recalibrate wlan if transferring system to another device)
<stan>
how about checking the hw mac address on boot and if changed, recalibrate wlan?
<bencoh>
talking about calibration, should batery calibration happen automagically, or should I run something?
<uvos>
automagically
<stan>
why does maserati-calibrate refuse to be rerun?
<stan>
do i cause harm by removing that check from the script?
<bencoh>
uvos: is there a reason why the battery status applet keeps saying "calibration needed" then?
<uvos>
bencoh: device?
<bencoh>
(I'm not running -devel yet, btw) droid4
<uvos>
it has to see battey low and battery full within one boot
<uvos>
and subsequently it needs to see one of those in the current boot
<uvos>
otherwisese its uncallibrated
<bencoh>
hmm, I think it saw both, but maybe not in that order
<uvos>
stan: yes you cant callibrate without the stock fem parameters
<bencoh>
either that, or it always crashed after low
<uvos>
order dosent matter
<bencoh>
well, then ...
<uvos>
it needs to shutdown cleanly
<uvos>
ofc
<uvos>
otherwise no save
<bencoh>
I'll have to give it another try I guess
<bencoh>
last time it shutdown in my hands it was around ~25% according to upower
<stan>
uvos: but dpkg-reconfigure firmware-ti-connectivity, then running maserati-calibrate could work?
<bencoh>
(~3.3V)
<uvos>
you have to reinstall the firmware
<bencoh>
(I think it reached cutoff during a current peak)
<uvos>
bencoh: if you battery is bad it can be impossible to callibrate
<bencoh>
I replaced it a few years ago and barely used the phone since then
<bencoh>
but it could be
<stan>
i think we need a wiki page for 'how to use an existing maemo-leste sdcard in a different device'
<uvos>
why dont you go improve the wiki
<stan>
i can paste your comments to a page under that title to ensure I do not write anything incorrect
<uvos>
please format it nicely
<uvos>
also put it into the droid4 and bionic page
<uvos>
its device specific
<stan>
ok
<stan>
how do i < uvos> you have to reinstall the firmware
<uvos>
apt reinstall
<stan>
that is difficult without wlan
<uvos>
well you can use usbnet
<uvos>
or download it elsewhere and dpkg -i
<bencoh>
dpkg -i sounds better yeah
<stan>
thanks, then you confirm that apt reinstall ti-firmware-connectivity is necessary and dpkg-reconfigure ti-firmware-connectivity is insufficient?
<uvos>
btw you must reboot after reinstalling
<uvos>
yes
<uvos>
so reinstall the firmware -> reboot -> maserati-callibrate
<stan>
ty again. will setup wiki page
<stan>
btw it looks like there is progress with qualcomm supporting linux. there may be some snapdragon based phones that can do leste now/soon
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 272 seconds]
<Wizzup>
it looks like dsme doesn't actually wait() for anything that it kills, so it might report that it stopped a program too soon
<Wizzup>
I suppose it can't always just wait, depending on the signal it sends, but that's probably why some of our service restarts fail
<Wizzup>
I think this is also ultimately the cause for the resets we are seeing on certain upgrades
<Wizzup>
ke-recv is restarted way too fast, when the previous one is not gone yet, fails to start because of that, and the device reboots after 10 attempts
<Wizzup>
it might make sense to increase the dsme log level as well
<Wizzup>
that would be adding -v 7 invocation in the init script
<Wizzup>
yeah, I cannot think of any other reason that ke-recv would fail to restart, unless it is somehow restarted with some poor env, or when debian is still working on parts it needs
<Wizzup>
the code is straightforward and should log to syslog right away in case of problems
<uvos>
something something ditch dsme :P
<uvos>
(for starting non-session services at least)
<Wizzup>
it's not clear it's dsme, it could be debian restarting it at an unfortunate time
<uvos>
well the point is dont spend to mutch time on this, both ke-recv and dsme we should ditch for various reasons.
<freemangordon>
uvos: please...
<uvos>
no not please
<uvos>
both of these lack technical merit
<uvos>
and dsme is really architecutally broken
<uvos>
(except as a session manager thats ok)
<freemangordon>
you're wasting too much energy spittin on dsme, launcher, whatnot, basically a reverse NIH syndrome I'd say
<freemangordon>
and this is not really useful
<Danct12>
Wizzup, i assume just add devel into source.list should work right?
<Wizzup>
uvos: tbh I don't know how many linux phones support on the fly apt-upgrade, I guess mobian probably does
<freemangordon>
Wizzup: maemo has never supported apt-get upgrade
<freemangordon>
system upgrades shall be done through HAM
<uvos>
freemangordon: we shal keep the underlying system working
<freemangordon>
uvos: sure. so?
<uvos>
freemangordon: many parts of ke-recv dont work on mainline and sfos absorbed ke-recv stuff into mce so we can just copy + paste that so thats hardly reverse NIH
<uvos>
so dont break apt
<freemangordon>
I am not talking about ke-recv in particular, but in general about your attitude:"there is a bug in program X? ah, lets remove it then."
<bencoh>
freemangordon: iirc fremantle broke with *dist-upgrade*, not with upgrade
<uvos>
no upgrade
<uvos>
or rather both
<uvos>
multiple times now
<uvos>
freemangordon: no its allways remove program X
<freemangordon>
bencoh: upgrade was never officially supported either
<uvos>
just when a bug comes i ofc reiterate
<freemangordon>
that's why the PR thingie
<bencoh>
well, I guess I had luck with upgrade then
<bencoh>
anyway, I'd really like to be able to run apt-get upgrade on leste
<buZz>
isnt the appmanager just a frontend for apt really?
<freemangordon>
I said "supported" ;)
<freemangordon>
yes, it is
<bencoh>
freemangordon: yeah :)
<freemangordon>
but is stops lots of things before doing the real upgrade
<freemangordon>
including putting the device offline etc
<freemangordon>
apt will never do that IIUC
<uvos>
wich is just a hack around various bugs really
<Wizzup>
freemangordon: /system/osso/connectivity/srv_provider/[VALUE]/module <-- here VALUE is just a name, right, not a network type?
<freemangordon>
ummm....
<freemangordon>
no idea :)
<Wizzup>
I have a working provider module, but it only works on DUMMY network types, not on WLAN_INFRA, and I don't know why
<Wizzup>
I get this:
<Wizzup>
Jun 29 13:21:08 localhost icd2 0.98[17712]: calling service provider module
<Wizzup>
Jun 29 13:21:08 localhost icd2 0.98[17712]: srv type 'WLAN_INFRA' unknown
<Wizzup>
fro Jun 29 13:21:08 localhost icd2 0.98[17712]: calling service provider module
<bencoh>
freemangordon: tbf it sounds like something that we might be able to fix in an incremental fashion
<Wizzup>
Jun 29 13:21:08 localhost icd2 0.98[17712]: srv type 'WLAN_INFRA' unknown
<uvos>
on pp and mapphones it asks the kernel driver to do it
<Wizzup>
oh that's just rilmodem I guess
<Wizzup>
hm, no
<freemangordon>
and for generating the waceform we use the lib I am talking about :)
<freemangordon>
*waveform
<uvos>
freemangordon: sure on n900
<freemangordon>
on every device
<uvos>
no
<uvos>
you cant
<uvos>
freemangordon: but not directly, through a pa moudle
<freemangordon>
pa module calls the lib to generate the waveform
<uvos>
freemangordon: and ucm /kernel takes care of device differences
<uvos>
you can not send any audio to the modem during a call.
<uvos>
you must ask the modem to insert dtmf
<freemangordon>
uvos: so, who generates dtmf tones?
<uvos>
the kernel exposes this via alsa
<freemangordon>
ah
<freemangordon>
and what about busy tone?
<uvos>
modem
<uvos>
modem dose everything
<freemangordon>
ok, will see
<uvos>
on n900 you have to emulate the stuff the modem dose on pp/mapphones via pulse
<freemangordon>
because I don;t see that happening for IP calls
<uvos>
the interface stays the same for the dialer
<uvos>
freemangordon: right for ip calls different story ofc
<uvos>
the busy tone comes from the voip server tho no?
<uvos>
(not sure)
<freemangordon>
I doubt
<freemangordon>
but not really sure
<uvos>
also note that busy tones are kina a thing of the past
<freemangordon>
why is that
inky has joined #maemo-leste
<uvos>
on lte modern phones just say busy (at least the ones i use)
<freemangordon>
so, what if I am dialing through my car kit?
<freemangordon>
shall I read the messages while driving with 140 km/h?
<uvos>
the device makes a sound
<freemangordon>
called busy tone, no?
<uvos>
though whatever output it is
<uvos>
yeah no
<Wizzup>
is busy the sound before you pick up?
<uvos>
its just the sound of the notification
<freemangordon>
Wizzup: no, what you describe is "ringing" tone
<uvos>
no the busy sound like in a pstn netowrk
<freemangordon>
beep-beep-beep-beeo-...
<Wizzup>
ok
<Wizzup>
well I'll look at packaging it now
<Wizzup>
seems like a concrete thing I can work on
<uvos>
aka it dosent come over the phone conection like in pstn
<uvos>
lte just sends the device a message really
<freemangordon>
and the device shall generate it
<freemangordon>
(the tone)
<uvos>
well they dont anymore
<uvos>
but sure if you want
<freemangordon>
uvos: see my car kit example
<freemangordon>
I can do voice dial and I expect an audible feedback
<uvos>
right and what im saying is that this is not speccaly implmented
<uvos>
its just a notification
<uvos>
and that has a sound
<freemangordon>
well, you said "a thing from the past" :)
<uvos>
right the beep beep beep thing that gsm and ptsn do is a thing of the past
<uvos>
thats what i was getting at
<freemangordon>
if you mean that it does not come from the networks, then ok
<freemangordon>
but the sound as such, I doubt it will be gone soon
<freemangordon>
it doesn't really make sense to remove the most recognized phone tone which was there since the beginning of the telephony just to replace it with some other sound
<freemangordon>
no matter who generates it, beep-beep-... will not go soon IIUC
<uvos>
pff back in the day the nice operator told you the line was in use :P
<freemangordon>
which is very useful when I am in Greece :)
<freemangordon>
or when you are in Bulgaria :p
<Wizzup>
so I think we'll figure this out along the way, no?
<freemangordon>
yeah
<Wizzup>
it feels like we're overly zooming on in this at this point :P
<freemangordon>
Wizzup: it is important from the architectural POV
<freemangordon>
who does what
<freemangordon>
busy tone was just an example
<Wizzup>
yeah, but we have a lot more to figure out I think
<freemangordon>
sure, but this is easy
<freemangordon>
:)
<uvos>
lets get something to work, then get it work well
<freemangordon>
agree, but lets try to have as much as possible from the bigger picture upfront
<freemangordon>
that'll save us some effort in the future
<Wizzup>
we could have a wiki page as scratchpad
<Wizzup>
I think we will probably change a *lot* in sphone
<uvos>
well geting sphone running with everyhing implmented in the modem like on d4 first is a no brainer
<uvos>
since all the code is just sitting there.
<Wizzup>
but it's nice to get audio going, test calls a lot, etc
<Wizzup>
yes
<freemangordon>
very important aspect is how long it takes for the phone to start ringing
<uvos>
why?
<Wizzup>
uvos: any idea what debian section we should use for sphone
<uvos>
no
<freemangordon>
IIRC we have 1.5 second if we want to follow the standards
<uvos>
well the modem dose eveything
<uvos>
im sure it follows standarts
<uvos>
or you mean the reverse
<uvos>
in this case sphone is ram resident
<uvos>
and instant
<freemangordon>
but it takes some time UI to show up and to play "ring-ring" sound
<uvos>
pretty mutch
<uvos>
sphone keeps everything in ram
<freemangordon>
mlock?
<uvos>
no
<freemangordon>
then it can be swapped
<freemangordon>
also, we'll have to renice
<uvos>
sure but just do that with cgroups
<freemangordon>
or implement cgroups
<uvos>
but its just one big binary with everthing that runs as a deamon
<freemangordon>
yeah
<Wizzup>
(like the rtcom-call ui program)
<freemangordon>
actually it uses a big lib as well
<uvos>
and ofono needs to be in ram ofc
<freemangordon>
I guess we'll have to mlock it as well, or somesuch
<uvos>
but jeah just dump everything into a cgroup that keeps it loaded
<freemangordon>
mhm
<uvos>
dbus too
<freemangordon>
mhm
<freemangordon>
and PA
<freemangordon>
we may look at what fremantle is doing
<freemangordon>
though it uses ohm as well
<Wizzup>
uvos: what contains unique-1.0.pc ?
<uvos>
fremantle is pre cgroups tho
<uvos>
i think
<uvos>
Wizzup: unique
<freemangordon>
it uses cgrous as well
<Wizzup>
I thought it was uuid-dev, but it looks like it is not
<uvos>
if you try to unlock it then sees it immidiatly
<uvos>
?
<Wizzup>
startup-pin-query waits for the sim to present before it attempts to unloc kit of course
<Wizzup>
basically the UI will forever show 'no sim present' in tsatu bar
<uvos>
ok yeah i think i see that
<Wizzup>
until you restart ofono or kick it in some way
<uvos>
ok
<uvos>
ok
<uvos>
yes
<Wizzup>
yeah I don't fully understand how ofono on the d4 works yet, but I think it acts on the tty line, and then uses qmi to actually do things
<Wizzup>
so maybe we just need another 'act on this when you see it on tty line' thing
<Wizzup>
(this is an extremely simplified version of my already basic understanding)
<uvos>
maybe
<uvos>
same issue exists on pp?
<uvos>
or no?
<Wizzup>
btw my revision is on that gh issue
<Wizzup>
I don't think that issue exists on the pinephone or on the n900
<tmlind>
uvos: for the voice call issues, not sure i know what we should do.. but i think we should move dts node for cpu_dai_mdm to be a child of the cpu_audio node as the cpu is not involved at all
<tmlind>
uvos: then when voice call is active, it would also keep it's parent active
<Wizzup>
uvos: sphone should be apt-get install'able on the d4 now
<uvos>
tmlind: ok if that would work :P right now i have no clue how soc_snd descides what dai is active
<uvos>
tmlind: i just sent sre a emial with that very question
<tmlind>
uvos: i think right now we completely rely on the set_tdm_slot() hack
<tmlind>
uvos: yeah sre should know, i don't
<uvos>
ok that dosent cause Voice Playback to be active
<uvos>
see debugfs
<tmlind>
yeah ok makes sense
<Wizzup>
uvos: shall I try to hildonize the sphone ui somewhat?
<uvos>
Wizzup: explain?
<Wizzup>
add the atoms, maybe make the text fields larger
<uvos>
Wizzup: besidse using libhildon for the protrait mode what would that entail
<uvos>
ok
<uvos>
sure
<Wizzup>
maybe add context menu to switch between the UI windows
<Wizzup>
(as opposed to various .desktop launchers)
<uvos>
i like various .desktop launcher tbh
<uvos>
and we need them anyhow
<Wizzup>
a .desktop for new sms seems weird to me
<uvos>
so you need to support the xdg intents thing
<Wizzup>
we just have 'Conversations', which is for sms history and also writing new SMS
<uvos>
so if an app wants to send sms: it uses xdg spec to locate the sms program
<uvos>
that program has some magic in its .desktop file to make it work
<uvos>
btw the fact that this suff is missing is a major pain for maemo apps
<Wizzup>
I can skip the context menu if you want, but I think 6 launch icons is not very useful ux, even now, but I also don't feel strongly about it
<Wizzup>
uvos: ok, but let's consider that a separate issue for now
<Wizzup>
how did you get it in portrait mode for your screenshots
<uvos>
i run forcerotation = 1 in hildon transition.ini
<Wizzup>
uvos: also making buttons larger, like 'Send' and 'Cancel' in sms-new
<Wizzup>
uvos: right
<uvos>
that makes everything rotateable
<Wizzup>
did you manage to send a sms yet?
<uvos>
sure everything you propose makes sense
<Wizzup>
I just get 'SMS send action failed'
<uvos>
but i think we should fix the ofono stuff first
<uvos>
no
<uvos>
it uses a ofono interface thats mia
<Wizzup>
ok
<freemangordon>
Wizzup: dialer has theming
<freemangordon>
I think it makes sence to use it
<freemangordon>
*sense
<Wizzup>
I don't know how theming works, but it seems like we can do that later
<uvos>
also why would the dialer want to look diferent than system theme?
<freemangordon>
actually no, look at what I linked ^^^
<uvos>
ok
<uvos>
i dont think this is a big deal
<Wizzup>
I think once we get basic things working, we'll just get PRs for things that are a big deal, and also for things that are not a big deal ;)
<tmlind>
uvos: to clarify why we should move the voice call dts node, the voice call codec should not be a child of omap mcbsp like we have it right now, the voice all is all between cpcap and the modem
<uvos>
tmlind: makes sense
<Wizzup>
uvos: lol the style it uses is also white text on white/gray text input I think :-D
<Wizzup>
like the qt5 stuff, but inverse
<uvos>
tmlind: but i dont know how the dts structure results in dapm deciding what dai to power
<uvos>
really the voice dai needs to be considerd powerd at all times
<uvos>
since it is
<uvos>
and the kernel dose not controll it
<uvos>
tmlind: i sent you the email to sre for referance
<tmlind>
uvos: ok, if the voice call codec is a child in dts of the cpcap voice codec, then it's also a child device in linux meaning voice call code will keep it's parent busy with pm runtime during use
<uvos>
Wizzup: not sure what you mean
<uvos>
Wizzup: i assume you found some theaming issue
<Wizzup>
uvos: on the dialer, when you press the buttons, it renders white text in the text field
<uvos>
ok
<uvos>
maybe he hardcoded the color
<Wizzup>
we'll see
<uvos>
or our themes are broken
<Wizzup>
progress at least
<uvos>
our qt themes are broken
<uvos>
which is why i fixed them at run time
<uvos>
as you mentioned
<tmlind>
good to see some voice call progress :) ttyl
<uvos>
bye
<uvos>
Wizzup: btw to get to the options you have to merge my branch
<uvos>
i added the -c command for it
<Wizzup>
uvos: feel free to merge it
<Wizzup>
bbiab
<uvos>
interestingly you can hotswap in a sim on a d4
<uvos>
motmdm detects this fine
<uvos>
so the android userspace was the limiting factor on this
mardy has quit [Quit: WeeChat 2.8]
inky has joined #maemo-leste
<stan>
what does a power-led blinking 3 times a second mean when connected to usb power?
<stan>
green, about 2.5x/sec
<stan>
echo 800000 > /sys/class/power_supply/usb/input_current_limit made it stop
<uvos>
Wizzup: btw on a diffrent sim now: no change to the bahavior, no grps/umts data
<uvos>
this is on a fresh install + cellular stuff
<uvos>
on devel
<uvos>
so i think you could repo it by just using a fresh image
<Wizzup>
ok
<Wizzup>
maybe I can remove the gconf entries as well
<Wizzup>
going to sleep first :)
tvall has joined #maemo-leste
lexik has quit [Remote host closed the connection]
scops has joined #maemo-leste
venji10[m] has joined #maemo-leste
mighty17[m] has joined #maemo-leste
ajr has joined #maemo-leste
asriel_dreemurr has joined #maemo-leste
lexik has joined #maemo-leste
tvall has quit [Quit: node-irc says goodbye]
scops has quit [Quit: node-irc says goodbye]
venji10[m] has quit [Quit: node-irc says goodbye]
mighty17[m] has quit [Quit: node-irc says goodbye]
ajr has quit [Quit: node-irc says goodbye]
asriel_dreemurr has quit [Quit: node-irc says goodbye]
belcher_ has quit [Read error: Connection reset by peer]
belcher has joined #maemo-leste
tvall has joined #maemo-leste
scops has joined #maemo-leste
mighty17[m] has joined #maemo-leste
ajr has joined #maemo-leste
venji10[m] has joined #maemo-leste
asriel_dreemurr has joined #maemo-leste
xmn has quit [Ping timeout: 240 seconds]
Pali has quit [Ping timeout: 272 seconds]
<stan>
on one device tonight, when usb is plugged-in and battery is full, i get a reboot loop shortly after kexec exits. if i pull the usb power, it boots fine