Hello Pekka On Fri, Jul 13, 2012 at 1:30 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 13 Jul 2012 12:58:45 +0530 > Abhijit Potnis <abhijitpot...@gmail.com> wrote: > > > Hello , > > > > 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. > > 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. > 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 ? > > 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. > :) > > 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. > > 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. 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. > > Yes. Could you please point me to these evdev patches. They would be helpfull. > 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. > > The code organization as mentioned by me above is my humble suggestion. I would like to hear your feedback on this. > > Thanks, > pq > PS: I am very naive in this area, pardon me if the above questions sound completely absurd ! -- Regards, Abhijit Potnis
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
