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 <div class="gmail_extra"> <div class="gmail_quote">On Wed, Nov 21, 2012 at 1:03 PM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On Wed, 21 Nov 2012 12:36:45 +0530 Abhijit Potnis <<a href="mailto:abhijitpotnis@gmail.com">abhijitpotnis@gmail.com</a>> wrote: > On Wed, Nov 21, 2012 at 12:23 PM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>>wrote: > > > On Wed, 21 Nov 2012 11:38:57 +0800 > > Henius Dong <<a href="mailto:donglw@pset.suntec.net">donglw@pset.suntec.net</a>> 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 <<a href="mailto:donglw@pset.suntec.net">donglw@pset.suntec.net</a> > > > > <mailto:<a href="mailto:donglw@pset.suntec.net">donglw@pset.suntec.net</a>>> 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 > > > > < > > <a href="http://lists.freedesktop.org/archives/wayland-devel/2012-September/005324.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2012-September/005324.html</a> > > > > > > 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. </div></div>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 </blockquote></div> -- Regards, Abhijit Potnis </div>