Wayland on Embedded

[Pekka Paalanen]

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.

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 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.

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.


Thanks,
pq