Well, you didn’t bought this fresh mini2440 with a 3,5″ or 7″ touchscreen just for putting another dust receiver on your desk didn’t you ?
If you compiled a kernel from the mini2440 kernel repository with the mini2440_defconfig, the framebuffer driver is loaded by default. You should see an “Armwork” logo when booting your board. If it’s not the case and you have a 7″ screen, you have to pass “mini2440=1tb” as a boot argument for the kernel ( 0 is for 320×240, 1 for 800×480 ). This has to be done in u-boot.
The framebuffer for the screen should be avaiable on device /dev/fb0, if that entry does not exist, you probably want to make it by using the following command “mknod /dev/fb0 c 29 0”. If you wonder why those numbers, well, the major “29” is from the /proc/devices file, there you can see that the major 29 is reserved for fb character devices, and as there is only one fb on the system, the minor is 0, but if you want to make sure of that, all character devices are listed on /sys/dev/char.
If you don’t have anything in /proc or /sys or both, you should mount them by doing:
mount /proc /proc -t proc mount /sys /sys -t sysfs
If you don’t want to be bothered with than anymore, put them in /etc/fstab .
That should be it for the fb.
A nice “s3c2440-ts” driver should also be loaded when booting your board, it is responsible for providing the touchscreen input.
When booting, you can see that message: “input: s3c2410 TouchScreen as /devices/virtual/input/input1”. And indeed, if you go to the directory “/sys/devices/virtual/input/input1” (don’t forget to mount /sys), you’ll see some nice things.
In this folder, 2 directories have interesting names: event1 and mouse0, and both of them have a “dev” file in their content. They contain major:minor addresses of their character devices. Hu ?
event1 provide a “touchscreen” way to access to the touchscreen input while the mouse0 provide another abstraction that show the ts as a mice.
To access them, we have to make a node in /dev as following:
mkdir /dev/input mknod /dev/input/ts c 13 65 # (from event1/dev) mknod /dev/input/mice c 13 32 # (from mouse0/dev)
BTW, I kind of discovered the mouse input after doing what’s next, but I didn’t really had good results with that abstraction.
In order to exploit what’s coming from /dev/input/ts (if you do “cat /dev/input/ts”, you should see some weird characters when touching the screen ), we can use the tslib library.
I followed that howto to cross-compile it.
After the installation, you should be careful with the configuration.
About the ts.conf, I just uncommented “module_raw input”.
About the env variables, I exported as follow at first:
export TSLIB_TSEVENTTYPE=INPUT export TSLIB_CONSOLEDEVICE=none export TSLIB_FBDEVICE=/dev/fb0 export TSLIB_TSDEVICE=/dev/input/ts export TSLIB_CALIBFILE= export TSLIB_CONFFILE=/usr/etc/ts.conf export TSLIB_PLUGINDIR=/usr/lib/ts
As you can see “TSLIB_CALIBFILE” is empty, if you put something in it, all ts_* tools will quit with a nice Seg fault …
Then calibrate your screen with “ts_calibrate /usr/etc/ts.calib” and a stylus. After that, calibration information’s will be stored in /usr/etc/ts.calib, data that you should put in the “TSLIB_CALIBFILE” env var.
If you want a more reliable configuration, put all those vars in the /etc/profile file, this will be load along with bash.
Qt Embedded 4.5
While the qt lib is a nice and heavy piece of work, cross-compiling is actually quite easy.
First you need to download the sources from Qt: http://get.qt.nokia.com/qt/source/qt-embedded-linux-opensource-src-4.5.2.tar.gz (last version here).
Untar it and then go in the directory.
First we need to provide what tools you’re going to use for cross-compiling the thing. On my host I use the toolchain provided by my openembedded installation, thus all my tools are starting by “arm-angstrom-linux-gnueabi-“. You have to modify the file
to express what tools you want to use to cross-compile. Of course you have to do that according to your toolchain.
BTW, if your toolchain is a path that’s only in your user PATH var, you might want to put the full path to your toolchain, otherwise there will be some problems when doing “sudo make install”.
Then, let’s configure:
./configure -embedded arm -xplatform qws/linux-arm-g++ -prefix /usr/local/Qt -qt-mouse-tslib -little-endian
The -prefix is telling Qt that it’s going to be installed in /usr/local/Qt : hu ? When I first compiled Qt, I had my sd card mounted on /media/disk, so I put -prefix /media/disk/usr/local/Qt as an option. While I had no problem for the installation, I had troubles running some examples, as they we’re looking for files in the prefix path and not the real path (which is /usr/local/Qt on the board). I played a bit with the options but didn’t find a nice way to do that, that’s why I did the really ugly hack that’s following. I’m looking for a better solution, so if anyone as any, please mail me …
I simply did a symbolic link from /usr/local/Qt to /media/disk/usr/local/Qt by doing :
sudo ln -sf /media/disk/usr/local/Qt /usr/local/Qt
That’s really ugly cause cross-compilation and virtual installation should be done nicely in userspace, while here I use a system wide path to do the trick.
Then you simply have to do :
make sudo make install
It’s going to take a while so go drink a coffee and remember those nice times when you had fun installing a gentoo from stage1 on a k6-2 …
Then unmount your sd card and boot your board.
You first have to register the Qt lib dir, this two lines should do:
echo "/usr/local/Qt/lib" > /etc/ld.so.conf.d/qt.conf ldconfig
Then, in order to configure QWS to use the tslib driver, you have to
as mentioned in the Qt doc.
And … that should be all.
Have fun with Qt examples, starting by /usr/local/Qt/exemples/qws/mousecalibration in order to make sure that everything is all right.
- Cross-compiling Qt/X11 Article on the Qt dev blog
Please comment this post, if you find any error or improvement I would be glad to take them in consideration