Wayland on Embedded

Abhijit Potnis abhijitpotnis at gmail.com
Fri Jul 13 03:23:18 PDT 2012


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

> 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.
>
> Yup, too early to think abt this !


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

Thanks.


>
> > > 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.
>
>
No, I haven't yet looked into the input part. I will get back to you in
this regards.



>
> Thanks,
> pq
>

Thanks for the help.

-- 
Regards,
Abhijit Potnis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120713/0f865d67/attachment.html>


More information about the wayland-devel mailing list