Compositor for eink device

[Pekka Paalanen]

On Tue, 11 Jun 2013 12:28:21 +0200
Claudius Marpa Heine <claudius.marpa.heine at student.uni-augsburg.de>
wrote:

> Am Dienstag, den 11.06.2013, 12:38 +0300 schrieb Pekka Paalanen:
> > On Tue, 11 Jun 2013 08:44:15 +0200
> > Claudius Marpa Heine <claudius.marpa.heine at student.uni-augsburg.de>
> > wrote:
> > 
> > Hi Claudius,
> > 
> > that is a very cool idea for a project!
> 
> Thank, I like to hear that ;)
> 
> > > 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.
> 
> Do you mean that qt, gtk, efl, etc. which already have support for
> wayland don't work with the tablet-shell and there is no way of
> compiling it with support?  
> And the desktop-shell don't support touch input and has to be broken
> apart to build a more tablet style UI.
> That's misfortune.

There are different things at play here. Both shells consist of several
parts: public Wayland protocol interfaces towards clients, a Weston
plugin, and a helper client (e.g. weston-desktop-shell).

See also
http://cgit.freedesktop.org/wayland/weston/tree/notes.txt

Tablet-shell uses different protocol towards Wayland clients than
desktop-shell. Clients (usually toolkits) need to be explicitly written
to support the shell protocol. This means that tablet-shell has poor
chances of running any desktop applications.

Desktop-shell is what almost everyone writes the toolkit support for,
so that is not a problem. The problem with desktop-shell is that you
need to enhance weston-desktop-shell to use touch input.

> How difficult could it be to add touch input into the desktop-shell?

Not too difficult. You just need to decide how the desktop should
respond to touches, and implement that in weston-desktop-shell. You can
do that in isolation, no need to modify toolkits, protocol, weston, or
weston plugins.

Well, you may need to modify the toytoolkit coming with weston,
since weston-desktop-shell uses it, to add support for touch input. But
I guess if you only need the launcher panel buttons to react to touch,
you could just hack it in clients/desktop-shell.c of weston repository.

Oh, and nothing prevents you from writing a total replacement for
weston-desktop-shell, or forking the desktop shell plugin. So even if
you will be using desktop shell protocol wise, you can still have your
own "desktop".

> Under this circumstances maybe I should take a deeper lock into
> qt-wayland.
> 
> > > 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?
> 
> Yes it's a standard evdev device and udev is available. So input, I
> thought until now, would not be a problem.

Sounds ok, if the touchscreen advertises ABS_MT_SLOT. If it does not,
you get to do some input plumbing in weston, too.

And looking at http://www.chauveau-central.net/pub/KoboTouch/ , there
is no ABS_MT_SLOT. So, maybe a week of work to get that hooked up and
upstreamed.


HTH,
pq