What Will Be The Ui?


icurafu said:
I have a question on memory usage.

I wanna be able to use the entire 128MB of RAM. How much ram will Qtopia consume and is there is option to dump the entire OS memory on full screen apps and then reload when the application is exited?

What would need to be done to dump the ram, do we need to detach from hardware. Can anyone estimate how long this would take? or how many seconds would be added to the execution of each of these high memory consuming applications?
Well if the GUI is more or less the same as a normal lightweight window manager running on X on top of the system like any other Linux box it would be fairly simple just to kill the window manager and just load the required libs for that specific app/game, unless you got a lot of stuff running this should just add a few seconds extra if even that.
Should Also be possible to "hide" the GUI and throw it to a swap of likewise freeing up most of the 128MB, this way you should really be able to use 97-98% of the RAM for the app with just X running behind it, if you don't need X then you should be able to use ~100% of it.

This under the assumption that Pandora will work as any other Linux system.


Qt for Embedded Linux (don't know much about it) has a
Storage footprint dependent on configuration
Compressed: 1.7 - 4.1 MB
Uncompressed: 3.6 - 9.0 MB
 
Last edited by a moderator:
Parkydr said:
I was using the Debian testing distro, but now it says kernel to old on the GP2X. I'll drop back to stable.

Hum isn't Debian testing requiring the EABI and NPTL?
 
Last edited by a moderator:
Laurent said:
Parkydr said:
I was using the Debian testing distro, but now it says kernel to old on the GP2X. I'll drop back to stable.

Hum isn't Debian testing requiring the EABI and NPTL?
No, in Debian terms ARM OABI and EABI are separate architectures. ARM OABI is still supported with EABI also in unstable now IIRC. That said, your quite right to state that most of the development is going into the ARM EABI variant.
 
Last edited by a moderator:
DJWillis said:
No, in Debian terms ARM OABI and EABI are separate architectures. ARM OABI is still supported with EABI also in unstable now IIRC. That said, your quite right to state that most of the development is going into the ARM EABI variant.
Well EABI is better. I guess there's no choice but to stick to OABI for gp2x to keep compatibility. I guess Debian unstable still has OABI for the same reason.

It looks like Pandora will use EABI from the start so it looks brighter here :)
 
Last edited by a moderator:
Laurent said:
Well EABI is better. I guess there's no choice but to stick to OABI for gp2x to keep compatibility. I guess Debian unstable still has OABI for the same reason.
No question about that. Unless the 2X moves to 2.6 wholesale, EABI is a pipe dream ;).

Whilst I have experimented with EABI and 2.6 on the 2X I can't really see any push to move that way (it will upset a lot of compatibility anyway) so I guess the status quo is best maintained.

Laurent said:
It looks like Pandora will use EABI from the start so it looks brighter here :)
It is and always was. I have always been very clear about that :D. Given a choice I would also not build the OABI support wrapper into the kernel. No point promoting the old ways, best to make a clean break (and the OABI wrapper is a bit of a PITA anyway) ;).
 
Last edited by a moderator:
DJWillis said:
It is and always was. I have always been very clear about that :D. Given a choice I would also not build the OABI support wrapper into the kernel. No point promoting the old ways, best to make a clean break (and the OABI wrapper is a bit of a PITA anyway) ;).
I'm all in favor of forcing users and dev's to use new stuff, and the best way is to simply drop obsolete compatibility layers. It's better for them, they just have to learn it the hard way :p
 
Last edited by a moderator:
Laurent said:
I'm all in favor of forcing users and dev's to use new stuff, and the best way is to simply drop obsolete compatibility layers. It's better for them, they just have to learn it the hard way :p
Heh... And people wonder why I keep asking for a gelled firmware environment... ;) B)
 
Last edited by a moderator:
Another option that might be worth to consider:
DirectFB

It is a LGPL library which started as a library around the bare linux framebuffer and input devices.
According to the news it already supports the platform. With some of the extension projects
opengl and X window integration seems possible
 
Well Fltk already supports opengl (inside the windows) ... and version 1.1.7 is quite stable also efltk is being ported back to fltk 1.1.7 as an aditional library (called edelib) that supports nicer themes and intrenationalization IIRC... Personally i think 25mb for a windowing environment is rediculous even if the pandora had 512mb ram cause if say a video editor or image program is made (entirely possible due to the large touchscreen) you are going two want a light windowing system + your ram hog editor program not two ram hogs at once :)

I do remember seeing some nice statistics on DirectFB and GTK ... oh look here they are LOL
http://www.directfb.org/docs/GTK_Embedded/

but anyway i would prefer Fltk over GTK or QT since.... well i can actually understand a little of how to code Fltk in C++

I must admit that Qtopia is prettier than Fltk though X.x LOL well since I doubt it would be all that much trouble to compile Fltk for pandora... so why not offer Both since ede2 + fltk is really small?
 
I'm pretty sure you can just statically compile fltk. It's too small to worry about it.
 
sindbad said:
I'm pretty sure you can just statically compile fltk. It's too small to worry about it.
I'm positive of it. Fltk was originally designed to be linked statically. Reality is, though, if you're going to be
using it all over the place (Including UI code for apps, etc.) you're probably going to want to make it an .so as the code portions will be loaded once for the entire system. As for DLL Hell as it were, that's because Microsoft didn't have the same framework (no versioning present- we have versioning...) and a position that you can't just willy-nilly place your own DLL's everywhere. Dynamic load's not the problem. :D
 
Last edited by a moderator:
I've finally got back to a stable ARM QEMU system,

It uses about 7MB on the GP2X (with fairly large html book loaded).

Here's the pmap for FBReader running on QEMU:

CODE

6330: FBReader -geometry 320x240
Address Kbytes Mode Offset Device Mapping
00008000 7256 r-x-- 0000000000000000 008:00001 FBReader
00725000 32 rw--- 0000000000715000 008:00001 FBReader
0072d000 1040 rwx-- 000000000072d000 000:00000 [ anon ]
40000000 1184 r---- 0000000000000000 008:00001 locale-archive
40128000 36 r---- 0000000000000000 008:00001 gtk20.mo
40131000 24 r--s- 0000000000000000 008:00001 gconv-modules.cache
40137000 4 r---- 0000000000000000 008:00001 libc.mo
4013c000 24 r-x-- 0000000000000000 008:00001 libnss_compat-2.3.6.so
40142000 28 ----- 0000000000006000 008:00001 libnss_compat-2.3.6.so
40149000 4 r---- 0000000000005000 008:00001 libnss_compat-2.3.6.so
4014a000 4 rw--- 0000000000006000 008:00001 libnss_compat-2.3.6.so
4014b000 64 r-x-- 0000000000000000 008:00001 libnsl-2.3.6.so
4015b000 28 ----- 0000000000010000 008:00001 libnsl-2.3.6.so
40162000 4 r---- 000000000000f000 008:00001 libnsl-2.3.6.so
40163000 4 rw--- 0000000000010000 008:00001 libnsl-2.3.6.so
40164000 8 rw--- 0000000040164000 000:00000 [ anon ]
40166000 1052 r-x-- 0000000000000000 008:00001 libc-2.3.6.so
4026d000 28 ----- 0000000000107000 008:00001 libc-2.3.6.so
40274000 8 r---- 0000000000106000 008:00001 libc-2.3.6.so
40276000 4 rw--- 0000000000108000 008:00001 libc-2.3.6.so
40277000 12 rw--- 0000000040277000 000:00000 [ anon ]
4027a000 84 r-x-- 0000000000000000 008:00001 ld-2.3.6.so
4028f000 28 ----- 0000000000015000 008:00001 ld-2.3.6.so
40296000 4 r---- 0000000000014000 008:00001 ld-2.3.6.so
40297000 4 rw--- 0000000000015000 008:00001 ld-2.3.6.so
40298000 1024 rw--- 0000000040298000 000:00000 [ anon ]
40398000 32 r-x-- 0000000000000000 008:00001 libnss_nis-2.3.6.so
403a0000 28 ----- 0000000000008000 008:00001 libnss_nis-2.3.6.so
403a7000 4 r---- 0000000000007000 008:00001 libnss_nis-2.3.6.so
403a8000 4 rw--- 0000000000008000 008:00001 libnss_nis-2.3.6.so
403a9000 36 r-x-- 0000000000000000 008:00001 libnss_files-2.3.6.so
403b2000 28 ----- 0000000000009000 008:00001 libnss_files-2.3.6.so
403b9000 4 r---- 0000000000008000 008:00001 libnss_files-2.3.6.so
403ba000 4 rw--- 0000000000009000 008:00001 libnss_files-2.3.6.so
403bb000 8 r-x-- 0000000000000000 008:00001 ISO8859-1.so
403bd000 28 ----- 0000000000002000 008:00001 ISO8859-1.so
403c4000 4 r---- 0000000000001000 008:00001 ISO8859-1.so
403c5000 4 rw--- 0000000000002000 008:00001 ISO8859-1.so
403c6000 104 r---- 0000000000000000 008:00001 gtk20-properties.mo
403e0000 20 r---- 0000000000000000 008:00001 glib20.mo
403e5000 24 r--s- 0000000000000000 008:00001 a960c40fc9306f090224a04585f8a963-x86.cache-2
403eb000 256 r--s- 0000000000000000 008:00001 eeebfc908bd29a90773fd860017aada4-x86.cache-2
4042b000 64 r--s- 0000000000000000 008:00001 cabbd14511b9e8a55e92af97fb3a0461-x86.cache-2
4043b000 24 r--s- 0000000000000000 008:00001 6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2
40441000 512 r---- 0000000000000000 008:00001 DejaVuSans.ttf
be971000 84 rwx-- 00000000be971000 000:00000 [ stack ]
mapped: 13264K writeable/private: 2228K shared: 392K



Can't see cairo or pango even though they were required for linking.
 
Tom Cooksey said:
Hiya,

I'm a developer working on OpenGL ES integration in Qt/Embedded Linux. One of the main things I'm doing is getting shiny iPhone-like window transitions to work. I was just wondering what people were intending to do for the UI of the Pandora? I'm currently working with an OMAP 3430 SDP development kit, so I'm confident the driver I'm writing for Qt/Embedded will work pretty well on the Pandora, assuming it has PowerVR's SGX Null-Window-System drivers on it.

If no-one has a UI ready, I'd love you to choose Qtopia or some other framework based on Qt/Embedded. I would do my best to support any efforts along these lines too. I can tell you that you should be able to get Compiz/iPhone like window transitions at the very least!
Cheers,

Tom

PS: Sorry if this sounds like a sales pitch!



Tom,

I'm 100% with you. IMHO, QTopia is the BEST GUI (and more!) for embedded devices.

I have cross-compiled QTopia 4.3.0 for my IMX31Lite board -> http://www.youtube.com/user/DrOctavius1
and I was trying to do the same as you (opengles 1.0 and egl driver integration with qt4.3.0), until TI
realesed the OMAP35xx, and now..... I just want a board with that SoC (CORTEX + opengles 2.0) :)

As soon as I get the HW, I can help you if you want ;)
 
Last edited by a moderator:
DrOctavious is the screen on your board bigger than the pandora? Do you thing that the interface is getting in the way any? I mean is are there any improvements on it that come to mind? for instance that scrolling photo viewer is cool but not too good for lot of photos...when your only looking for one.

also does Qtopia have an onscreen keyboerd equivalent to maemo? too bad im on dialup atm will have to check out Qtopia when i have one of those blazing 2mbs college connections handy :)....
 
cb88 said:
DrOctavious is the screen on your board bigger than the pandora? Do you thing that the interface is getting in the way any? I mean is are there any improvements on it that come to mind? for instance that scrolling photo viewer is cool but not too good for lot of photos...when your only looking for one.
The screen in my board is bigger, 10.2" vs 4.3" and both are 800x480.
 
Last edited by a moderator:
Ok, I've compiled qtopia-opensource-4.3.1 for my amd64 gentoo linux desktop. I've got it running but what I see is a mobile phone simulation very similar to symbian os phones. If that is qtopia, I don't see the relation between the pandora and a mobile phone. Perhaps I compiled the wrong one.

But I still can't see how to implement a interface for the pandora using qtopia. I know that the gui can be coded as a typical Qt4 application and then get ported to qtopia.. But I ran an example application on the qvfb, the snake game, and it ran at fullscreen without windows decorations and without application menus, so I thought it needs a "server" application, or am I wrong? Is that thing what confuses me..

(I've already run qtopia using runqtopia script, but I've also run the snake game without running runqtopia nor qpe, only qvfb and snake, so "qpe" is the server I was refering)
 
Qtopia renders straight to the framebuffer, without X. This is not suitable for the pandora, so an Xserver with some GUI made with Qt4 would probably be better.
 
But we still don't know if the pandora will run using the framebuffer or if it will use an Xserver.

Squidge, do you know something about that?
 
I'd like to know the decisions (if any) about this as well. Although I personally think Kdrive would be great :D
 
efegea said:
But we still don't know if the pandora will run using the framebuffer or if it will use an Xserver.

Squidge, do you know something about that?
I don't have anything concrete, but I would suspect it using the frame buffer by default, but having the option of launching the X server for PDA stuff and what not. Maybe. Possibly.

Or in other words, "No, I don't know anything about that" :D

Ask DJW, he's the OS guru ;)
 
Last edited by a moderator:
Back
Top