<Wizzup>
parazyd: when you have a moment pls look at policy-settings-common debian packaging, I don't know how to create the 'current' dir that the rpc/*.spec file makes
<Wizzup>
parazyd: that is in debian/policy-settings-common-text.install
<Wizzup>
parazyd: also the .spec file defines the .dres files for both packages
<Wizzup>
I think the .dres file should go in the -text only
<Wizzup>
also, we need an initscript for ohmd ;)
<Wizzup>
ok, just ohm-plugins-misc remains, I think I will do that another day
akossh has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: just use install ?
<Wizzup>
uvos: where, in rules file??
<uvos>
just postinst
<uvos>
(note im no deb wizzard its just what i would do)
<Wizzup>
yeah
<Wizzup>
well I spent too many hours today doing packaging
<Wizzup>
I'll look at with a fresh mind tomorrow
<Wizzup>
I think once all of this is there, I can try it on the n900
<uvos>
try what exactly?
<uvos>
tha audo setup from nemo?
<Wizzup>
yes, so hopefully we can get most of it to work, whih is:
<Wizzup>
1. volume applet
<Wizzup>
2. policy routing based on system state (hp plugged in, etc)
<Wizzup>
3. call audio routing (if any)
<Wizzup>
and probably loads of other stuff I forget
<uvos>
ok cool
<Wizzup>
I don't think it works *yet) with ucm, so that will be for another time
<uvos>
i gues n900 because the backend stuff is hardcoded for n900 mixers
<Wizzup>
which is why I'd probably start with the n900
<uvos>
ok
<Wizzup>
yeah because there are n900 files from nemo
<Wizzup>
it's how it works in maemo and nemo/mer/sailfish
<uvos>
hmm
<uvos>
seams kinda excessive
<Wizzup>
I can't comment on how it works at all, since I don't know
<Wizzup>
(yet)
<Wizzup>
but it seems pretty likely we'll want to use thos code
<Wizzup>
s/thos/this/
<Wizzup>
that's also why I suggested going the tp route
<uvos>
im still not sure why there is not just several modes with different pa streams associated to them and an app can ask for a stream
<Wizzup>
that might also work
<uvos>
and then depending on the mode the other streams are paused
<Wizzup>
I just looked at some of the policy files just now
<uvos>
and the volume is restored depending on what mode was enterd
<Wizzup>
could be
<Wizzup>
but it has different routing for ip calls than normal calls, etc, so it has to know
<Wizzup>
it can't just be a "phone" property somewhere in pa
<Wizzup>
somewhere in a pa stream
<uvos>
sure so have a 4th stream mode for ip calls
<uvos>
sure so have a 4th stream/mode for ip calls
<uvos>
i think tieing the entire audio setup to some implmentation of a comunications framework is a misstake
<uvos>
less is more here
<uvos>
but thats just imo
<Wizzup>
all I know is that I like what maemo does, and we need something, and sailfish is maemo stack but foss
<Wizzup>
I can't comment on how it works technically really
<uvos>
thats a problem in and of itself
<Wizzup>
but I do know that this is a solid path to get us to something works is proven to work
<uvos>
but ok
<Wizzup>
uvos: I didn't say I wouldn't know at some point
<uvos>
sure
<Wizzup>
uvos: it's like 10+ repos with a lot of prolog and C code
<uvos>
right
<uvos>
another problem in and of itself
<uvos>
:)
<Wizzup>
problems that lead to a solution :p
<uvos>
well its jour department
<sicelo>
"tieing the entire audio setup to some implmentation of a comunications framework" < no. it's not like that. the communications framework is in charge of exactly communications. other audio issues are not handled by tp at all (e.g. music playback)
<uvos>
sicelo: well the audo setup forces the communications framework to be tp forever
<uvos>
you cant swap out tp for ex the telegram-desktop app and place a ip call with that
<Wizzup>
yeah it's just pa doing the audio core, and then ohmd does all the routing policy (through some pa module to be able to do certain things) and then userspace can request audio features
<uvos>
if its just a specal stream for ip calls
<Wizzup>
uvos: that is my guess, it's not clear that that is true
<sicelo>
you can
<uvos>
then you could route the telegram app to use that that stream
<uvos>
and everything works
<Wizzup>
but just for the record our aim *is* to use tp for everything if we can
<uvos>
if pulse reads some special tp proparties and descides what to do based on that
<uvos>
then its a problem
<Wizzup>
no, pulse doesn't do that, ohm does
<Wizzup>
as I understand it
<uvos>
sure pulse ohm whatever
<Wizzup>
I'm sure you could extend to policy if it doesn't do what you want yet
<uvos>
point is the audio streams etc arnt configured correctly if i replace tp with some other app
<Wizzup>
but for example this also deals with emergency calls
<Wizzup>
uvos: well, I can't argue with that point because I do not know if that is the case
<sicelo>
:)
<uvos>
i dont either
<Wizzup>
:D
<uvos>
but that was wat i gatherd from the above
<uvos>
"but just for the record our aim *is* to use tp for everything if we can" maybe but tp wont and cant provide all the features of the native apps
<sicelo>
look, you can run your telegram just fine while the maemo tp stuff is in place.
<Wizzup>
it's 3.5k of prolog code (the basic policies)
<uvos>
so peapole will allways want to use the native apps
<uvos>
sicelo: maybe but when i get a call with the vollume be right?
<sicelo>
Wizzup is talking about the leste stuff. it doesn't prevent use of native anything
<Wizzup>
uvos: I agree it might not offer all the features, but I don't agree that that is what folks want
<Wizzup>
:p
<Wizzup>
uvos: it might be fine if it uses the standard pulseaudio phone property thing
<uvos>
sicelo: will the notifications be on the right volume?
<Wizzup>
we won't know until we have it in place
<uvos>
etc
<sicelo>
we were using linphone on n900 without any issues, even though that was not doing tp
<uvos>
"<Wizzup> uvos: it might be fine if it uses the standard pulseaudio phone property thing" ok but if we can use that and it works why dont we use the modern pa mechansums for exactly this + stream silencing etc instead of the neamo setup
<uvos>
not saying there is no reason
<uvos>
but we should know this kind of thing beforhand...
<Wizzup>
there is no phone that uses plain pa and works sensibly as far as I know
<Wizzup>
but the sailfish stuff does
<Wizzup>
and it's what maemo did
<Wizzup>
pulseaudio itself is not powerful enough to do many of the things we want to be able to do
<uvos>
thats insufficant for me sorry, anyhow im not really helping here, as i say its your department.
<Wizzup>
plus, this setup should give us audio on n900 voice calls
<Wizzup>
uvos: I think we both have waaaay to little knowledge of this to make any determination
<uvos>
right
<dreamer>
(ppst, pipewire kopen?)
<uvos>
shutup
<uvos>
:D
<Wizzup>
I'm simply taking the tested and proven path that also happens to support some of our more sophisted devices wrt audio routing
<uvos>
switching to pupewire just adds more complication we dont need atm :P
<Wizzup>
I think that makes the most sense since we don't have the resources to re-do all the work and it's foss
<uvos>
Wizzup: its fine, i dont have to like it
<Wizzup>
if it doesn't make sense, well then I spent a week packaging and understanding it, not the end of hte world
<uvos>
sure
<Wizzup>
I want to get to a point where it works and we can actually evaluate it
<uvos>
ok
<uvos>
not totaly insane i gues
<Wizzup>
my bet is that it'll actually work out quite ok, and I hope that the main challenge will be supporting ucm
<Wizzup>
plus it'll get us the other maemo bits like volume applet and such
inky has joined #maemo-leste
<Wizzup>
uvos: but that's nice progress @ sphone
inky_ has quit [Ping timeout: 245 seconds]
avoidr has quit [Quit: leaving]
avoidr has joined #maemo-leste
<uvos>
thanks
<Wizzup>
I think some things will come together this year :)
<Wizzup>
it might very well be audio + calls + telepathy/conversations + contacts
<freemangordon>
Wizzup: Re volume applet - someone (me?) shall port it to stream-restore-nemo once we have it
<Wizzup>
freemangordon: we'll see if that's required, it might just be the same
<Wizzup>
or is there still code missing
<uvos>
sms works
<freemangordon>
IIRC the diff between stream-restore and stream-restore2 was that latter supports both absolute and relative volume while former supports absolute only
<uvos>
btw any idea what the point is of declaring a function extern in header
<uvos>
like this "extern int ofono_call_hangup(gchar *path);"
<uvos>
all functions that arnt static are effectively extern no?
<uvos>
am i missing something?
<sicelo>
yes on droid 4 everything works, except USSD. i once made a basic hildon thing in python to handle incoming calls and smses via ofono dbus
<sicelo>
maybe USSD works now. not sure
<uvos>
call audio works only on external speaker
<sicelo>
or it worked, but there was no reply ... can't remember anymore
<uvos>
unles you have hack applied
<uvos>
(like i do)
<sicelo>
i stopped working on the application because it sounded like we only wanted tp
<uvos>
ok
<uvos>
sicelo: also i assume you where replieing to this "sms works"
<uvos>
i ment sms works in sphone
<uvos>
not d4 in general
<Wizzup>
how are you testing?
<sicelo>
yes i was replying to that. sms doesn't work on d4 now?
<uvos>
yes it dose
<uvos>
and i just implmented the interface in sphone
<uvos>
so it works
<uvos>
Wizzup: i sent myself a sms
<sicelo>
actually works on all leste phones
<uvos>
Wizzup: and for calls i call a automatic customer service thing from the provider
<Wizzup>
ah, check
<Wizzup>
uvos: so testing on the d4?
<uvos>
yeah
<uvos>
btw can re fix sapwood-engine-WARNING **: 23:08:56.000: sapwood-theme: Failed to load pixmap file /usr/share/themes/marina/images/qgn_plat_separator_horizontal_paned.png: Failed to connect to sapwood server using `/var/tmp/sapwood-:0': Connection refused
<uvos>
somehow
<uvos>
sphone hits this manny times
<uvos>
makeing its output really hard to read
<Wizzup>
how do you spawn it
<Wizzup>
and as what user
<uvos>
user
<Wizzup>
over ssh?
<uvos>
just ./sphone over ssh yeah
<Wizzup>
try maybe source /etc/profile or something
<Wizzup>
I think it's just missing some env stuff
<uvos>
that dident help
<uvos>
yeah launched on device it dosent happen
<Wizzup>
maybe diff the env from device shell and ssh shell
<uvos>
hmm its not obvious when looking at printenv after sourceing the profile
<uvos>
anyhow ill quit there for today
<uvos>
with some luck ill have sphone working as intended by next weak
<Wizzup>
\o/
<Wizzup>
uvos: when you restart just run 'env | sort > /tmp/1.txt' and diff it