Compositor for eink device

[martin brook]

Guys Hi,

An interesting area which I've done some work on with a kobo touch, some
useful links at

https://wiki.merproject.org/wiki/Community_Workspace/kobo




On Tue, Jun 11, 2013 at 10:38 AM, Pekka Paalanen <ppaalanen at gmail.com>wrote:

> On Tue, 11 Jun 2013 08:44:15 +0200
> Claudius Marpa Heine <claudius.marpa.heine at student.uni-augsburg.de>
> wrote:
>
> > Hi folks,
> >
> > for my master thesis in computer science I am looking into implementing
> > a wayland-compositor for eink devices (specifically for a Kobo Glo
> > Reader I own).  For the record I am currently only looking into it, so
> > no promises ;)
>
> Hi Claudius,
>
> that is a very cool idea for a project!
>
> > Someone from the mobileread forum already implemented a open source java
> > replacement for the environment [1].  He used the native einkfb library
> > [2] to write into the eink framebuffer.
>
> Ok, looks like fbdev with some extended ioctls.
>
> > I would like to have a "normal" compositor and shell to be able to run
> > gtk or qt applications on the eink device.  I already looked over the
> > weston code and I think that all I have to do is to make a fork of
> > framebuffer compositor where I add eink support and to implement a
> > tablet shell for this device class.
>
> Yes, starting from compositor-fbdev.c is the way to go.
>
> Note, that if you go with tablet-shell, then all toolkits need to
> specifically have support for it. An initially easier route would be to
> bend the desktop-shell to work on the device, though I guess it might
> not be a good match for the user interface paradigm. So I suggest
> starting with desktop-shell, and seeing what you need to break to make
> the UI nice and usable.
>
> > I don't have experience in this field (eink and compositors), but here
> > are some issues I am currently thinking of:
> > 1. eink display should only repaint if something changed and only with a
> > limited fps (if someone get the crazy idea to watch videos with it)
> > 2. repainting should only happen to the area/pixels that changed and
> > every x times repainting the whole display.
>
> Weston already has infrastructure in place to both repaint only the
> damage, and to throttle the framerate all the way down to clients. In
> your backend, you can force a full repaint as needed, I think. You may
> want to look into the pixman renderer and fbdev backend for more
> details.
>
> I looked at the einkfb code, and it seems the wait for screen update to
> complete is blocking. That is not too good, since it would block the
> whole compositor. You may need to put that ioctl into a separate
> thread to have it run async, and then signal the completion. For an
> example of how to handle a completion function call from a different
> thread, see the flippipe code in compositor-rpi.c.
>
> If you can get an event via the device file descriptor, making the fd
> readable when the screen update has completed, that would integrate
> well with the main loop in weston. If not, you need the flippipe
> relay.
>
> > 3. There are many different eink devices with out there. Is there a
> > possibility to write an abstraction layer?
>
> Don't write an abstraction layer as the first thing. When we get the
> third different eink driver for weston, then it becomes possible to
> see if an abstraction could be designed, or if they only want some
> helpers for the common code.
>
> Ideally, there would be DRM/KMS drivers for all eink displays, so a
> user space abstraction would not be needed. How feasible that is, I do
> not know, and I think it would also be out of scope for your thesis.
>
> (DRM/KMS drivers do not *have to* support acceleration, I believe they
> could be written to support only dumb buffers, which are generic.)
>
> > When rendering works I would start working on a tablet shell.
> >
> > Do you have some constructive comments/ideas?
>
> Is the input exposed as standard evdev input devices? Is there udev?
>
> > Do you think this idea is realizable within a master thesis for a
> > beginner like me?
>
> I assume you are fluent in C and familiar with programming on GNU/Linux.
>
> Hmm, master's thesis, i.e. 6 months of work including the literary work
> and writing the thesis. I would say with desktop-shell, no problem.
> Continuing to tablet-shell may be more work than you expect due to the
> client support required. But, the tablet-shell part could rely on the
> toy demos, and show what is possible, even if it does not run gtk and
> Qt apps.
>
> We have been craving for a good example of a completely different
> shell than the desktop oriented ones, to make a point of what shells
> actually are supposed to be. If you could make that point, that would
> be brilliant!
>
> Ah, and another note: the current desktop-shell does not react to touch
> input at all. You may need to pick which way to go, since doing both
> desktop shell with touch and a tablet shell is probably too much.
>
> > [1] http://www.mobileread.com/forums/showthread.php?t=196994
> > [2] https://mediaz.googlecode.com/svn/trunk/ReaderZ/native/einkfb/
>
> If you like Qt, I think it might be possible to use only Qt to write an
> eink compositor, but I don't know much about that. Depends on your
> goals, too.
>
>
> Cheers,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130611/9d726287/attachment-0001.html>