On Wed, 21 Nov 2012 12:36:45 +0530 Abhijit Potnis <[email protected]> wrote:
> On Wed, Nov 21, 2012 at 12:23 PM, Pekka Paalanen <[email protected]>wrote: > > > On Wed, 21 Nov 2012 11:38:57 +0800 > > Henius Dong <[email protected]> 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 <[email protected] > > > > <mailto:[email protected]>> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
