[Community] Report on QtMoko

2016-06-14 Thread Josua Mayer
Greetings to all of you,

I present to you my results from the hacking weekend:
I was working on making it easy to start hacking on QtMoko.

0) Prelude
I intended to make actual debs available, but I have yet to find time
uploading these huge things. For the moment packages will have to be
built from source, as to the instructions in the new repositories linkd
below.

1) Kernel: http://projects.goldelico.com/p/qtmoko2-kernel/page/README/
There is now an easy way to build a kernel deb from whatever release our
kernel hackers deem stable. It is meant to be unpacked on top of a fresh
rootfs.
The idea is that this rootfs should at this point be bootable. However
currently a custom bootargs.scr is required to facilitate looking for
the DeviceTree files in /boot/dtb/. Please find a sample script attached
to this mail.

As you will notice, I did not override bootcmd, but instead manually
implemented the boot procedure. This is not perfect. Ideally this
bootargs.scr would only override the u-boot environment variable that
currently has / and /boot hardcoded as valid sources for DTBs. Feel free
to provide improvements should you find any.

2) Qt-Embedded: http://projects.goldelico.com/p/qtmoko2-qte/page/README/
First, to avoid any confusion: Qt-Embedded is just Qt, but built to
directly draw on the Framebuffer instead of using any of the available
Window Systems of this Universe.
I picked version 4.8.7 as starting point because this one is the latest
stable release of the 4.8 series that QtMoko currently uses.
My goal was to provide Qt as a standalone framework to then later build
QtMoko components against it.
This direction is completely opposite to QtMoko, which has tried to
accumulate every component and library into a single monolithic system.

Currently the Qt-Embedded deb installs itself into /opt in order to not
mess, or conflict with the non-embedded Qt variant provided by Debian.
There are demos installed to /opt/qt-embedded/examples, and I did try
out a few of them. They appeared to work properly, but there is a
problem with touchscreen input:
When touching the screen, Qt properly detects a mouse-press at the right
location of the screen. But then when moving the pointer, it runs away
in a non-linear fashion.
I later concluded that it looks like this:
pos_new = new_absolute_coordinates + distance_to_last_position
This is a serious issue and needs investigating. We suspect that the
Qt-Embedded LinuxTP mouse driver is doing something nasty!

If you want to play around with it, this is how:
# set up environment
export PATH=/opt/qt-embedded/bin:$PATH
export LD_LIBRARY_PATH=/opt/qt-embedded/lib:$LD_LIBRARY_PATH
export QWS_MOUSE_PROTO=linuxtp:/dev/input/touchscreen
cd /opt/qt-embedded/examples
# try out whatever example you like, and dont forget to pass the -qws
commandline option

3) QtMoko itself
Sadly, besides having a perl programmer do a quick scan of its configure
script, we ran out of time before making any notable progress.
There are now 2 optiosn for next steps:
a) try to make QtMoko build itself against the standalone Qt-Embedded,
WITHOUT rebuilding it as part of the qtmoko build
b) identify core components of QtMoko and build them individually

Thats it for now, as mentioned above you can expect an apt repository to
be made available soon(TM).

best regards
Josua Mayer
___
Community mailing list
Community@openphoenux.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.openphoenux.org


Re: [Community] Report on QtMoko

2016-06-14 Thread H. Nikolaus Schaller
Hi,

> Am 14.06.2016 um 16:41 schrieb Josua Mayer :
> 
> Greetings to all of you,
> 
> I present to you my results from the hacking weekend:
> I was working on making it easy to start hacking on QtMoko.
> 
> 0) Prelude
> I intended to make actual debs available, but I have yet to find time
> uploading these huge things. For the moment packages will have to be
> built from source, as to the instructions in the new repositories linkd
> below.

Great work!

> 
> 1) Kernel: http://projects.goldelico.com/p/qtmoko2-kernel/page/README/
> There is now an easy way to build a kernel deb from whatever release our
> kernel hackers deem stable. It is meant to be unpacked on top of a fresh
> rootfs.
> The idea is that this rootfs should at this point be bootable. However
> currently a custom bootargs.scr is required to facilitate looking for
> the DeviceTree files in /boot/dtb/. Please find a sample script attached
> to this mail.
> 
> As you will notice, I did not override bootcmd, but instead manually
> implemented the boot procedure. This is not perfect. Ideally this
> bootargs.scr would only override the u-boot environment variable that
> currently has / and /boot hardcoded as valid sources for DTBs. Feel free
> to provide improvements should you find any.

This will change with latest U-Boot. bootscr is deprecated there and uEnv.txt
will provide just the device tree name.

An example can be seen here fore the Pyra:

http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=Letux/boot-scr/uEnv-pyra%2Blc15.txt;h=ea46c1e9b58eb7e1ab09b0c929ee079a5e86b72a;hb=refs/heads/work/hns/letux-extensions

But all this can be fixed when U-Boot is upgraded at some point in the future
(which needs a little more to be done for the GTA04 to provide touch screen
interface within u-boot).

> 
> 2) Qt-Embedded: http://projects.goldelico.com/p/qtmoko2-qte/page/README/
> First, to avoid any confusion: Qt-Embedded is just Qt, but built to
> directly draw on the Framebuffer instead of using any of the available
> Window Systems of this Universe.
> I picked version 4.8.7 as starting point because this one is the latest
> stable release of the 4.8 series that QtMoko currently uses.
> My goal was to provide Qt as a standalone framework to then later build
> QtMoko components against it.
> This direction is completely opposite to QtMoko, which has tried to
> accumulate every component and library into a single monolithic system.
> 
> Currently the Qt-Embedded deb installs itself into /opt in order to not
> mess, or conflict with the non-embedded Qt variant provided by Debian.
> There are demos installed to /opt/qt-embedded/examples, and I did try
> out a few of them. They appeared to work properly, but there is a
> problem with touchscreen input:
> When touching the screen, Qt properly detects a mouse-press at the right
> location of the screen. But then when moving the pointer, it runs away
> in a non-linear fashion.
> I later concluded that it looks like this:
> pos_new = new_absolute_coordinates + distance_to_last_position
> This is a serious issue and needs investigating. We suspect that the
> Qt-Embedded LinuxTP mouse driver is doing something nasty!
> 
> If you want to play around with it, this is how:
> # set up environment
> export PATH=/opt/qt-embedded/bin:$PATH
> export LD_LIBRARY_PATH=/opt/qt-embedded/lib:$LD_LIBRARY_PATH
> export QWS_MOUSE_PROTO=linuxtp:/dev/input/touchscreen
> cd /opt/qt-embedded/examples
> # try out whatever example you like, and dont forget to pass the -qws
> commandline option
> 
> 3) QtMoko itself
> Sadly, besides having a perl programmer do a quick scan of its configure
> script, we ran out of time before making any notable progress.
> There are now 2 optiosn for next steps:
> a) try to make QtMoko build itself against the standalone Qt-Embedded,
> WITHOUT rebuilding it as part of the qtmoko build
> b) identify core components of QtMoko and build them individually
> 
> Thats it for now, as mentioned above you can expect an apt repository to
> be made available soon(TM).
> 
> best regards
> Josua Mayer

BR and thanks again,
Nikolaus


___
Community mailing list
Community@openphoenux.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.openphoenux.org