On Fri, 13 Jul 2012 15:20:22 +0530 Abhijit Potnis <[email protected]> wrote:
> Hello Pekka > > 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 ? Let's first have a working backend, and then look at if there is anything worth sharing with other backends. Too many layers is not nice, so maybe we can have helper functions. Anyway, we will see once there is code to look at. I don't think anyone has anything against having more backends, if they're maintained... anyone? > 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. Great! > > 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. http://lists.freedesktop.org/archives/wayland-devel/2012-July/004206.html Do keep in mind, that that patch series was NAK'd. The plan is to fold the udev-evdev stuff into compositor-drm.c. But if you have use for udev-code, too, we have to think about it more. > > 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. Yeah, but do you have udev for discovering input devices, or how is it done? Or do you have input at all yet? By organizing the code I was referring to the udev/evdev and compositor-drm.c plans. If you are going to need udev too, folding it into compositor-drm.c might not be the best option if you could reuse it. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
