Wayland on Embedded

[Abhijit Potnis]

Hello Pekka

On Fri, Jul 13, 2012 at 1:30 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Fri, 13 Jul 2012 12:58:45 +0530
> Abhijit Potnis <abhijitpotnis at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120713/2ba6984a/attachment.html>