Hello Pekka <div class="gmail_quote">On Fri, Jul 13, 2012 at 1:30 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"> On Fri, 13 Jul 2012 12:58:45 +0530 <div class="im">Abhijit Potnis <<a href="mailto:abhijitpotnis@gmail.com">abhijitpotnis@gmail.com</a>> wrote: > Hello , > </div><div class="im">> Is there any plan to have(& maintain) a GLES2 >> framebuffer back-end for > Weston on the weston git, so as to have Weston run on hardware's that do > support GLES2 on framebuffer ? > Say for example ARM targets like the beagle-board. I know that the GLES2 >> > framebuffer implementations would become redundant once the hardware > vendors > start supporting wayland on their boards. But it would still serve the > purpose of running/testing weston (and a few software rendered apps) on > hardware that > don't yet have support for Wayland from the vendor. </div>Hi Abhijit, the problem with GLES2-on-fb is that the APIs involved are not standard, so there cannot be a single backend for all such cases. The DRM backend relies on DRM, Mesa and GBM, and the Android backend relies on Android libs. </blockquote><div> Ya, I do agree. With GLES2-on-fb we would end up having an implementation for each board or for a group of similar boards. My question is, can it be possible that generic part of GLES2-on-fb be separated out and only the system specific part be implemented for each different board. Say like in case of android, what lies in compositor-android.c except for config creation part is pretty much generic and it may work on few other common set of systems other that google nexus ( Android & other flavours of linux as well ). And the implementation which is in android-framebuffer.cpp would be categorised as the system specific one. Can there be an abstraction in the above said way ? And would Weston git be ready to accommodate several such back-ends for numerous boards ? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Even when hw vendors do start supporting Wayland, that will probably mean the client-server interaction, which is standardised. The server-fb interaction will likely still require some special code, as I'm not convinced everyone would start writing DRM-drivers for their gfx hw. </blockquote><div> </div><div>:) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> What you *can* do, is write a new Weston backend and send it upstream. There is already a backend for Android, which has nothing to with DRM or Mesa. </blockquote><div> I was able to write a back-end for my system. Its minimalist but none-the-less, works! There are few more glitches that I have to sort and I am looking into them. I shall put it across once they are completely tested. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I set up the Android backend code so, that most of it can be built without an Android tree, and it is built by default. That will at least keep the code building, when someone changes Weston's generic parts, but cannot try it on Android. Although the major reason why that happened was that Android libs are C++, and I couldn't do without a conversion layer. For input devices, we can share the existing evdev code, if your hardware has evdev input drivers in the kernel. I sent a patch series recently to implement that for the Android backend, but I need to redo it. </blockquote><div> Yes. Could you please point me to these evdev patches. They would be helpfull. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Does your embedded system have udev or not? If it does, and you are serious about writing a backend, we need to re-think with krh how to organise the code. </blockquote><div> The code organization as mentioned by me above is my humble suggestion. I would like to hear your feedback on this. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Thanks, pq </blockquote></div> PS: I am very naive in this area, pardon me if the above questions sound completely absurd ! -- Regards, Abhijit Potnis