Google Summer of Code Ideas
Table of Contents
The following are the ideas for Google Summer of Code. Note that the list is just a starting point. Don't hesitate to add any interesting proposals you would like to work on, or to discuss such proposals in mailing list or IRC.
Bugfixing
Goal: to have a better OpenInkpot.
Required skills: various.
Yes, bugfixing. There are lots of small (or not so small) bugs open in ticketing system, so fixing a bunch of them is always good. There are several pre-made lists of bugs, e.g. errors in rendering various books, bugs in Hanlin V3 or Hanvon N516 support. It is entirely possble to work of various bugs in order to familiarize yourself with codebase.
Mentors: dottedmag, avn, lunohod
Emulator
Goal: to have an easy-to-use e-book reader emulator on PC to ease development and testing
There are (at least) two approaches to creating an emulator: system-level emulator and application-level emulator. You are free to go with any.
System-level emulator
Required skills: hardware/kernel hacking
This variant consists of adding devices or drivers to QEMU to run OpenInkpot under it. There are two variants of accomplishing this task:
- New kernel target "qemu" for OpenInkpot, enabling to run firmware under i386 qemu.
- (+) Emulation is fast
- (+) Existing code for keyboard / touchscreen / network / storage etc may be reused. Only e-Paper specifics should be implemented (delays on screen update etc)
- (-) New kernel target is needed
- Hardware emulation for a device supported by OpenInkpot
- (+) Completely unmodified firmware can be run under QEMU
- (-) Lots of emulated devices need to be added
Mentors: jekhor
Application-level emulator
Required skills: C/Python/shell programming, a bit of Debian packaging
Application-level emulator might consist of:
- a set of mock services providing the same interfaces that the real services on device implement (D-Bus mostly):
- power management
- storage management
- any other services required by applications
- Xephyr server patched to emulate e-Paper specifics
- Glue scripts which set up the mock services and run GUI and application in a chroot.
Mentors: dottedmag, avn
New hardware
Goal: to have OpenInkpot run on more e-Book devices.
Required skills: hardware/kernel hacking.
There is a long list of devices on the hardware page, many of which are not supported by OpenInkpot at all, or with development stalled. Adding a new target to OpenInkpot is a good task which could take up to 3 months or more.
Adding new target consists of the following tasks:
- Adding missing drivers to kernel (either forward-porting code released by vendor, or writing drivers from scratch)
- Adding new target to linux-2.6 OpenInkpot package
- Adding missing drivers to bootloader or figuring out another way to start OpenInkpot
- Producing firmware image by extending build-fw tool
Mentors: jekhor, xl0, lunohod
Transition to OpenWRT
Goal: to make OpenInkpot use OpenWRT as underlying embedded linux distribution.
Required skills: shell programming, OpenWRT hacking.
OpenInkpot has been built upon IPlinux, which is maintained by the OI developers. In order to focus exclusively on e-Books reading experience it would be nice to drop IPlinux and move to OpenWRT.
Following tasks should be accomplished:
- Tweak kernel building from git in OpenWRT
- Move userspace packaging to OpenWRT
- Adjust firmware building
There is more information here: Transition to OpenWRT
Mentors: dottedmag, lunohod
Global search
Goal: to have OpenInkpot index and search books.
Required skills: C programming.
There are several free index/search engines availbale, mostly desktop-oriented. This task includes adaptation of existing index/search engine to the specifics of eBook devices, or writing one from scratch, both the crawler and the UI.
Specifics mentioned are:
- Power consumption. Search engine must carefuly use battery (e.g. indexing only while device does not want to sleep). Additionally there might be a conduit which pre-indexes the files during upload to device.
- Screen specifics. UI for search should be e-Paper friendly. This involves some UI decisions about completion, incremental search etc.
Mentors: dottedmag, avn, lunohod
Boot speedup
Goal: to speed up device boot and also to decrease memory consumption while running
Required skills: shell programming, bits of C knowledge.
SysV initscripts are not really designed for booting mobile devices. It would be nice to replace sysvinit with something more apropriate, e.g. Upstart (if it is small/fast enough for Hanlin V3) or Runit.
While replacing init system it is advisable to get rid of various cruft and leftovers from Debian and also to make sure services run only when necessary (e.g. dropbear stars only after setting up usbnet networking).
Mentors: dottedmag
XKB in ecore-xcb
Goal: to have proper API exoposed for interacting with keyboards of devices.
Required skills: C programming, a bit of Python programming, X11 protocol experience (at least a bit of).
This task spans two projects: Enlightenment and X.org (OI being the indirect beneficiary) and includes the following parts:
- Patching xcb-proto code generator to produce XKB bindings in XCB (X.org)
- Adding XKB support to Ecore_X (xcb variant) (Enlightenment).
Mentors: dottedmag, lunohod
Object-oriented Evas-like glib-based canvas
Goal: to get rid of EFL in long-term and rely on well-known libraries instead
Required skills: software design and architecture skills, C programming
OI uses EFL libraries (Ecore, Evas, Edje, Efreet) for GUI and partially to abstract away the OS. We (devs) don't really like the implementation of the libraries. There was and is an ongoing discussion to replace them as follows:
- Ecore_* -> xcb, glib, gvfs
- Efreet -> glib
- Evas -> pango, cairo, ??
- Edje -> lua, ??
The missing parts are marked as "??" - we need a stateful Evas-like object-oriented canvas and DSL for drawing interfaces, based on glib object model and utilizing well-known libraries instead of home-made stuff in EFL.
The ideas behind Evas are quite good, so they might be used as an inspiration. There are several cairo-based canvases (unfortunately either written in C++ or tightly bound to GTK), and those may be used as a reference.
Mentors: dottedmag
UI policy/mechanisms split
Goal to improve robustness of software Required skills: C programming
OpenInkpot UI is run under root, as lot of system interfaces are only available to root. There are silly helpers and hacks all around necessary to arbitrate several applications' access to hardware.
The situation is quite unhealthy, and refactoring similar to one done on desktop Linux is necessary to resolve it:
- Hardware access should be moved to privileged services (udisks, upower, something else)
- Hardware arbitration should be moved to services too (e.g. upower shall combine "don't sleep" requests and issue single command to hardware)
- UI should be redone to use X and D-Bus services only.
As a side-effect mdev device manager should be replaced with udev.
Mentors: dottedmag
