Quote:
Originally Posted by Adam B.
Very cool!
How'd you get around the libc issues?
|
hehehe, I didn't, I repeat, DIDN'T port Qt 4, I ported Qtopia 4!
Qtopia is, basically, Qt 4 for embedded devices and instead of running on top of an X server (which on the iLiad is XFBdev, an X server on top of the framebuffer device), Qtopia runs straight on the framebuffer...
This means -> faster GUI -> faster startup times
And this is not all, I hacked around, well basically, added a ton of ARM features to qemu-arm which is now capable of running ARM compiled (with the 'official' iRex OE gcc compiler) applications ON x86 LINUX
So, is it an emulator? Kinda!!!
What you see is:
1) an uname -a of the actual (virtual) machine (i686)
2) in /opt/iliad I have a complete copy of the iliad filesystem and I just ran uname -a again from the command-line (with binfmt_misc you can set a magic sequence so it can identify ARM compiled code and happily runs /usr/bin/qemu-arm which runs the iLiad code unchanged!)
3) I started the Qt4 X11 application qvfb (tweaked for the iliad, just the iliad dimensions and depth (4 bits) as default)... QVfb is a virtual framebuffer for use with Qtopia applications...
4) you see that I run the fontselector example with the runqt script (which just passes a few default parameters so it uses the QVfb framebuffer instead of /dev/fb) and the program shows it's output in the QVfb application. BTW. this and all the other (have tested most of them) examples are actually ARM executables as well....
Where is this leading?
1) An easy to use development environment (Trolltech just released plugins for Eclipse for C++/Java/Qt4/Qtopia/Jambi) without the need to move the programs to the iLiad for testing and debugging the ARM code
- For even faster development you can initially develop your program with a native (for me x86_64) compiled QVfb *and* native compiled Qtopia Core 4 + native app you're writing which performs a lot faster since It doesn't need vmware (needed a 2.4.19 x86 kernel for qemu-arm to work), doesn't need qemu-arm and doesn't use the slowness of it all
- When the app is ready for debugging you start using the qemu-arm + vmware environment
2) Easy and fast GUI applications for the iLiad. I'm actually planning to replace the whole lot, well, I skip the X server and all that stuff and will write my own, better (well, according to my taste), content-lister. My own document plugins (which should render faster), etc., etc.
3) I hope to add Qt Jambi (should be trivial, but you never know) support so we can also use Java as a development language which automatically has the same look and feel as the C++ applications. Oww and yes, I also have a working JVM...
Oww, I almost forgot, the thing with Qtopia is, you can write your own screen driver plugin. I just extended the framebuffer one and actually implemented the dirty rectangle routines which are neatly available in the screen driver interface (which call the iLiad's special update routines) -> no need for patched Xlibs and adding update routines all over the place...
Drawbacks?
- No more stock X apps, but since I prefer KDE over Gnome and since KDE uses Qt as its base I don't see real problems... (just like porting a gnome app to KDE...)
Well, that's it!
Aenea
PS. And to just piss of Mobipocket even more, one of the document plugins will be secure mobipocket in C++. According to Dutch law no-one can prevent me from writing an app which does the same as theirs (I'm allowed to write a DRM circumvention program, but not distribute it, but a viewer contains no circumvention, if the laywers say it is then the original Mobipocket viewer is also prohibited...) only, hehe, faster startup times and faster rendering and, ohh, did you see that font selector demo?