<tmlind>
no luck so far with current wlroots with weston-simple-egl with dmabuf instead of EXT_image_dma_buf_import like wlroots-0.14.1 is still using
<tmlind>
i wonder if there is some dmabuf issue also involved somewhere with the pvr_egl_shim?
<freemangordon>
tmlind: hmm, what exactly does not work?
pere has quit [Ping timeout: 256 seconds]
<tmlind>
freemangordon: so wlroots uses EXT_image_dma_buf_import up to 0.14.1, then drops it and uses dmabuf
<freemangordon>
dmebuf like BO?
<freemangordon>
or, what is dmabuf?
<freemangordon>
bo == gbm
<tmlind>
yeah i guess the buf comes via gbm
<freemangordon>
this should work
<freemangordon>
do you have some error message or anything that demonstrates "does not work"?
joerg has quit [Quit: EEEEEEK]
joerg has joined #maemo-leste
<uvos>
glamor uses EXT_image_dma_buf_import i think
* freemangordon
checks
<tmlind>
ok
<tmlind>
EXT_image_dma_buf_import works with earlier wlroots for weston-simple-egl
<tmlind>
weston-simple-dmabuf-egl i've never seen working and it produces some pvr blob error
<uvos>
ok but ofc dmabuf not working might point to deeper issues
<tmlind>
right
<freemangordon>
I don;t think dmabuf is supposed to work at all, unless I am missing something, it is GBM that should work. IIUC/IIRC dmabuf is platform specific
<uvos>
sure but the pvr driver must be mangining the gbm buffers in kernel somehow
<tmlind>
well yeah non-working dmabuf is an issue :) so making sure glamor uses EXT_image_dma_buf_import might fix pvr_egl_shim?
<uvos>
should be dambuf there no
<uvos>
(im not sure how pvrk works ofc)
<freemangordon>
glamor uses eglCreateImageKHR
<freemangordon>
to import gbm bo
<freemangordon>
this *is not* dmabuf afaik
<freemangordon>
I don;t think pvr blobs support EXT_image_dma_buf_import
<tmlind>
oh sorry wrong property, just a sec
<freemangordon>
I don;t remember seeing it announced
<uvos>
pretty sure its implemented in terms of dmabuf
<uvos>
(in kernel)
<freemangordon>
you mean gbm?
<tmlind>
i meant what is known to work is using EGL_WL_bind_wayland_display
<uvos>
yeah
<freemangordon>
uvos: might be
<freemangordon>
but from user POV those are different
<freemangordon>
dma_buf uses proprietary ioctl codes to map/unmap etc
<freemangordon>
after all everything should end up in the video memory
<uvos>
glamor certenly checks for EGL_EXT_image_dma_buf_import
<freemangordon>
BTW, gbm does not even allow you to mpa
<uvos>
but if pvr dosent expose it its not useing it ofc
<freemangordon>
uvos: modesetting uses GBM, not DMA_BUF
<freemangordon>
so is glamor
<tmlind>
sorry i pasted wrong buffer above, so what i meant is wlroots up to 0.14.1 uses EGL_WL_bind_wayland_display for weston-simple-egl and that works, dmabuf for later wlroots does not work
<freemangordon>
tmlind: I am confused
<tmlind>
yes sorry
<uvos>
glamor uses it for GBM_BO_WITH_MODIFIERS
<uvos>
(its not relevant just mentioning)
<freemangordon>
uvos: which is disabled
<uvos>
right
<freemangordon>
also, GBM_BO_WITH_MODIFIERS is still not DMA_BUF API
<uvos>
no
<freemangordon>
look at gbm.h
<tmlind>
i guess no way to test pvr_egl_shim with EGL_WL_bind_wayland_display? probably best to compare glamor usage against kmscube etc
<freemangordon>
bo with modifiers is basically several planes, IIRC
<freemangordon>
but it still a BO, not DMA_BUF
<tmlind>
just in case, if glamor is using EXT_image_dma_buf_import, and sgx blobs do not provide EGL_EXT_image_dma_buf_import_modifiers, glamor might be setting wrong default dmabuf configuration
<uvos>
its not
<tmlind>
ok
<uvos>
its just a optional path
<freemangordon>
glamor is using EGL_KHR_image_pixmap
<freemangordon>
tmlind: I also wonder why wlroots (or whatever) does not use native WL buffers
<freemangordon>
those are supported by the blob
<freemangordon>
do you have a link to the code?
<uvos>
its a compositor not a client
<freemangordon>
so<
<freemangordon>
?
<freemangordon>
it can still import WL buffer, not DMA_BUF buffer
<freemangordon>
maybe I am missing the context
<uvos>
it wants to use egl
<uvos>
Probubly
<tmlind>
i think the plan is to make wlroots support more backends, it already supports wayland and x11 at least
<uvos>
on wayland? it is the comp. it runs on egl/gbm/kms
<tmlind>
so freemangordon: so is glamor doing the GL_CLAMP_TO_EDGE calls?
<uvos>
no
<freemangordon>
yes
<uvos>
we patched that out
<freemangordon>
:)
<freemangordon>
no
<freemangordon>
it turned out it is another issue
<freemangordon>
so I reverted later on
<freemangordon>
just a sec
<uvos>
oh ok
<tmlind>
the CLAMP_TO_EDGE stuff is needed for sure, but i think the real reason wlroots broke is because renderer->egl->procs.eglQueryWaylandBufferWL no longer gets called, and maybe dmabuf now gets wrong params
<freemangordon>
uvos: actually, the issue was that GL_CLAMP_TO_EDGE was not set
<freemangordon>
and some insane default was used, leading to a broken rendering
<uvos>
ok
<tmlind>
freemangordon: also check glamor for GL_EXT_unpack_subimage usage, and compared to the wlroots commit 2ec83ab4f11b above
<uvos>
im honestly pretty hazy on all of this considering the time delta
<freemangordon>
tmlind: sorry, can;t do this ATM, I am on modest :)
<tmlind>
freemangordon: ok just few suggestions on what might cause the issues :)
<freemangordon>
tmlind: glTexSubImage2D is not supported on KHRImage backed texture
<uvos>
GL_EXT_pack_subimage is optional in glamor
<freemangordon>
gimme 5 minutes to grok the commit
<uvos>
glTexSubImage2D(GL_TEXTURE_2D, 0,
<uvos>
x1 - box->x1, y1 - box->y1,
<uvos>
x2 - x1, 1,
<freemangordon>
uvos: unfortunately no
<uvos>
f->format, f->type,
<uvos>
bits + ofs);
<uvos>
well it checks for it and dosent bail
<freemangordon>
it tries to use it and thats the reason why it does not fully work with pvr blobs
<uvos>
tmlind: glTexSubImage2D is not supported on KHRImage backed texture <-- your sure that isent valid
<freemangordon>
it segfaults in the blob
<uvos>
?
<tmlind>
GL_TEXTURE_2D needs to be handled line at a time if no GL_EXT_unpack_subimage
<freemangordon>
uvos: yes, lemme find the specs
<uvos>
tmlind: thats whats happening thera
<uvos>
iirc
<uvos>
it goes for (; y1 < y2; y1++, ofs += byte_stride)
<uvos>
*iiuc rather
<uvos>
i tried compearing the wlroots changes to glamor before
<uvos>
and could not find what glamor is doing different/wrong
<tmlind>
ok
<uvos>
and then i went and tried to check this statement "glTexSubImage2D is not supported on KHRImage backed texture" but came up blank
<uvos>
since you can look at the specs for all of these things but its pretty opaque what can be used with what
<freemangordon>
"There is no support for most of the functions that manipulate other texture targets (e.g. you cannot use gl*Tex*Image*() functions with TEXTURE_EXTERNAL_OES)"
<freemangordon>
because we use glEGLImageTargetTexture2DOES, but with GL_TEXTURE_2D, not GL_TEXTURE_EXTERNAL_OES
<freemangordon>
however, using GL_TEXTURE_2D should fail on gles2, IIUC, but it does not with the blobs
<freemangordon>
but, later on it segfaults in the blob when you try to glTexSubImage2D
<freemangordon>
I am not sure I can explain it any better
<freemangordon>
so, the workaround I was on is to create a texture backed FBO to copy the original texture to and to use glTexSubImage2D on that
<freemangordon>
that was working pretty much ok on d4, however, when I tried on n900, it was hanging the whole device, and this is where I said f**k it and stopeed :)
<tmlind>
heh
<tmlind>
freemangordon: care to post that workaround somewhere?
<freemangordon>
tmlind: so, you you know how *exactly* wlroots fails?
<freemangordon>
tmlind: it was a test program, lemme check if it is in the repo
<tmlind>
weston-simple-egl tries to use some invalid fd and gets: fcntl64(49282, F_DUPFD_CLOEXEC, 0) = -1 EBADF (Bad file descriptor)
<tmlind>
that's the dmabuf breakage, weston-simple-shm and weston-simple-damage work just fine as does sway
<tmlind>
so where's the segfault in pvr_egl_shim then? after the GL_TEXTURE_2D call?
<freemangordon>
I need to boot my d4, I think I have the latest sources there
<freemangordon>
can't recall, sorry
<freemangordon>
oh, no, it was not in the shim
<freemangordon>
but in glamor
* tmlind
has been building countless iterations on d4 of wlroots and sway versions to bisect the issues..
<freemangordon>
it is glamor that tries to use glTexSubImage2D
<tmlind>
ok
<freemangordon>
sorry, have to do some RL work, ttyl
<tmlind>
later
<tmlind>
no idea where weston-simple-egl pulls that bad fd from.. sounds like some bogus dmabuf config
<kona>
Freemangordon yes, currently porting tinymail to gio so I can build modest
inky_ has joined #maemo-leste
lyubov has quit [Ping timeout: 252 seconds]
lyubov has joined #maemo-leste
<freemangordon>
kona: good, though I was able to build TM without this module, shall I push my changes?
<freemangordon>
I added leste as another platform which doesn;t build gnomevfs module
<kona>
Sure, can you show me which repo you are using?
<freemangordon>
Wizzup: what provides calendar applet?
<freemangordon>
oh, it is in extras
<uvos>
so the adress book depends on a specific email client which depends on a calandar widget which is a plugin for a program that depends on hildon-desktop and in turn allmost everything hildon which also depends on the calendar backend
<uvos>
clearly this is not sane and a cut needs to be made in some (or better several places) here