<uvos>
then you have a dummy setup that you can check with pactl to see if you stuff on top set the right thing
<Wizzup>
ok
mardy_2nd has joined #maemo-leste
<freemangordon>
I really hope UCM is smart enough to be able to handle all the use cases
<freemangordon>
so far it has a deficiency that you cannot attach user data to profile (or whatever it was called)
<freemangordon>
maybe we shall patch that
<freemangordon>
uvos: do you know if ^^ is possible already
Pali has joined #maemo-leste
<freemangordon>
use case is volume applet, you have more steps on volume slider when using speakers as an output compared to when you use FMTX, for example
<uvos>
ucm is not smart, and thats not its job
<uvos>
its job it so that there is one mixer controll from alsa for pulse to worry about for eatch fucntion, not $(20-RANDOM-CONTROLS) that variy by device
<Wizzup>
freemangordon: afaik UCM can help us switch the mixer values for us, but the policy we still have to do
<Wizzup>
i.e. when do we decide to switch UCM profile, and to what do we switch it
<Wizzup>
it's just easier to use than fiddling with alsamixer values
<Wizzup>
freemangordon: I think for volume applet this can be done with pulse
<Wizzup>
unless I'm confused?
lightbri1ger has quit [Changing host]
lightbri1ger has joined #maemo-leste
lightbri1ger is now known as lightbringer
Kabouik has joined #maemo-leste
Kabouik has quit [Changing host]
Twig has joined #maemo-leste
uvos has quit [Ping timeout: 240 seconds]
Twiggy has joined #maemo-leste
Twig has quit [Read error: Connection reset by peer]
mardy_2nd has quit [Quit: WeeChat 2.8]
Twiggy has quit [Read error: Connection reset by peer]
<freemangordon>
so, we have a "Master volume" in PA, and we have a list attached to it with 10 (for example) volume levels that define 10 steps in volume slider
<Wizzup>
and we just need to instrument pulseaudio in various ways, first of all to have separate 'groups' of applications (iiuc), music playing ones and phone calls, and also attach tags
<Wizzup>
that is entirely separate from corking streams, and actually having certain switches change at the right moment
<Wizzup>
assuming we have a proper UCM and pulseaudio understands "Call Mode" (as it does on the d4), we can utility pulseaudio-policy-enforcement to set the right PA modules depending on system state
<Wizzup>
this is really as far as my understanding goes, I plan to understand more this week
<freemangordon>
Wizzup: what I am discussing is on top of that
<Wizzup>
ok
<freemangordon>
look how volume applet initializes
<bencoh>
freemangordon: wasn't xpolicy directly related to pulseaudio?
<Wizzup>
yes, this is what I mean with 17:54 < Wizzup> and we just need to instrument pulseaudio in various ways, first of all to have separate 'groups' of applications (iiuc), music playing ones and phone calls, and also attach tags
<freemangordon>
ok, lets call those properties 'tags' if you wish
<Wizzup>
It's quite some work to pull that apart and reproduce it proper, but that's what I intend to do this week
<Wizzup>
to port the fremantle audio config (minus enforcement) so that volume applet can work
<Wizzup>
that's basically what I plan to do
<Wizzup>
and then hopefully alarms will also work
<freemangordon>
great!
<freemangordon>
LMK if you need help
<Wizzup>
*nod*
<freemangordon>
though I am on osso-abook
<bencoh>
Wizzup: you might want to check /etc/pulse/xpolicy.conf on fremantle
<freemangordon>
bencoh: and there is more to that, in /var/lib IIRC
<Wizzup>
bencoh: I have a tar of all the files on my ssd I think
<bencoh>
/var/lib/pulse{,-nokia} yeah
<freemangordon>
so, if I get that right, each sink has 2 user-defined properties that are used by volume applet
<freemangordon>
first is for volume steps when not in call, the second - when in call
<Wizzup>
I believe so
<freemangordon>
that's what we shall somehow recreate, at least in terms of volume applet
<bencoh>
at least that's how it behaves from a user pov
<freemangordon>
not only from user POV, see the code
<freemangordon>
so, we ahve a properties, which are list of volumes in dB
<freemangordon>
and when a sink becomes active (?) the applet uses those properties to tune it's slider number of steps and to set the output volume based on the current step
<freemangordon>
taking in consideration if we are n call or not
<Wizzup>
yes
<freemangordon>
*in
<freemangordon>
the particular values for n900 are in /var/lib/... IIRC
<bencoh>
freemangordon: wait, don't tell me the status applet is actually the one changing the output volume once the call stats
<bencoh>
starts*
<freemangordon>
yes, it is
<freemangordon>
IIUC
<bencoh>
:'(
<Wizzup>
bencoh: what should do it in your opinion?
<bencoh>
I dunno, but definitely not some UI element
<freemangordon>
why is that an issue?
<freemangordon>
it is not really UI element
<bencoh>
from a logical pov, it sounds kinda ... broken
<freemangordon>
UI is just on top of its core functionality
<freemangordon>
and its core functionality is to change the volume :p
<Wizzup>
bencoh: I mean, something has to map keyboard key to pulse actio
<Wizzup>
n
<Wizzup>
and it's not pulse that does this
<bencoh>
I don't expect status applet to take any active part in the actual system, only to allow me to interact with it
<bencoh>
but ... meh
<Wizzup>
mhm
<freemangordon>
bencoh: and who is supposed to do the actual volume change?
<freemangordon>
shall we teach PA on calls?
<bencoh>
no idea, tbf
<freemangordon>
my stance is - Nokia did it like that, unless we have some strong evidence it can be done better, lets not reinvent the wheel :)
<bencoh>
I'd have expected telepathy / the telephony framework / the phone app to notify pulseaudio and switch output/volume, but ...
<freemangordon>
oh I'd say this is even worse
<bencoh>
freemangordon: yeah, I'm not really arguing about what we should do tbh
<freemangordon>
application should not control things like volume IMO
<bencoh>
but I think we had a similar discussion back at some point (when you RE-ed maybe? or it was another piece of software)
<freemangordon>
could be
<freemangordon>
don;t really remember
<bencoh>
me neither, until now
<bencoh>
anyway, I don't really have a better idea for now, so ...
<bencoh>
:)
<freemangordon>
:)
<bencoh>
is pulseaudio in the same state than back in fremantle days? or does it have new abstractions we could benefit from?
<bencoh>
it's funny how they really patched the whole ecosystem to make that phone work :)
<bencoh>
(and I have to admit it's a great piece of work in the end)
<freemangordon>
:)
<uvos>
the patches are partially very hacky tho
<freemangordon>
Wizzup: maybe we will need that too
<uvos>
not that i blame them
<bencoh>
uvos: yeah, but still :)
<uvos>
they where loosing the war with android and with the symbian /wimo devision
<uvos>
so im sure they where under duress
<freemangordon>
the war with android was not even started by then
<sicelo>
actually maemo had nothing to do with android :)
<sicelo>
it's symbian that was fighting
<uvos>
well yes it did
<freemangordon>
there was simply no android :)
<uvos>
android was around
<uvos>
so it was a competitor
<bencoh>
it was more symbian/iOS back then; android was around, but still pretty infant
<freemangordon>
mhm
<uvos>
the d1 came out around the same time
<uvos>
and was a huge sucess sales wise
<freemangordon>
2009?
<uvos>
yes
<bencoh>
"with the first commercial Android device, the HTC Dream, being launched in September 2008"
<sicelo>
uvos: seriously. maemo fremantle had nothing to do with android. in fact, it was even struggling to make a case against symbian itself, let alone android. anyway
<freemangordon>
because the code in question was *finished* 2009
<uvos>
sure
<bencoh>
yeah, android was an infant :)
<uvos>
sure ok but "compettion"
<uvos>
the iphone for sure
<freemangordon>
not really
<uvos>
come one
<freemangordon>
it was internal competition in Nokia
<uvos>
the fremantle ui apes the iphone
<freemangordon>
with symbian
<bencoh>
iphone 3/3gs was its direct "competitor" (of at all)
<bencoh>
(if* at all)
<Wizzup>
yeah nokia messed up internally a lot as well
<freemangordon>
well, n900 was anno9unced as iphone killer :D
<freemangordon>
*announced
<freemangordon>
which it was really back then
<bencoh>
honestly, it might have been, if not for ... pretty much everything, apart from the technical aspect
<uvos>
freemangordon: practicaly maybe
<uvos>
comertially? no
<freemangordon>
despite that, I know lots of wealthy people who bought n900 back then
<uvos>
sure
<freemangordon>
but it was Nokia who screw it
<bencoh>
same, and I still come across people that tell me they had one at some point
<freemangordon>
mhm
<uvos>
but no doubt of the big phones sold in 2009: the d1 the n900 and the iphone
<freemangordon>
not technical guys
<uvos>
the n900 did worst
<Wizzup>
I had people tell me they had the phone way back when.... but they saw my d4 with leste and though it was n900 with fremantle ;)
<freemangordon>
:D
<bencoh>
haha
<uvos>
he
<freemangordon>
ok, I am back to osso-abook
<bencoh>
:)
crab has joined #maemo-leste
crab has quit [Quit: WeeChat 2.3]
crab has joined #maemo-leste
crab has quit [Client Quit]
crab has joined #maemo-leste
<uvos>
Wizzup: did you change anything with qt5
<uvos>
or the calculator app?
<uvos>
btw im very sure that fremantle takes inspiration from android 1.0 i mean look at os2008 and fremantle and a1.0
<uvos>
but its not important
<uvos>
anyhow calculator app: theming is broken again
<uvos>
the text box is white now for some reason
<uvos>
so no input can be seen
<Wizzup>
uvos: I don't think I changed anything
<uvos>
hmm
<uvos>
i dident either local
<uvos>
*localy
<uvos>
the hildon preeview is even still right
<uvos>
coult you check on your device?
<Wizzup>
yeah same for me
<Wizzup>
interesting
<uvos>
hmm wierd
<Wizzup>
maybe some pkg was promoted or something
<uvos>
promoted?
<uvos>
by debian you mean
<uvos>
(as we are on devel for us ofc)
<uvos>
yeah maby a qt5 change in debian caused this
<stan>
calculator could be a candidate to add to default image
<stan>
not in the device i have running now. maybe in the newer image
<uvos>
stan: if it dident install with updateing
<uvos>
you dont have the metapackage installed
<uvos>
which is bad
<stan>
it's in the newer image, sorry
<uvos>
it should be in _any_ image
<uvos>
if you updated it half way recently
<uvos>
if its not your image is broken (its missing the metapackage at least)
<Wizzup>
you probably just removed it
<uvos>
the metapackage also dissapeard on an update for me too btw
<uvos>
i think something was conflicting at some point
<uvos>
that was very long ago tho
n900 has quit [Quit: WeeChat 2.3]
n900 has joined #maemo-leste
adc has quit [*.net *.split]
mardy has quit [*.net *.split]
joerg has quit [*.net *.split]
stan has quit [*.net *.split]
lel has quit [*.net *.split]
mrgeanie has quit [*.net *.split]
StephanvanSchaik has quit [*.net *.split]
linmob has quit [*.net *.split]
The_Niz has quit [*.net *.split]
peetah has quit [*.net *.split]
ikmaak has quit [*.net *.split]
RedW has quit [*.net *.split]
joerg has joined #maemo-leste
adc has joined #maemo-leste
stan has joined #maemo-leste
StephanvanSchaik has joined #maemo-leste
peetah has joined #maemo-leste
mrgeanie has joined #maemo-leste
RedW has joined #maemo-leste
mardy has joined #maemo-leste
The_Niz has joined #maemo-leste
lel has joined #maemo-leste
ikmaak has joined #maemo-leste
linmob has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
<stan>
is there a forseeable way we could set system languages we want supported on our device, then prevent apt from downloading every translation available? e.g. 71-osso-pdf-viewer-l10n-zhhk 72-osso-pdf-viewer-l10n-zhcn
<Wizzup>
no
<uvos>
tmlind: any idea what the difference between mbmloader_hs.bin and mbmloader_ns.bin is?