<Entitlement>
sicelo - [ SUBMITME: iio: accel: st_accel_core: Read mount-matrix from device tree · msm891... ]
<parazyd>
We could include that patch if it makes sense
<sicelo>
He says, "It's a bit ugly so I've been meaning to rework it and then submit upstream"
<parazyd>
ok
<sicelo>
I don't think we urgently need it. Actually that's why I didn't open issue in bug tracker, since it's not really a leste problem
<sicelo>
For the record, (3), the mount matrix I ended up with in udev to make it work in droid4's natural portrait mode is 0, -1, 0; 1, 0, 0; 0, 0, -1 ... so that's what would need to go into dts once that's working.
<sicelo>
Although it's actually probably 0, 1, 0; -1, 0, 0; 0, 0, -1 that should be in dts. Seems the matrix is inverted/transposed in dts, as opposed to udev.
uvos has joined #maemo-leste
Pali has joined #maemo-leste
Jasper[m] has quit [Quit: Bridge terminating on SIGTERM]
cato`[m] has quit [Quit: Bridge terminating on SIGTERM]
kgoetz has quit [Quit: Bridge terminating on SIGTERM]
t_rex has quit [Quit: Bridge terminating on SIGTERM]
mighty17 has quit [Quit: Bridge terminating on SIGTERM]
fLegmatik has quit [Quit: Bridge terminating on SIGTERM]
venji10[m] has quit [Quit: Bridge terminating on SIGTERM]
tvall has quit [Quit: Bridge terminating on SIGTERM]
ollieparanoid[m] has quit [Quit: Bridge terminating on SIGTERM]
afontain_ has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam has quit [Quit: Bridge terminating on SIGTERM]
venji10[m] has joined #maemo-leste
Jasper[m] has joined #maemo-leste
cato`[m] has joined #maemo-leste
kgoetz has joined #maemo-leste
fLegmatik has joined #maemo-leste
t_rex has joined #maemo-leste
mighty17 has joined #maemo-leste
ollieparanoid[m] has joined #maemo-leste
MartijnBraam has joined #maemo-leste
afontain_ has joined #maemo-leste
tvall has joined #maemo-leste
xmn has quit [Ping timeout: 240 seconds]
inky has quit [Ping timeout: 260 seconds]
inky has joined #maemo-leste
<uvos>
sicelo: yup that looks like it
<uvos>
btw the physical oritation thing comes from android
<uvos>
where untill 4.0 or something you could not apply a matrix
uvos has quit [Quit: Konversation terminated!]
uvos has joined #maemo-leste
<uvos>
parazyd: the patch would not do anything for us, as we still need to override it with our matrix that has -y towards the left
<uvos>
parazyd: as we expect landscape as the natural orientation.
<Entitlement>
Wizzup - [ glamor: Fix rendering of pixmap textures backed by EGLImageKHR image (!568) · Me... ]
<uvos>
strait mesa as in llvmpipe?
<uvos>
with omapdrm?
<sicelo>
Jonathan's mesa
<sicelo>
Mesa+pvr
<uvos>
yeah
<uvos>
it has issues
<Wizzup>
uvos: it sounds similar to the texture problem you ran into, I think
<uvos>
idk if glmark works
<uvos>
Wizzup: no thats not ti
<Wizzup>
ok, too bad
<sicelo>
You can try. No luck for me so far on postmarketos. Glmark immediately crashes the gpu there ... but it ran with TI's blobs on N900
<uvos>
sicelo: ok
<uvos>
it runs on full blobs for sure on d4
<uvos>
weston and ksmcube at least work fine on the google pvr patches
<uvos>
but yeah its buggy
<uvos>
gitlab.freedesktop.org/freemangordon/xserver/-/commits/test <- i started here
<sicelo>
Yes, also kmscube fine for me on pmos with Jonathan's mesa + pvr. Very reliably too. Only one time I got around 40fps, after trying some UI it didn't like
<uvos>
yeah if glmark and other stuff dosent run, maybe we should continue with the blobs
<uvos>
idk
<uvos>
i gues the legwork with the texture suffeling might be our best bet
<uvos>
(as fmg reccomends)
<sicelo>
But give it a try too :-p
<sicelo>
I'm too new to this stuff and might have done something wrong
<uvos>
well i have no idea what im doing either tbh
<uvos>
my trade is mechanical engineering
<sicelo>
At least you know something about gbm and glamor
<uvos>
:P
<uvos>
yeah
<uvos>
problem is i really dont know anything about gl
<uvos>
i only know about kernel interfaces around video/gfx
<uvos>
esspecaly with the texture copying problem, it would be great if we had someone with enough knowlage about gles and egl spec to tell us if whats happing in pvr is to spec
<uvos>
or if its a bug
<uvos>
if its a bug we could complain to ti
<parazyd>
I can try getting through to some people if someone can write me what exactly I could ask them
<parazyd>
wrt gles/egl
<uvos>
is glTexSubImage2D allowed on EGL_KHR_image textures (backed by gbm)
<sicelo>
I think I've seen that before ... glTexSubImage2D ... isn't that something missing on pvr? :-/
<uvos>
no
<uvos>
i think you are thinking about texture clamping modes
<sicelo>
Ok. Might be mistaking it with something else
<parazyd>
uvos: So depending on a yes or no answer we would know if it's a bug in the blobs?
<uvos>
yes
<sicelo>
Ah, mistaking it with GL_EXT_unpack_subimage
<uvos>
i also take the liberty of hosting freemangordons test app here
<uvos>
it shows what you have to do to get EGL_KHR_image into glTexSubImage2D without the blobs exploading
<uvos>
thanks to this it really istent more than some legwork to do the same in all places in glamor
<uvos>
(should at least)
<uvos>
with all blobs
<uvos>
mesa-pvr has other / maby additional problems
<Wizzup>
weren't there also hangs? or no hangs
<uvos>
Wizzup: the hang because of the 1bpp textures was solved by fmg
<Wizzup>
ok
<uvos>
i think it still hangs on exit
<uvos>
but i havent tried the latest on the full blob stack
<uvos>
i think everyone is now sutably informed
<uvos>
maybe we should copy the above log into an issue
<Wizzup>
yeah...
<uvos>
executing the manual update ioctls after page flip in driectfb dident help :(
<uvos>
i hope im doing something wrong...
<parazyd>
Also
<parazyd>
the IRC channels are on irc.freenode.net (FreeNode). The main channel is now '##OpenGL' (two hashes) and there's also a '##opengl3' channel specific to OpenGL 3.x development.
<parazyd>
Perhaps worth dropping by there too?
<uvos>
ok i must be doing something wrong
<uvos>
DFBARGS=system=fbdev,no-graphics-vt
<uvos>
works fine
<uvos>
because the vt's cursor causes the display to continue to refesh
<uvos>
so it is dfb failing to refesh the display confirmed