Dingoo A320 forum

Hello

I managed to compile some apps with openembedded/Angstrom.

I was waiting for the standard rootfs to check that they were running.
In fact this a a bit of a hack but it enables to port applications very easily.

To run applications, I put binaries and all the needed libraries into a 'package' file, which is mounted on a loop. Then I have a wrapper which can launch the binary with the correct environment.

So I have a X server and some applications on top.
I also have 'strace' utility running, which could be usefl for developer.
And also dropbear ssh server.
Why do I need to run an ssh server on the Dingoo? To mount it via sshfs, for instance.

There are some problems left but I think this is a good start.
xmms runs for instance, but is very slow, I don't know why.

But the main problem is that there is no way (for now) to move the mouse pointer, except when connected to the PC.
When connected I can use x2x, which enables the mouse from my computer to control the cursor on the dingoo.

I think this main problem will be solved soon, either with a wrapper, or with a native app.

I plan to put the files somewhere if anyone thinks there is some interest of doing it.

Please see the image below for a shot.


cyberic

X apps on dingoo, looks awesome!

Couldn't understand how you did it (wasn't angstom targeted on ARM devices?)... anyway good job!
What about resources needed? (X ram requirements, libraries dimension)

Mplayer performance/usability? As far as i know we still need a videoplayer for dingux (but i supose it should run on a framebuffer device instead of on top of the xserver).

There are a plenty of useful apps that could be ported now... (xpdf is the first that comes into my mind).

For PDF, actually there is also epdfview:
http://trac.emma-soft.com/epdfview/

In fact I have tried to get the libs and stuff from a running debian, and it works!

So it is event not needed to port apps, we can 'borrow' them from debian directly (at least for some of them, not everything works)

About X, I'll give you the numbers.

But we have 29MB memory available on the dingoo, that leaves a lot of room...

About mplayer, as soon as I scale the video, it is laggy.

But I think it works directly on the framebuffer too, can't test right now.

cyberic99 wrote:About mplayer, as soon as I scale the video, it is laggy.

But I think it works directly on the framebuffer too, can't test right now.

Yes, mplayer can use a framebuffer device as its video output as well as output the video through SDL. Both ways should work on Dingux, but the framebuffer option probably gives the better performance.

cyberic99 wrote:In fact I have tried to get the libs and stuff from a running debian, and it works!

So it is event not needed to port apps, we can 'borrow' them from debian directly (at least for some of them, not everything works)

Do you mean that we can download (at least some) binaries from debian-mipsel repo and get them work on dingoo?

That would be a good reason to port dpkg, too!

Yes, but I think it would be better to use another readonly format. Maybe we could write a deb2goo or deb2doo ... In fact, most applications do not really need to be installed... Most of the time they can be launched on a read only filesystem too
And the worst problem is that symlinks don't work on FAT filesystems
I think that dpkg it too complicated, and we need a simple package format, containing all necessary binaries, libs, and resources.
For now I use romfs images that I mount in loop devices, and it seems to work...

Could you post your builds, and write an how-to for using debian binaries?

OK, there are some limitations left but I'll do than tonight.

At the moment, when dingux boots, it will search and mount every package file in the 'pkg' directory.

But the number of loop devices is hardcoded in the booboo's kernel (should be easily fixable/dynamic with a module)
For now is is 8. And one loop device is already used for the rootfs.

So that means that we can only have 7 packages at the same time.

All of this can be easily worked around/fixed, I'll do it later.

Thanks!

BTW... i still haven't understood why the packages have to be mounted as readonly filesystems...
apart symlinks (and possibly dependancies) couldn't the binaries be excuted from the fat partition, wherever it's mounted?

The fact that they are readonly is not that important. But we have to mount a filesystem that support symlinks, like romfs, ext2... but not vfat.
This is important required the libraries and the linker use symlinks.
Anyway, this could easily be worked around.

But I do not like the idea a the user 'installing' apps.
For instance, on a mac, you don't have to install anything (most of the time)

You just drag the application, which is a single file, et voila!

That is what I'd like to do with packages.

You drag and drop a file, you have a new app. That simple.