Compositor for eink device

[Pekka Paalanen]

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