<rafael2k>
Wizzup: crazy re-drawings in firefox... it looks like its dimensions keep changing, even not scrolling the page the ui elements are drawn in wrong places, then in correct places, then in wrong again...
<rafael2k>
Wizzup: dont really know how to try glamor with llvmpipe...
rafael2k has quit [Ping timeout: 252 seconds]
rafael2k has joined #maemo-leste
alex1216 has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
uvos has joined #maemo-leste
<Wizzup>
rafael2k: ok, yes
<Wizzup>
rafael2k: I am also not seeing that anymore with apitrace
mepy_ is now known as mepy
rafael2k has quit [Quit: [BX] Man and mouse alike, both end up in pussy]
alex1216 has quit [Ping timeout: 256 seconds]
<uvos>
glamor refuses to enable on llvmpipe, you have to comment out that check in the source
<uvos>
not sure why you would want to in this case tho
<uvos>
the problem seams not to be glamor
<Wizzup>
uvos: ok, I just want to be able to communicate that to them somehow, they didn't ask if it was glamor
<Wizzup>
uvos: but if the major problem goes away in apitrace ...
<uvos>
apitrace slows things down so i gues that helps somehow
<uvos>
:(
<Wizzup>
yes, to which the guy who responded to me said 'we have never seen timing problems so that seems unlikely to me'
<Wizzup>
it could be that we just take the wrong unsupported path and that causes the enum issue perhaps
<uvos>
yes seams likely
<Wizzup>
although the glEnable is before that decision
<Wizzup>
I think the clutter 0.8 patches might not get applied at all
<Wizzup>
there doesn't seem to be a series file
<Wizzup>
bbiab
<uvos>
it also renders wrong on intel btw
<Wizzup>
so the lima guy said
<Wizzup>
13:42 < enunes> Wizzup: hmm I played it but I'm still not sure what am I looking at
<Wizzup>
13:43 < enunes> best case would be if a single trace reproduces the bug when played on the lima device and does not reproduce it on e.g. intel
<Wizzup>
which is why I wanted to try powervr
<Wizzup>
but imho the llvmpipe trace should suffice
<Wizzup>
I guess I could try to replay that on lima
<uvos>
its wrong on i965 too
<uvos>
so a bug in mesa is pretty unlikely
<uvos>
(i965 is a mesa classic dirver that shares very little with the gallium drivers radionsi/lima)
<Wizzup>
and actually the replay looks ok speed wise
<Wizzup>
ish
<uvos>
heh
<Wizzup>
probably because the gpu is slow :)
<uvos>
well inky_ and rafael2k use hildon on llvmpipe on pp
<uvos>
so it must be okish sorta
<uvos>
certenly llvmpipe hildon on d4 is more than painfull
<Wizzup>
it's all painful imho
<Wizzup>
but ok
<Wizzup>
if you see just how butter smooth portrait h-d is with lima when it works :)
<Wizzup>
it's quite a sight
<Wizzup>
ok now actually brb
<Wizzup>
so lima supports EGL_KHR_image_pixmap but llvmpipe does not
<uvos>
k
<Wizzup>
so perhaps the way we do EGL_KHR_image_pixmap is broken
<uvos>
yes
<Wizzup>
(even though it clearly works for pvr)
<uvos>
sounds very possible
<uvos>
i would not count on pvr to enforce spec :P
<uvos>
so comment that path out and try on lima
<Wizzup>
it seemed to be more like mesa not following spec if I recall fmg correctly
<uvos>
yes what glamor did with khr image was ub
<uvos>
mesa just worked in this case
<Wizzup>
ok
<Wizzup>
btw lima has EGL_NOK_texture_from_pixmap not we search for something else
<Wizzup>
we search for EGL_NOKIA_texture_from_pixmap
<Wizzup>
freemangordon: ^^^
<Wizzup>
pvr also as EGL_NOK_texture_from_pixmap it seems
<Wizzup>
ddk 1.17 at least
<Wizzup>
probably need to update that check too then
<Wizzup>
wondering if the call to eglCreateImageKHR perhaps needs updated img attribs
<Wizzup>
well hang on, why does the llvmpipe path still fail for lima then
<Wizzup>
maybe they interpret the KHR properties differently
<Wizzup>
EGL_KHR_partial_update seems to be in lima but not in pvr
<Wizzup>
so setting use_fallback=1 I think helps with firefox corruption, but not at all with osso-xterm problems I was tracing
<Wizzup>
but it does make vkb just work I think
<Wizzup>
we're onto something :)
<Wizzup>
checking for EGL_NOK_texture_from_pixmap instead of EGL_NOKIA_texture_from_pixmap has different behavious as well, the status area looks odd/off, and the other problems remain
<Wizzup>
so the current workaround is to set use_fallback to TRUE
<Wizzup>
there seems to be more problems still though
<Wizzup>
yeah no this is not the fix for some of the other problems at least
<Wizzup>
uvos: do you recall the obnoxious glib variable to print g_debug messages?
<Wizzup>
G_MESSAGES_DEBUG=all it is
<Wizzup>
maybe the problem is in clutter_eglx_texture_pixmap_update_area
<Wizzup>
this is beyond me for now
<freemangordon>
hmm?
<freemangordon>
seems I am missing the party :)
<freemangordon>
Wizzup: did you apply "glamor: add missing GL_TEXTURE_WRAP_X parameters"?
<freemangordon>
hmm, where do you see EGL_NOK_texture_from_pixmap?
<Wizzup>
freemangordon: hi!
<Wizzup>
let's take a step back a for a moment
<freemangordon>
sorry, I was too busy, I have some 30 minutes maybe now and I'll have to run (GF has birthday :) )
<freemangordon>
ok
<Wizzup>
ok
<Wizzup>
congrats :)
<freemangordon>
thanks!
<Wizzup>
so we're seeing lots of flickering and drawing of old and invalid content on the pinephone
<freemangordon>
one note re TFP - it is supported in VMs, so I doublt we misuse it
<Wizzup>
VMs are mostly llvmpipe
<Wizzup>
but well noted
<freemangordon>
not really
<Wizzup>
you can see the amd mesa one is clearly wrong
<freemangordon>
at least vmware and virtualbox provide 3d accell
<freemangordon>
right
<freemangordon>
but doesn;t seem like bad texture to me
<Wizzup>
there seem to be a pattern to it when I look at it in apitrace, the regions that were previously rendered black get turned white again in later frames
sunshavi has quit [Read error: Connection reset by peer]
<freemangordon>
soemthing doesn;t get flushed?
<Wizzup>
possible
<Wizzup>
but note that X renders with glamor
<Wizzup>
and it works just fine when h-d is llvmpipe but X is lima
<Wizzup>
as far as I can tell
<Wizzup>
I haven't tested the opposite (glamor with llvmpipe and h-d with lima)
<freemangordon>
right, but then buffers are not allocated by lima driver
<freemangordon>
BOs that is
<Wizzup>
ok
<Wizzup>
so there are a few other things to note:
<Wizzup>
1. not super relevant but the NOKIA extension we search for is present in mesa as NOK not NOKIA
<Wizzup>
2. mesa complains about invalid enums in glEnable(GL_TEXTURE_2D) and some texture param calls
<freemangordon>
(this is new to me, was not there few months ago)
<freemangordon>
(16,59,40) freemangordon: Wizzup: did you apply "glamor: add missing GL_TEXTURE_WRAP_X parameters"?
sunshavi has joined #maemo-leste
<Wizzup>
3. if I set use_fallback = TRUE with lima ( so the TFP checks are ommitted), some things work fine, but not all problems are solved, suggesting there are problems beyond TFP
uvos has quit [Remote host closed the connection]
<freemangordon>
so, did you apply that patch?
<Wizzup>
freemangordon: yes, looks like I have those applied
<freemangordon>
this is the 3rd one
<Wizzup>
yes
<freemangordon>
ok
<Wizzup>
this is basically where I am at now
<freemangordon>
I doubt we break TFP, clutter just issues 2 or 3 EGL calls
<Wizzup>
I am going to check how it goes with h-d using lima, but tfp hard disabled, I want to see if the osso-xterm selection bug is still there then
<freemangordon>
ok
<Wizzup>
so no, with TFP fallback in place, that redrawing bug is still there
<freemangordon>
as expected
<Wizzup>
but some bugs are fixed (like virtual keyboard rendering)
<freemangordon>
maybe because of the changed timing
<Wizzup>
could be
<Wizzup>
firefox also doesn't flicker as much anymore
<Wizzup>
in any case there is where I am stuck
uvos has joined #maemo-leste
<freemangordon>
so, what I think is - some fence is missing
<Wizzup>
the traces clearly render wrong on mesa
<freemangordon>
hmm
<freemangordon>
with llvmpipe?
<freemangordon>
on PC?
uvos has quit [Remote host closed the connection]
<freemangordon>
do we have some errors in retrace?
uvos has joined #maemo-leste
<freemangordon>
Wizzup: also, IIUC, we use GLES2 in clutter and OGL in glamor
<Wizzup>
freemangordon: no, llvmpipe renders fine
<Wizzup>
freemangordon: but if I render it on my PC it is also wrong with amdgpu
<freemangordon>
so, what is "mesa" then?
<Wizzup>
my amd radeon mesa driver
<freemangordon>
ah
<uvos>
we can totaly retire the idea that its glamor in any way
<freemangordon>
ok
<uvos>
this was proven in mulitple ways - not least of witch is i just tried the trace on amdgpu with acellMethod=none and dri2
<uvos>
and it has the same problem
<freemangordon>
ok, but then there seems to be some issue in GL calls
<Wizzup>
in general I think if you look in qapitrace you will see the textures are wrong
<Wizzup>
so whatever flings the texture to the display ultimately is not at fault
<freemangordon>
but ofc they are wrong
<Wizzup>
yes, mostly saying that's probably not glamor as well
<freemangordon>
ah
<freemangordon>
I mean - retrace just displays those textures, like, the content was captured on the device
<Wizzup>
parazyd: maybe the code can mention why the measuring math was changed, and to what
<Wizzup>
I see it in the PR but not in the code
<parazyd>
*shrug*
<parazyd>
I don't want to scare off people contributing by being super pedantic
<Wizzup>
he mentions a better algorithm but then we don't actually use it
<Wizzup>
parazyd: I committed the comments to liblocation
<Wizzup>
if this breaks it would be nice to know where it came from, so I added the guys remark
<Wizzup>
as in I don't think we test this code at all yet (distance from p1 to p2) so we probably don't know if it works even
<parazyd>
ok, thanks
<parazyd>
It's a textbook algorithm
<Wizzup>
right but we're swapping one textbook one out for another
<Wizzup>
I don't know if there's a reason one is more accurate for small distances than others, or why nokia went for one that's more accurate for longer distances
<Wizzup>
as in why not go for the 'king' algorithm
<parazyd>
This new one is faster
<parazyd>
And my algorithm was also from a textbook, not from the binary.
<Wizzup>
you can just have a linux repo with many remotes
<Wizzup>
I do that for n9xx-linux, droid4-linux, pine64-linux, etc
<parazyd>
Yeah I mean pushing to an empty gh repo
<Wizzup>
git is clever enough to sort everything else out
<rafael2k>
how I miss subversion...
<rafael2k>
:P
<Wizzup>
let me be blunt
<Wizzup>
you only miss it because you don't understand the power of git yet
<Wizzup>
<--- coming from someone who used to like svn
<rafael2k>
eheheheh
<rafael2k>
so good the r1234... knew by heart the commit numbers
<rafael2k>
I understand the power... I just don't need it
<rafael2k>
tarballs, patch and diff are good
<rafael2k>
anyway, I use git everywhere...
<rafael2k>
lemme focus here on this kernel not to forget upower lines
<Wizzup>
:)
alex1216 has joined #maemo-leste
<rafael2k>
yay, checking the patches for the 5.15, we'll have already the pinephone keyboard support, when it hit the streets
<rafael2k>
these ubuntu-touch guys are really annoyng.. a patch to config just to remove sysrq support... I like it so much
<uvos>
we do that too
<rafael2k>
:(
<uvos>
its because uart devices
<rafael2k>
any reason?
<uvos>
can be noisy so sometimes they broadcast sysrq randomly
<rafael2k>
right, did not know
<uvos>
mapphones have this problem for instance they would just spontainously reboot
<uvos>
because of sysreq being pressed by pluging in a charger :P
<rafael2k>
so cool to alt+sysrq+O and the computer just instantly shuts down
<rafael2k>
shit
<rafael2k>
right, sysrq stays N then
<uvos>
well we dont disable sysrq in kernel
<uvos>
but we do so early in the boot proccess via init
<rafael2k>
this is more elegant...
<uvos>
so that it still works if you need it to debug the phone
<rafael2k>
I'll not touch the mobian config to start, as it is working fine, just add the patch we need to make battery leve appear, and we should be fine
<rafael2k>
crypto modules are there already, all good
<Wizzup>
and then git checkout -t sunxi64/kernel-branch-yeah from pine64-kernel
<Wizzup>
and then just git push that
<Wizzup>
(this is untested but I think it can work)
<rafael2k>
tks!
<rafael2k>
if kernel works fine and debian package build finish successfully, I'll shout for help on how to use git
<rafael2k>
; )
<Wizzup>
k
<Wizzup>
meanwhile new mesa is hitting beowulf-devel finally
<Wizzup>
sicelo: now I think you should be able to apt-get dist-upgrade (well, in a few minutes)
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 256 seconds]
mardy has quit [Quit: WeeChat 2.8]
rafael2k has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: when you get to it, conversations is also a good test case for some corruption
<Wizzup>
there are two bars on the side of the screen that weirdly become 'transparent' or something where the previous (stacked) window becomes visible
<Wizzup>
I would suggest to just copy your n900 rtcom el db and try it