<Wizzup>
uvos: ohmd seems to react to hp plug just fine on n900, so that's good news
<Wizzup>
it also has support for fmradio, so that'll be fun if that "just works"
<Wizzup>
with the pulseaudio alsa-config for the n900 (instead of UCM) I can also switch audio for the apps to earpiece, headphones or speakers
<Wizzup>
It looks like the volume handling is a bit different, so we'll have to decide if we use their approach (mainvolume plugin) or the old maemo method
<Wizzup>
it also nicely attempts to disable the fmradio broadcast when hp is plugged in
<Wizzup>
cool
<Wizzup>
anyone with a sailfishos phone here?
<Wizzup>
I was wondering what this would yield: rpm -qf /etc/pulse/xpolicy.conf
<Wizzup>
(some of those would be good to try on software gl too: what if all transitions are set to 0 ms, blur disabled, etc)
pere has joined #maemo-leste
<bencoh>
I'm not certain the user can really disable everything using transitions.ini
<bencoh>
but that would be cool
<Wizzup>
probably not
<Wizzup>
but we control it, so if it makes a difference we could consider some of that
<bencoh>
for software egl I guess it would
<bencoh>
for n900, I doubt it
<Wizzup>
yeah
<Wizzup>
there is also some stuff about xdamage events wrt rotation
<bencoh>
reducing animations on n900 does not necessarily speed it up
<bencoh>
it's funny / silly, but if you reduce animations too much on n900/fremantle, it feels kinda jerky
<Wizzup>
mhm
inky_ has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
mardy has quit [Read error: Connection reset by peer]
mardy has joined #maemo-leste
inky_ has quit [Read error: Connection reset by peer]
inky_ has joined #maemo-leste
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: hmm?
<Wizzup>
uvos: what part?
<uvos>
ping
<uvos>
what do you want
<Wizzup>
I don't remember :)
<uvos>
oh
<uvos>
ok
<Wizzup>
made a lot of progress on audio front though
<uvos>
ragarding the transistions ini
<uvos>
i do have the roataion animation disabled
<uvos>
but really reduceing those timers to 0 is not so usefull
<Wizzup>
does it get rid of the noise upon rotation?
<uvos>
no thats the kernel
<Wizzup>
ok
<uvos>
that landed with the new omapdrm code
<uvos>
in 5.10 i think
<Wizzup>
ok
<uvos>
hildon is quite inefficant anyhow and will go through the motions of the animation either way
<uvos>
(ie it will create and distroy the surfaces)
<uvos>
so reducing the timer is effectively pointless
<Wizzup>
ok, we could probably write some code to skip that, but I am not sure if that helps muhc if we still 3d render everything (which I guess we will)
<uvos>
sure
<Wizzup>
right
<Wizzup>
it's also not relevant, we mostly have working 3d for our purposes
<uvos>
the main problem is that hildon is composing everything
<uvos>
for no real reason
<uvos>
imo
<Wizzup>
do you mean upon expose, or always
<uvos>
allways
<Wizzup>
and is that indeed what affects llvmpipe performance and such? I didn't measure
<uvos>
yes
<uvos>
without this the apps would be renderd by x
<uvos>
and not though llvmpipe at all
<Wizzup>
can clutter do that?
<uvos>
as is the architecture forces all of the apps to be renderd to textures
<uvos>
and then these textures are fed to the 3d engine (or llvmpipe)
<uvos>
can clutter do what?
<uvos>
not compose?
<uvos>
thats not related to cluter per say
<Wizzup>
I mean, wouldn't everything still be a 3d render?
<uvos>
no
<Wizzup>
hmm, so if we want to pursue a llvmpipe hildon-desktop with no eye candy we could maybe attempt that at some point
<Wizzup>
(skip animations, disable compositing)
<uvos>
ok so heres the deal:
<uvos>
so right now hildon asks x to put all of the xwindows into offscreen texutres which it feeds clutter and then transforms and renders all the windows itself.
<uvos>
this rendering is done by h-d via cluter via gl calls
<uvos>
this is what is slow
<Wizzup>
right
<uvos>
regardless of animations
<uvos>
this makes all the animations easy and allows the task switcher to show live tiles
<uvos>
in rality h-d could just let x render everything, and any thing it wants to show (the title bar, hildon home etc) could be real x windows that contain clutter surfaces instead of just clutter surfaces that hildon renders
<uvos>
hildon could still display all the same animations
<uvos>
by asking x for a single buffer before the animation
<uvos>
and then performing the animation with that buffer
<uvos>
then the rendering would never pass though gl
<uvos>
except durin an animation
<uvos>
the only thing you would have to sacrifice is the live switcher tiles (they would have to be screenshots of the app in its last focused state)
<uvos>
this would then work fine on x11 with no accell
<uvos>
as x11's own rendering is very cpu optimized it should be fast(ish) even on n900
<Wizzup>
right, but rendering seperate windows and such would be a lot of (re) work
<uvos>
right
<uvos>
it makes no sense to implement this kind of thing
<Wizzup>
yeah
<uvos>
from a manpower perspective
<uvos>
im just saying the way they did it is kind dumb
<uvos>
as this btw also wastes a screen sized buffer worth of ram for every app thats open
<uvos>
which im sure hurts bad on n900
<uvos>
thats 1.5mv
<uvos>
*mb
<uvos>
per app
<uvos>
just down the drain
<uvos>
anyhow cool progress on the audio stuff
<Wizzup>
yeah, hopefully it'll all come together soonish
<Wizzup>
I think most of the sw is now packaged and built in the CI
<Wizzup>
if I understand some of this correctly, UCM support probably isn't all that problematic
sixwheel- is now known as sixwheeledbeast
inky_ has quit [Ping timeout: 272 seconds]
inky_ has joined #maemo-leste
jesster1234 is now known as jessicant
jessicant is now known as jesster1234
jesster1234 is now known as jessicant
kona has joined #maemo-leste
<kona>
is there some way to get the virtual keyboard to send keystrokes direct to the terminal?
<kona>
or a way to send characters without a CR/LF for use in e.g. vi?
<kona>
i guess the latter is what i am looking for since my pinephone doesn't seem to support BT kb.
<stano_>
hi kona
<kona>
hi!
<stano_>
can we pm?
<kona>
yes, thanks for asking
<uvos>
kona: you cant use the vkb in immidate mode
<uvos>
kona: however you can send text with cr/lf to xterm
<uvos>
kona: just type the text and click above the vkb to close it
<kona>
oh, hmm.
<kona>
awesome, thanks!
<uvos>
you can also get subtaly different results (sometimes usefull) by opening the vkb with volume up
<uvos>
instead of a tap on the input field
<kona>
oh, that is great, too
<uvos>
i do have to say that the vkb of maemo is simply bad
<uvos>
its a weakness that stems from the fact that the devices we mostly use have hardware keyboards
<kona>
it used to work pretty well on the 810
<kona>
but i guess that's like, a decade ago :)
<uvos>
even though i never used a n810 i know the vkb still sucked even then, at least in implementation, because the current behind the scenes implementation is explicitly also for the n810 (ie its the same)
<kona>
oh, hmm.
<kona>
yeah, i usually used the hw kb
<inky>
i used n810, and i still like the device very much. i would use it everyday if not the ssl issue.
<inky>
i was surprised to know that mainline kernel doesn't support the device.
<inky>
i remember i installed non maemo custom linux distribution on sdcard with qt based desktop environment, roxbox? i guess roxterm belongs to that project.
<inky>
there was also a gentoo for n900 and i guess for n810 project by slonopotamus.
<inky>
uvos vkb did not have two backends back then, right? you have added x11 backend. or it did have two backends always?
uvos has quit [Remote host closed the connection]
uvos has joined #maemo-leste
<kona>
ssl issue? maybe too old openssl?
<kona>
1.0 vs 1.1 vs 1.2?
Pali has quit [Ping timeout: 248 seconds]
uvos has quit [Ping timeout: 248 seconds]
ajr has quit [Ping timeout: 252 seconds]
asriel_dreemurr has quit [Ping timeout: 276 seconds]