Wayland on Embedded

Tue Nov 20 23:40:23 PST 2012

For the convenience of those who didn't witness yesterday's IRC.
Yes, a blog-worthy topic.

<*madeeha*> Hi
<*madeeha*> Is it possible to write an egl native wrapper for Wayland for a
closed source driver.
<*madeeha*> I want to keep the native implementation shm based like in mesa
which supports both
<*madeeha*> shm and drm.Is it possible without availability of the egl
source code of the driver?
<*pq*> madeeha, it all depends on whether your proprietary graphics stack
offers anything that allows you to implement graphics buffer sharing
<*pq*> madeeha, that's for Wayland clients. Are you talking about clients
or servers? They have different requirements.
<*pq*> madeeha, also what do you mean by shm in this context? Using a
rendering API with EGL, copying the image into an shm buffer, and sending
that to a server?
<*madeeha*> pq: only Wayland client. On the server side, we are managing
with fbdev. (i am using the genivi layer manager wayland plugin which
allows compositor to work with fbdev)
<*madeeha*> on the client side, there is an egl/wayland client
<*madeeha*> pq: hence the need for egl native for wayland
<*madeeha*> pq: can we have the egl native on shm like in mesa/gallium
native_wayland.c with native_shm.c
<*madeeha*> ?
<*pq*> err, I still don't quite get the question, maybe because I'm not
familiar with native_shm.c of Mesa. But I would bet, that any Wayland shm
in Mesa is only for software renderers.
<*pq*> madeeha, so, you would basically want to have Wayland clients, that
use EGL and hardware rendering, to work on your platform, right?
<*pq*> Wayland client support in EGL has two parts: the client side which
is the EGL Wayland platform + wayland-egl API, and the server side which is
basically the EGL_WL_bind_wayland_display extension or something to the
same effect
<*pq*> how the server renders itself, using EGL, fbdev, or whatever, is not
too relevant, as long as it is compatible with the way you implement the
EGL_WL_bind_wayland_display-equivalent
<*pq*> madeeha, can you explain in more words on what you want to do, and
what is the "egl native" you refer to?
<*madeeha*> pq: yes sure, so we have Wayland client applications that use
GLES as rendering api ... but the graphics stack has no EGL Wayland
platform available
<*pq*> right
<*madeeha*> pq: the graphics stack supports EGL fbdev platform
<*pq*> the first thing to get such client apps going, is to find a way you
can pass graphics buffers from one process that renders into it, to another
process that uses it (as a texture or putting it into an overlay or hw
compositor or...)
<*pq*> step 2 is creating a Wayland protocol extension for the buffer
passing
<*madeeha*> pq: for the first thing, can't SHM buffers be used if the
compositor can handle those?
<*pq*> then, try to integrate it into your compositor and the client side,
perhaps in a libEGL wrapper
<*pq*> madeeha, most likely not: buffer that a GPU renders into, are
usually badly suited for CPU usage, or impossible to access directly. Hence
you would be forced to do a copy, like glReadPixels, into an shm buffer
before sending it to the server.
<*madeeha*> pq: that is what we are doing on compositor side :)
<*madeeha*> oh sorry
<*madeeha*> pq: please ignore my last comment
<*pq*> heh
<*pq*> such glReadPixels kind of a copy is a huge performance hit, and then
if your server is again using GLES, you have to do glTexImage2D, which is
another copy between CPU and GPU domains.
<*pq*> the best thing would be to find a way to avoid both such copies, and
pass the buffer directly, e.g. by passing some handles so you don't have to
copy
<*pq*> that is what the wl_drm protocol extension does
<*madeeha*> pq: things are much clearer now ..
<*pq*> great :-)
<*madeeha*> pq: for wl_drm, the graphics driver has to be drm , right?
<*pq*> yeah, wl_drm has been designed for the Linux DRM stuff
<*pq*> you could design your own protocol extension for the same purpose
<*madeeha*> pq: thanks so much!
<*pq*> I once made a protocol extension for passing buffers in Android
<*madeeha*> pq: do you think i should get some suggestions from your
Android branch? .. i browsed it a bit
<*madeeha*> will that help in my situation
<*pq*> hmm... maybe not before you know about your own graphics platform
<*pq*> madeeha, the key problem is to find what your handles would be, ans
how you create and use them.
<*pq*> then, passing then through the Wayland protocol, carried by an
extension, should not be a big problem.
<*madeeha*> pq: true, i will investigate on that side now. thanks

On Wed, Nov 21, 2012 at 1:03 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed, 21 Nov 2012 12:36:45 +0530
> Abhijit Potnis <abhijitpotnis at gmail.com> wrote:
>
> > On Wed, Nov 21, 2012 at 12:23 PM, Pekka Paalanen <ppaalanen at gmail.com
> >wrote:
> >
> > > On Wed, 21 Nov 2012 11:38:57 +0800
> > > Henius Dong <donglw at pset.suntec.net> wrote:
> > >
> > > > Hi Abhijit
> > > >
> > > > -----Original Message-----
> > > > From: Abhijit Potnis
> > > > Sent: 2012/11/20 15:04
> > > >
> > > > > On Mon, Nov 19, 2012 at 3:34 PM, Henius Dong <
> donglw at pset.suntec.net
> > > > > <mailto:donglw at pset.suntec.net>> wrote:
> > > > >
> > > > >     Hello Abhijit
> > > > >
> > > > >     I saw the topic "Wayland on Embedded" in wayland-devel mailing
> > > list.
> > > > >     I'm interested in this topic too. But, I'm naive in this topic
> now.
> > > > >     So, I write a mail to you to see whether you could give me some
> > > > >     hints or not?
> > > > >
> > > > >     Now, I'm going to port the wayland onto freescale iMX6 board.
> It
> > > > >     supports Linux/WinCE/Android OS. I want to use the Linux OS
> > > > >     "without" DRM support. So, it going to be difficult to use the
> > > > >     compositor-drm.
> > > > >     But, freescale offers the GLES2 implementation. So, I wonder I
> > > might
> > > > >     need the same GLES2 >> framebuffer back-end.
> > > > >
> > > > >
> > > > > Freescale iMX6 driver releases do show that they now support drm in
> > > > > their kernel. You may want to try that.
> > > > > But as such writing a GLES2 over FB backend will work, but with
> > > > > restricted features as listed in the
> > > > > below mail chain. With much of the work now abstracted by
> > > gles2-renderer
> > > > > (gl-renderer as its called now) , it must be simple enough to
> write the
> > > > > back-end.
> > > > Thanks for your information. I would confirm with Freescale.
> > > >
> > > > >
> > > > >     Could you give me some help?
> > > > >     Anything is welcome.
> > > > >
> > > > > This will be of some help
> > > > > <
> > >
> http://lists.freedesktop.org/archives/wayland-devel/2012-September/005324.html
> > > >
> > > > I've checked this mail chain. The "restricted features" you
> mentioned is
> > > > I won't able to run GL client by using GLES2 over FB backend, right?
> But
> > > > since iMX6 has the DRM support, using DRM backend may be easier.
> > >
> > > Whether or not Wayland clients that use GL will work, essentially
> > > depends on libEGL, and not really about the backend the compositor is
> > > using. In fact, client support and compositor backend are orthogonal.
> > > They only need to be compatible in the sense, that what clients
> > > provide, the compositor can use.
> > >
> > > LibEGL is the standard place to implement the support for clients that
> > > use GL, but nothing prevents you from inventing your own way, if you
> > > control all the applications. Qt5 AFAIU supports its own thing, and so
> > > it is not dependant on libEGL's Wayland platform support.
> > >
> > > The Freescale driver release does have a few Wayland definitions
> > in their header files. But no document explaining if they support
> Wayland/
> > Weston. Also there is no explicit mention from freescale that they have
> >  Wayland EGL platform ( wayland-egl API) implemented.
> >
> > Correct me if I am wrong, with this scenario: we will have to end up
> > writing a
> > EGL wrapper for their proprietary driver to handle buffers. Or invent
> ones
> > on way.
>
> You're probably right. But the very first thing you have to do is to
> find out, if there is a way to pass gfx buffers from one process that
> renders into it, to another process that uses it as a texture or
> pushes it to the screen somehow. Once you know that, and know what the
> buffer handles are, you can start looking at how to use a Wayland
> protocol extension to send buffer handles, and then how to wrap it all
> in your own libEGL.
>
> Déjà vu, I think I just explained the same thing to someone on #wayland
> last evening. :-P Clearly a blog-worthy topic...
>
>
> Thanks,
> pq
>

-- 
Regards,
Abhijit Potnis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20121121/d09ff211/attachment.html>