<auanta>
* wonders if the OS supports connecting to a monitor via usb c
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 255 seconds]
macros_ has joined #maemo-leste
<auanta>
i think i answered my question haha, booting from emmc you do have to change the fstab
auanta has quit [Ping timeout: 268 seconds]
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
xmn has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
wideland1 has quit [Ping timeout: 268 seconds]
enyc has quit [Ping timeout: 255 seconds]
M1peter10[m] has quit [Quit: You have been kicked for being idle]
<freemangordon>
Wizzup: buffer age seems to be always zero :(
<Wizzup>
of clutter?
<freemangordon>
of eglQuerySurface(backend_egl->edpy, stage_egl->egl_surface, EGL_BUFFER_AGE_KHR, &age);
<freemangordon>
yes in clutter
<freemangordon>
this means inalid backbuffer and full redraw
<freemangordon>
*invalid
<freemangordon>
I will ask enunes later on
<freemangordon>
maybe we shall support partial updates as well
<freemangordon>
does not make sense, but..
Pali has joined #maemo-leste
<Wizzup>
freemangordon: do we need more mesa features or do we need to be more clever about it somehow?
<Wizzup>
uvos: if I have a sphone new sms window open (incoming), then opening the dialer doesn't bring it forward I think
<Wizzup>
uvos: latest kernel on my bionic works again with the modem it seems
<Wizzup>
uvos: so that was probably a fluke on my device
<Wizzup>
uvos: btw I am seeing this on bionic (maybe also on d4, not sure): [ 25.158325] asoc-audio-graph-card soundcard: ASoC: DAPM unknown pin Headphones
SuperMarioSF has joined #maemo-leste
SuperMarioSF has quit [Client Quit]
<freemangordon>
Wizzup: dunno, maybe we have to enable something
_uvos_ has joined #maemo-leste
<_uvos_>
Wizzup: yes, unfortinatly the libhildon api is terrible and, because it uses globals all over the place, dosent allow an application to have more than one window stack of stacked windows. this means certail combinations of windows in sphone conflict if sphone is compiled with libhildon support
<_uvos_>
since hildon itself has no sutch limitation, a fix might be to have sphone set all the xatoms to make the windows stacked itself
<_uvos_>
and then drop libhildon
_uvos_ has quit [Quit: _uvos_]
xmn has quit [Quit: ZZZzzz…]
Livio has quit [Ping timeout: 252 seconds]
auanta has joined #maemo-leste
<auanta>
my biggest thing with the current image is lack of on screen arrow keys for terminal navigation.. has anyone found a way to handle that?
<auanta>
especially for apps that use the console
auanta has quit [Quit: leaving]
auanta has joined #maemo-leste
<auanta>
join #devuan
<auanta>
oops
<sicelo>
the bottom panel in osso-xterm is customizable. you could 'retrofit' arrows there if you want
<auanta>
oh nice
<auanta>
oh yeah the other thing i noticed is that if i open up the surf browser or even chromium, i cant access the keyboard at all (e.g. to type a URL)
<norayr>
i just installed maemo-leste on my friends' droid4.
<norayr>
he has droid4 in a very good condition.
<norayr>
very good.
<norayr>
and it works very well.
<norayr>
and he is happy
<norayr>
thank you everyone.
Danct12 has joined #maemo-leste
<auanta>
another question as i'm trying to navigate the UI is.. how do I create a launcher for apps?
<auanta>
it appears that apps available in the repo do not populate with icons, unless they are in the 'app store'
<auanta>
is there a way to do it similar to how other desktop uis let you "create a launcher"?
<sicelo>
i don't recall if there's an actual widget/application to facilitate that. anyway, it's through .desktop files, like in other desktop UIs. you can look at the .desktop files from the applications that have icons, and do same thing for whatever you want to launch
<sicelo>
a quick and lazy way, if you don't care about icons is to install desktop-cmd-exec widget. it allows you do run arbitrary commands from a widget on the desktop, thus a poor man's "launcher"
avoidr has quit [Quit: leaving]
avoidr has joined #maemo-leste
<freemangordon>
Wizzup: it was my fault
<Wizzup>
freemangordon: ah?
<freemangordon>
buffer age issue
<Wizzup>
yeah
<Wizzup>
just wondered what it was
<freemangordon>
ah
<freemangordon>
was calling the function but always returning 0, in short :)
<Wizzup>
:)
<auanta>
heyy that works for me! thx @sicelo!
<auanta>
it does appear that the qtwebbrowser supports the keyboard. it seems to have its own separate keyboard that looks very different
<Wizzup>
right, that's a problem currently
<Wizzup>
our qt doesnt't support our normal keyboard yet, so this is a workaround
<auanta>
firefox, and pretty much all the browsers i tried are like that (not supporting the keyboard). will the fix work for all of them or just the qt one?
<auanta>
out of curiosity XD
<Wizzup>
it depends on the widget set and how we do it
<auanta>
ah ok
<Wizzup>
yeah, sorry, no simple answer :)
<sicelo>
auanta: check with uvos ... i think one of the volume keys should make keyboard work in firefox, etc
<Wizzup>
the hamburher button
<Wizzup>
or is this pinephone?
<auanta>
yes
<auanta>
PP
<auanta>
WHOA that's wild.. yes, the volume up key DOES bring up the keyboard
<auanta>
thanks ;)
<sicelo>
yw
<Wizzup>
uvos: btw, the bionic ofono doesn't seem to necessarily have the same bugs as the d4 does
<sicelo>
it's better, or worse?
<Wizzup>
better I think
<Wizzup>
like, it just detects the sim even if it has a pin
<Wizzup>
upon boot
<Wizzup>
on the d4 you need to restart ofono for it to do that, or perform some other operation
<Wizzup>
of course, my bionic doesn't want to actually connect to the network atm :)
<Wizzup>
it connected now :)
pere has quit [Ping timeout: 264 seconds]
<freemangordon>
Wizzup: I think I made it
<Wizzup>
any difference?
<freemangordon>
the only thing I cannot figure out is how to determine for how long to keep the history
<freemangordon>
hard to say
<Wizzup>
hm
<freemangordon>
I mean - how to measure
<freemangordon>
h-d swipes with 56fps in portrait
<Wizzup>
maybe compare to before with other mesa
<Wizzup>
and other h-d
<freemangordon>
actually fps is 60
<freemangordon>
in landscape it is slow, but that's because of the SW rotation
<Wizzup>
right
<Wizzup>
uvos: ok, calls work ok on the bionic too
<Wizzup>
freemangordon: maybe it is higher? I don't really know
<freemangordon>
well, for sure it does partial rendering
<freemangordon>
this should affect rendering times
<freemangordon>
but it is really hard to measure
<Wizzup>
it's a win in any case if we don't need to patch our mesa
<freemangordon>
sure
<freemangordon>
I wonder for how long I shall keep damage history
<freemangordon>
no more that 4 frames I guess
<Wizzup>
not sure how it works and what keeps the history tbh
<freemangordon>
we shall keep a list of damaged areas, so when we get the current back buffer age, we re-apply whatever has been done since
<freemangordon>
I borrowed the implementation from upstream clutter, but it seems it is not good
<freemangordon>
as it seems it assumes one always gets the 'oldest' back buffer, but that's not the case
<freemangordon>
anyway, I'll hard-code to 4 frames and call it a day
<Wizzup>
okay
<Wizzup>
cool :)
<freemangordon>
occasionally we'll have full scene redraw, but...
<freemangordon>
Wizzup: could you check if d4 supports EXT_buffer_age?
<Wizzup>
sure, sec
<Wizzup>
not in es2_info at least
<Wizzup>
(es2_info | grep -i EXT_buffer)
<freemangordon>
es2_info | grep -i buffer_age
<freemangordon>
should be supported
<freemangordon>
it could be KHR
<freemangordon>
could you just pastebin the result of es2_info?
<freemangordon>
yep, landscape fps is 22, portrait 60
<Wizzup>
in portrait I get 15-17
<freemangordon>
when swiping
<Wizzup>
in portrait
<Wizzup>
hm looks like it's similar in landscape for me (15-17)
<freemangordon>
mhm
<Wizzup>
stintel: ^^ :)
<freemangordon>
same here with mesa/clutter from the repos
<freemangordon>
22/60 with the fix
<Wizzup>
freemangordon: do your h-d changes work if it's not supported as well? (suppose so)
<freemangordon>
it should
<Wizzup>
ok
<Wizzup>
we can build it for -devel or -experimental and try it
<freemangordon>
but I don't want to build mesa on d4 (again)
<Wizzup>
just lmk when
<Wizzup>
I can build it in CI quickly
<freemangordon>
so, could you please revert the hack in -devel and build mesa?
<freemangordon>
'revert the hack in mesa' that is
<Wizzup>
should we do -experimental?
<freemangordon>
no
<Wizzup>
ok
<freemangordon>
we will break the rendering on PP for those on -devel for a while, but well, this is -devel after all
<Wizzup>
ok, we also have -experimental for this toying
<freemangordon>
I know
<freemangordon>
going to cook some dinner while mesa gets build
<Wizzup>
ok, btw
<freemangordon>
will push clutter changes after that
<Wizzup>
we don't -need- to rebuild mesa to test this, no?
<freemangordon>
yes, we do
<Wizzup>
we can just not use the swap behaviour
<Wizzup>
hmm ok?
<freemangordon>
otherwise it hangs
<freemangordon>
in xshmwait() or something
<freemangordon>
ttyl
<Wizzup>
ok
<Wizzup>
maybe when you get back you can push the h-d changes
<Wizzup>
mesa will probably build quite quickly now on our new hw ;)
<Wizzup>
(I still think we should just do it for -experimental tbh)
<freemangordon>
h-d changes?
<Wizzup>
no, mesa
<freemangordon>
clutter changes ;)
<Wizzup>
I can just built it again once it works
<Wizzup>
freemangordon: right
<Wizzup>
as in, there's no point in knowlingly breaking -devle imho
<Wizzup>
knowingly*
<freemangordon>
we are not going to *break* it
<Wizzup>
I suppose it just re-adds the render issues
<Wizzup>
ok
<freemangordon>
for a while rendering will be ugly on PP
<freemangordon>
yes
<Wizzup>
started it
<freemangordon>
thanks
<Wizzup>
np
<freemangordon>
hmm, nothing in ci channel
<Wizzup>
it posts about -source after it's done usually somehow
<freemangordon>
ah, ok
<freemangordon>
bbl
pere has joined #maemo-leste
<Wizzup>
freemangordon: ok, so the mesa build for armhf and aarch64 should be ready
<Wizzup>
the amd64 one failed due to disk space issues
<Wizzup>
it looks like jenkins has kept every build we've ever done
<Wizzup>
so I just changed the job xml config to only keep the last three, but it doesn't seem to automatically prune them, so I might have to re-run some jobs just to prune them
<freemangordon>
ok
<freemangordon>
going to push clutter to -devel
<Wizzup>
ok
<Wizzup>
I started another mesa build just to see if it auto cleans
<freemangordon>
ok
<Wizzup>
yeah looks like it
<Wizzup>
it might do it -after- the builds succeeds, but hey :)
<freemangordon>
hmm, seems we have more issues on PP
<Wizzup>
freemangordon: mesa related?
<freemangordon>
Wizzup: before you upgrade, could you confirm that after unlock, screen goes black or shows tklock after 1-2 seconds?
<freemangordon>
not sure
<freemangordon>
mce/tklock most-probably
<Wizzup>
will test now
<freemangordon>
only when you are on desktop though
<freemangordon>
with no applications started
<freemangordon>
hmm, happens with settings as well
<freemangordon>
looks like tklock event eater window
<freemangordon>
like it is not transparent
<Wizzup>
freemangordon: I don't see this currently I think
<freemangordon>
lemme revert clutter
<Wizzup>
freemangordon: maybe try conversations or firefox or some others that also had obvious glitches
<freemangordon>
no, rendering is ok
<freemangordon>
I am using xterm to test
<Wizzup>
ok
<Wizzup>
right
<freemangordon>
like swipe up<->down in xterm to select
<Wizzup>
yup
<Wizzup>
I do remember that :P
<freemangordon>
this is another issue
<Wizzup>
ok
<freemangordon>
lemme downgrade mesa as well and restart, to be 100%sure it is still the same
<freemangordon>
because I downgraded clutter and it is there
<Wizzup>
ah
<buZz>
wow new vdpau drivers? do they work on d4?
<Wizzup>
buZz: where did you read vdpau?
<Wizzup>
oh, you're seeing some debian update?
<Wizzup>
probably just a security or bugfix for debian buster
<buZz>
in apt upgrade :P
<Wizzup>
yeah so it'll just be an upgrade from debian
<freemangordon>
:(
<freemangordon>
unrelated
<freemangordon>
just rebooted with downgraded mesa/clutter
<freemangordon>
the same
<Wizzup>
ok
<freemangordon>
do you use tklock?
<Wizzup>
well, that's good, right?
<Wizzup>
yes, I just use the default everything
<freemangordon>
not really
<Wizzup>
I am not seeing what you are seeing I think
<freemangordon>
because I have no idea how to chase it
<freemangordon>
lemme make a video
<buZz>
version is 21.2.5+pvr6-1+2m7 , made me think it was for powervr?
<freemangordon>
buZz: wait a bit, on PP rendering will be broken and also this is not tested
<freemangordon>
shall I merge or you want to have a look?
<Wizzup>
will look
<freemangordon>
Wizzup: ok, in the meanwhile I will test on d4
<Wizzup>
looks good to me
<freemangordon>
ok, will test on d4 and if nothing is obviously broken will release it in -devel
<Wizzup>
ok
<Wizzup>
freemangordon: holy shit this is so much more smooth in portrait
<freemangordon>
mhm :D
<Wizzup>
it'd be kinda hilarious if h-d on lima is more smooth than all the wayland things, since it was advertised to be smoother and such
<freemangordon>
it is better in landscape too
<freemangordon>
sure it is
<freemangordon>
you mean xorg?
<Wizzup>
yeah, but the latency there is something I can feel
<Wizzup>
freemangordon: yeah just nvm my last statement, dont feel like elaborating :)
<freemangordon>
I guess because modesetting does 3-buffer
<Wizzup>
I know that folks online wrote that h-d (even before your patch) is the most smooth 3d wise
<freemangordon>
yep, saw that and wonder what did other do to make it slower
<freemangordon>
*others
<Wizzup>
bloated frameworks probably
<freemangordon>
yeah
<Wizzup>
+ maintainers like clutter not caring about low power
<freemangordon>
clutter is abandoned long time ago
<Wizzup>
need me to try on d4 or bionic?
<freemangordon>
already did on d4
<Wizzup>
3ok
<Wizzup>
ok
<freemangordon>
you may try on bionic, just in case
<freemangordon>
not that is is different
<Wizzup>
nah it'll be the same :)
<Wizzup>
uvos: I think we can move the omap-linux to stable, agree?
<Wizzup>
uvos: or is there still this drm hang bug that sicelo mentioned?
<Wizzup>
iirc if it's actually 100% reproducible, then that might be good news
<freemangordon>
Wizzup: we still have that high iowait with PP kernel in -devel on my braveheart
<Wizzup>
do you know what could cause it?
<freemangordon>
no idea
<Wizzup>
I also have it on my d4, and thought maybe the sd card was unhappy
<Wizzup>
and they are different kernel sources and versions
<freemangordon>
maybe your sd card is unhappy
<Wizzup>
for sure kernel upgrade via apt or modest can really freeze it for a while
<freemangordon>
because I downgraded the kernel and it works fine
<freemangordon>
compiled mesa twice without issue
<Wizzup>
ok
<freemangordon>
hmm, for how long will I see that big charging battery on my d4?
<Wizzup>
what do yoy mean?
<Wizzup>
oh
<Wizzup>
hah
<Wizzup>
until you press the power button
<freemangordon>
I restarted...
<Wizzup>
that's charge mode - it enters that when usb is plugged in and providing power on boot
<freemangordon>
I am pressing it appears
<Wizzup>
maybe this is the drm hang sicelo was talking about
<freemangordon>
ah
<freemangordon>
wait, this is not ok
<Wizzup>
yup
<freemangordon>
so, when I pressed power button it continued booting
<freemangordon>
before that I was pressing volume buttons
<Wizzup>
ah, ok, that's fine then?
<freemangordon>
how's that?
<freemangordon>
I wanted it to boot and it entered some "charging mode" I wo9uld expect to exit once it has enough battery to boot
<freemangordon>
not requiring me to power it on gain
<freemangordon>
*again
<freemangordon>
that's bad UX imo
<sicelo>
it doesn't auto exit charge mode
<freemangordon>
exactly
<Wizzup>
I am confused, fmg said it continued booting
<Wizzup>
so does it, or does it not exit charge mode?
<freemangordon>
after I pressed power button
<freemangordon>
so, it want manual intervention to continue
<freemangordon>
*wants
<sicelo>
it's like that by design
<freemangordon>
thats broken by design then
<freemangordon>
correct behaviour should be to exit that mode once there is no more need of it
<sicelo>
Wizzup: i don't know if it's drm hang or what, but that's what uvos says. what i observe is - boot droid 4 with usb, get in charge mode. after this, battery shows on screen with no backlight and pressing power or any other button doesn't have any effect. only way to get out of this is to force reset device.
<sicelo>
freemangordon: you can disable charge mode, by removing it from the kernel cmd line. I've been meaning to do so myself
<freemangordon>
sicelo: that's not the point
<Wizzup>
fwiw the original fw doesn't boot either when it's fully charged
<Wizzup>
I don't know what the n900 does, but I don't think it does that either, not sure
<freemangordon>
Wizzup: it depends:
<freemangordon>
if you power-on with usb cable attached, it just boots to OS
<freemangordon>
if you reboot from OS with cable attached, it just reboots to OS
<freemangordon>
the only case it does not boot to OS is if you attach a cable when device is powered off
<Wizzup>
freemangordon: I mean we're planning to eventually replace this again with actdead, no?
<freemangordon>
then it enters ACTDEAD (aka charge) mode and does not fully boot the OS
<freemangordon>
no matter how we call it, it behaves like I explained
<sicelo>
i agree about bad UX in that case, but yeah, charge-mode (taken from pmOS) has completely different goal from maemo's actdead
<freemangordon>
I am fine to call it charge mode or whatever, the point is that it shal behave consistently
<freemangordon>
which it does not currently
<freemangordon>
again: I did 'sudo reboot' and end-up with animated battery
<freemangordon>
that's broken IMO
<freemangordon>
someone shall check 'boot reason' from omap and decide based on that
<freemangordon>
was it powered on because usb cable was attached? yes? ok, stay in charge mode. no? continue to boot unless there is no enough charge, etc...