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