Compositor for eink device

Tue Jun 11 03:16:03 PDT 2013

On Tue, 11 Jun 2013 10:56:49 +0100
martin brook <martin.brook100 at googlemail.com> wrote:

> 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

Ok, only static pseudocolor, of course. Hopefully that matches PIXMAN_g8
format and pixman does the conversion automatically and without too
much hit.

The current pixman renderer in Weston is written for ARGB
compositing of client provided images. It is wasteful to first
composite in ARGB and then convert to grayscale, so if that needs
optimizing, you may need to:
- convert incoming buffers to grayscale and maintain a copy
- modify the pixman renderer to composite in grayscale+alpha, if
  possible
- add a grayscale pixel format to wl_shm protocol (I have planned on
  adding more formats anyway)
- modifying clients to use the grayscale format

But I think it is possible to start with the pixman renderer as is, and
convert to grayscale when copying to the fb.

Cheers,
pq

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