<phh>
is it usual to say egl while it requires gles?
<lurchi__>
egl and gles are different things, but both refer to GL on embedded platforms
<lurchi__>
egl: buffer/surface/window setup
<phh>
not really, you could very well have egl but not gles, and gles without egl (though the later is not speced)
<lurchi__>
phh: yes
<phh>
then calling something "egl" while requiring gles, is a bit weird
<LongChair>
it's an RFC, i'm pretty sure there will be tons of comments as usual :)
<LongChair>
but i need that one to get in before i can get the drmprime -> drm atomic one in
<phh>
mmm what's drm atomic?
<LongChair>
it's a new API that extends the DRM old legacy one
<lurchi__>
kms atomic mode setting?
<LongChair>
not only modesetting
<LongChair>
DRM atomic allows to work on multiple drm planes within the same vsync update
<LongChair>
so you can change overlays & primary buffers in one operation (which legacy doesn't allow)
<phh>
and this API will be accesssible from other programs than compositor?
<LongChair>
so in short we can have video coming from vpu displayed at the same time as primary buffer is rendered with gl and blend them
<phh>
or mpv will be able to give a plane to compositor with this?
<LongChair>
yes it is
<LongChair>
that is what wayland uses as a basis
<LongChair>
but you don't need compositor in that case
<LongChair>
there could probably be some vo_wayland extension now that wayland provides also a dmabuf API
<LongChair>
but i probably won't handle this :)
<LongChair>
my need is to blend libmpv with something else that uses GL mostly
<phh>
so at that point, a wayland compositor will be able to be always sleeping, because the sync will be done by the kernel, and the kernel already has all the buffers?
<LongChair>
if one would use the dmabuf wayland API yes
<phh>
ok, I see
<LongChair>
but DRM atomic api can have only one master
<LongChair>
so it's either mpv in my case or weston in wayaland case
<LongChair>
the general principle is setting properties on objects rather than calling drm legacy
<phh>
and everything is ok in mainline to have drm atomic on rockchip?
<LongChair>
and the committing your work, but there is only one commit per vsync, so there need to be someone that handles the atomic request creation & commit
<LongChair>
phh: atomic support is already in 4.4, mainline has a few more properties, but didn't check how it worked under mainline
<LongChair>
i'd like some of the mainline property to be backported, but that's another stiry :)
<LongChair>
story*
<phh>
mmm ok, from what I remember, android's compositor's drm backend uses per-soc ioctls, so I guess they need to switch to this
<phh>
ok thanks
<phh>
oh right, you need 4.4 for video decode
<LongChair>
yes
<phh>
well and rk3328 is not too great in mainline atm
<LongChair>
sorrowfully, but i don't expect this to change much until v4L2 driver is made
<LongChair>
and V4L2 API is still missing a few bits for v4L2 driver to be started afaik
<LongChair>
i mean for decoding
<phh>
mmm, from what I understood, they seemed to be moving out of v4l2, to a simple drm+ioctl driver