Wayland on Embedded

[Pekka Paalanen]

On Fri, 13 Jul 2012 15:20:22 +0530
Abhijit Potnis <abhijitpotnis at gmail.com> 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