<freemangordon>
and yes, looks like it is packaged properly
<freemangordon>
but, you need to create xorg.conf for it
<freemangordon>
see pastebin ^^^
<mighty17[m]>
Will try, tysm!
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
_inky has quit [Ping timeout: 240 seconds]
System_Error has quit [Ping timeout: 276 seconds]
_inky has joined #maemo-leste
R0b0t1`` has joined #maemo-leste
akossh has joined #maemo-leste
uvos has joined #maemo-leste
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
asriel has joined #maemo-leste
<uvos>
freemangordon: i dident remove it
<uvos>
freemangordon: i did make it a config option
<mighty17[m]>
welp :(
<mighty17[m]>
<freemangordon> "but, you need to create xorg...." <- `[ 101.485] (EE) Failed to load /usr/lib/xorg/modules/drivers/omap_drv.so: Error relocating /usr/lib/xorg/modules/drivers/omap_drv.so: InitPowerVREXA: symbol not found`
<uvos>
must not be linked to pvr um
<freemangordon>
uvos: no, that's another issue
<freemangordon>
InitPowerVREXA is in pvr EXA module
<freemangordon>
mighty17[m]: could you move omap_pvr_drv.so out of modules directory and retry?
<mighty17[m]>
as in?
<freemangordon>
mv omap_pvr_drv.so /root for example
<freemangordon>
move it to another dir
<mighty17[m]>
oh ok
<Wizzup>
mighty17[m]: why revert `Depend on sgx-ddk-um-dev ` ? just make sure you have the pc file
<Wizzup>
I made one
<mighty17[m]>
Wizzup: i dont have it on alpine
<Wizzup>
then make it!
<Wizzup>
otherwise things won't work
<Wizzup>
you need -everything-
<Wizzup>
I am talking about the .pc file
<Wizzup>
but if you think it's working, then ignore, just waking up
<Wizzup>
it just doesn't seem like a good idea to remove stuff from autotools that we add
<Wizzup>
they aren't just checks, they also translate to CFLAGS and linker actions
<freemangordon>
for some reason ld.so on alpine tries to resolve symbols on loading
<Wizzup>
ok, then I'll let fmg handle it because I think it's much better to build it the way tested it
<mighty17[m]>
musl issues?
<freemangordon>
yeah
<mighty17[m]>
ugh.. :/
<Wizzup>
also reverting the header commit is a bad idea, now you might even have wrong version
<mighty17[m]>
Wizzup: well from where can i get header files then?
<mighty17[m]>
omap5-sgx-ddk-um-linux ?
<freemangordon>
Wizzup: for sure this shall be fixe, but that's not the issue he is hitting now
<freemangordon>
mighty17[m]: from our -dev package
<mighty17[m]>
me has to package that for alpine
<mighty17[m]>
but even with that, this issue would come
<Wizzup>
yes, we worked hard to package it all properly so that people could just mimick the packaging and make it all work
<mighty17[m]>
can we just define InitPowerVREXA to 0 or smth garbage?
* mighty17[m]
> <@Wizzup:libera.chat> yes, we worked hard to package it all properly so that people could just mimick the packaging and make it all work
* mighty17[m]
has no clue how deb works
<freemangordon>
mighty17[m]: no
<Wizzup>
that's the nice thing about it: it's self contained so people can just do their packaging stuff and as long as it's the same, they know they did it right
<freemangordon>
this is dynamic linker's job to resolve symbols when they are needed
<Wizzup>
mighty17[m]: I also don't know how APKBUILDs work or other .spec files for rpm but I had no trouble figuring them out
* Wizzup
afk
<freemangordon>
and this seems to be broken, somehow
<mighty17[m]>
looks like we should ask in #alpine?
<uvos>
Wizzup: also move /usr/share/maemo-statusmenu-volume/sinks.ini to leste-config when able
System_Error has joined #maemo-leste
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 268 seconds]
<Wizzup>
uvos: right
<Wizzup>
uvos: so pkill status should work?
<Wizzup>
ah ok required mce restart
<Wizzup>
lol it looks tiny on droid4 :p
<Wizzup>
uvos: it looks like the volume for the hp and speaker are shared
<uvos>
yes they share a volume in ucm
<Wizzup>
they don't share the volume in actual playback
<uvos>
only different ucm profiles have sperate volume
<Wizzup>
if I unplug the volume is clearly much louder
<Wizzup>
but the applet doesn't realise when it gets changed I think
<Wizzup>
so it tries to revert to the wrong state
<uvos>
it dosent get changed
<uvos>
at least should not
<Wizzup>
so playing something in mpv (or w/e) and set volume to max on speaker, plug in hp, set volume to min, remove hp, and then adjust volume a bit
<Wizzup>
speaker will go to almost min
<Wizzup>
(from previous max)
<uvos>
yeah its true
<uvos>
the volume slider dosent update from external at all
<Wizzup>
don't know if it is intended, but it's not how it works on the n900 at least
<uvos>
but this is probubly ucm bug
<uvos>
the volume slider dosent updateing from external at all us a legacy bug, or rather nokia just dident care and the implementation is very bad
<Wizzup>
are you sure it doesn't rely on ohm and those plugins?
<uvos>
yes
<Wizzup>
because it clearly works
<Wizzup>
on n900
<uvos>
it cant update from external
<Wizzup>
well it might read different streams/sinks?
<uvos>
and it dose the volumes itself
<uvos>
for different states
<Wizzup>
oh, you mean it doesn't care for user manually changing it with alsamixer
<uvos>
no
<uvos>
it dosent care for anything else changing the stream
<uvos>
pavucontrol etc
<Wizzup>
the behaviour I described above works ok on fremantle/n900 though
<uvos>
ucm is probubly set to duck the volume on hp by accient
<uvos>
its broken
<uvos>
it just works because it claims all changes for itself
<uvos>
so ucm i probubly set to duck the volume on hp by accident
<Wizzup>
then it must be aware that something changes in audio setup
<Wizzup>
uvos: I don't think so, try to toy around with it a bit
<uvos>
and the slider dosent update when pa changes it
<Wizzup>
I'm pretty sure this is an unrelated bug
<Wizzup>
uvos: try the inverse: set speaker to 0, then plug in hp, set hp to max, then unplug hp, note that it is silent (correct) and then press volume up or down and see speaker jump to max
<uvos>
i dont have to
<uvos>
you can see the problem in pavucontrol-qt
<uvos>
anyhow it will get fixed once the slider follows pa events
<freemangordon>
removing stream-restore basically means that all maemo audio infra will not function
<freemangordon>
including ohm policies and whatnot
<Wizzup>
right
<freemangordon>
this is nto about updating the slider, but about lots more
<freemangordon>
so, what I think shall be done is: get module-stream-restore(or whetever the name is) from nemo and make it work, then port the applet to use it
<Wizzup>
I think I have this packaged
<freemangordon>
it would have been good if we can integrate with ucm though
<freemangordon>
but lets look at that after we finish all the onther things we're on atm
<Wizzup>
yes, ohm and pa stuff is going to require quite some brainpower and time
<freemangordon>
mhm
<Wizzup>
right, so do we merge this and later revert some stuff?
<Wizzup>
right now we have no volume control
<freemangordon>
up to you
<Wizzup>
I think I like the other changes, so I'd say yes, but maybe get the code commented rather than removed
<freemangordon>
maybe create a separate branch with that merged
<Wizzup>
or a branch for the code we want to keep
<freemangordon>
I wonder if we can create our own ucm parser, if ucm properties are not already available somehow
<freemangordon>
but lets not get into that now :)
<uvos>
ucm is alsa
<uvos>
pa is not nesscary at all
<uvos>
and yes you can read it from alsa
<freemangordon>
as I think getting audio properly will be the most complicated task we'll face
<uvos>
on everything except the n900
<uvos>
everything should work allready
<uvos>
except notification volume
<uvos>
witch is pretty easy to add
<uvos>
functionality wise
<freemangordon>
uvos: no, look at libplayback
<uvos>
ofc using the upstream alsa stuff makes api work differenly
<freemangordon>
everything maemo uses that
<freemangordon>
if there is upstream functionality that matches, well, maybe we can rewrite libplayback to use it. but I doubt
<freemangordon>
uvos: a simple example: you listen to music and sms comes. what happens? music gets paused, 'new sms' sound played and music resumed. or. sms sounds get mixed with music? or...?
<uvos>
yes
<uvos>
sound pauses
<mighty17[m]>
we had a public history right?
<uvos>
because the profile is switched pa suspends the sink
<uvos>
this causes pause
<mighty17[m]>
ie chat logs
<freemangordon>
uvos: "sound paused" is not the same as "playback pauses"
<uvos>
then it plays at some volume set for the new stream
<uvos>
playback pauses
<freemangordon>
how?
<uvos>
if the application is implemented correctly
<uvos>
gets a pa event
<freemangordon>
it is, by using libplyback
<uvos>
this works in mpv and mpd
<uvos>
and all desktop applications generally
<freemangordon>
who sets the priorities and classes?
<uvos>
then the sms notification sound is played at whatever volume of the new stream
<freemangordon>
and I can assure you this work extremely well in maemo
<uvos>
if its implemend as well as the volume slider
<uvos>
hahahahahahaha
<uvos>
so right now sphone dose its own switching, this is bad we would need soemthing to do so
<uvos>
yes this needs to take priority into acount
<freemangordon>
well, you may find it funny, but it really works wvery well
<uvos>
but this is the only pice we need
<freemangordon>
not really
<uvos>
and its very small compeard to takeing the eintere legacy stack
<uvos>
yes it is
<freemangordon>
uvos: I am not going to argue
<freemangordon>
but, to the extend it depends on me, I will resist to turning maemo-leste to a pale shadow of fremantle
<Wizzup>
sailfish also uses libplayback I think
<uvos>
thinking that just because implementaion differeng it being a "pale shadow" is the hight of folly
<uvos>
libplayback is not the issue here
<uvos>
since we can easly port it to whatever
<Wizzup>
what is the issue?
<uvos>
everything else
<uvos>
:P
<Wizzup>
I don't get it
<sicelo>
btw, according to someone who toyed on N900, maybe it's not *that* difficult to deal with the 200+ controls ... apparently not all of them are connected
<sicelo>
they prolly just exist in the chip, and driver exports them, but that's all
<uvos>
the n900 is a bit different
<uvos>
so it needs soemthing to redirect streams
<uvos>
since the cpu needs to copy samples about form device to device
<uvos>
something has to do that
<uvos>
this is indeed a bit more work
<uvos>
but it dosent tranlate at all to mapphones or pp
<freemangordon>
uvos: you mean calls?
<uvos>
yeah, also bt
<freemangordon>
my example was not about that, but anyway
<uvos>
right im just saying upstream has nothing for this
<uvos>
afaik
<Wizzup>
so what do we not want to pick from fremantle? I am confused
<Wizzup>
the sink roles definitely seemed to make sense to me
<uvos>
well the pa setup in general, ohm mostly
<uvos>
dont worry
<uvos>
ill do it
<freemangordon>
uvos: please don;t
<uvos>
sigh watever
<uvos>
*whatever
<Wizzup>
freemangordon: uvos: let's be constructive here, and I would really appreciate uvos' help with the ohm stuff
<freemangordon>
uvos: even if we are to do that (remove ohm etc)...
<freemangordon>
I think we shall discuss what we want to achieve, no?
<freemangordon>
Wizzup: sure
<uvos>
well not now
<Wizzup>
we do, and we did discuss that too, I think
<Wizzup>
but not now
<Wizzup>
yeah
<Wizzup>
:D
<uvos>
im done with this for now
<freemangordon>
yeah, not now
<uvos>
merge the volume slider if you like whatever