Re: Scratchbox apt-get update
2007/4/24, Leandro Melo de Sales [EMAIL PROTECTED]: It seems that there is a error in the maemo armel repository since my scratchbox installation can resolve repository.maemo.org, but can't find Packages.gz due to the wrong URL **binary-arm** instand of **binary-armel**. Please, let me know if I am wrong! Ah, no. That's not the repository being wrong, it's your target that is broken (most likely). Apt gets the architechture from dpkg, and apparently it's reporting arm although it should be armel. You can check this with dpkg-architecture. So, it's a debian devkit problem, but as I don't know much about that, I'm not sure about the cause... -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Friday 20 April 2007 10:39, you wrote: The primary conversion we do isn't planar - packed (this is a fallback for when the video is obscured), but from planar to another custom planar format. It would be good to get ARM assembly for the fallback path, but most of the problem when using packed lies in having to transfer the much larger amount of data over the bus. It is only a problem of definition :) Whatever it is, packed or planar, this YUV420 format is not YV12. So it still needs conversion which is performed by only reordering bytes and is not much different from packed YUY2 (except that it requires less space and bandwidth). There's one optimisation that could be done for the YUV420 conversion (the custom planar format that Hailstorm takes), which removes a branch, ensures 32-bit writes always (instead of one 32-bit and one 16-bit per pixel), and unrolls a loop by half. Might be interesting to see what effect this has, but I think it'll still be rather small. My main performance concern is exactly about this 'omapCopyPlanarDataYUV420' function. My experience from Nokia 770 video output code optimization shows that optimization effect can be really huge (it was 1.5x improvement on Nokia 770 for unscaled YV12 - YUY2 conversion going from a simple loop in C to optimized assembly code, I provided a link to the relevant code in my previous post). But N800 code can be probably improved more because now it contains unnecessary branch in the inner loop and branches are expensive on long pipeline CPUs. Such color format conversion performance should be comparable to that of memcpy if done right (it is about half memcpy speed on Nokia 770 for unscaled YV12 - YUY2 conversion). But only benchmarks can be a real proof, any premature speculations are useless and even harmful. Do you remember the times when nobody from Nokia believed that ARM core could be good for video decoding on 770? ;-) Testing with Nokia_N800.avi video on N800: # mplayer -benchmark -quiet -noaspect Nokia_N800.avi BENCHMARKs: VC: 29,525s VO: 15,029s A: 0,453s Sys: 59,919s = 104,925s BENCHMARK%: VC: 28,1390% VO: 14,3232% A: 0,4313% Sys: 57,1065% = 100,% BENCHMARKn: disp: 2511 (23,93 fps) drop: 0 (0%) total: 2511 (23,93 fps) Enabling direct rendering (avoids extra memcpy in mplayer, but requires to disable OSD menu): # mplayer -benchmark -quiet -noaspect -dr -nomenu Nokia_N800.avi BENCHMARKs: VC: 29,826s VO: 12,365s A: 0,437s Sys: 60,555s = 103,182s BENCHMARK%: VC: 28,9058% VO: 11,9833% A: 0,4236% Sys: 58,6873% = 100,% BENCHMARKn: disp: 2504 (24,27 fps) drop: 0 (0%) total: 2504 (24,27 fps) Testing the same video on Nokia 770: # mplayer -benchmark -quiet -noaspect Nokia_N800.avi BENCHMARKs: VC: 44,982s VO: 7,998s A: 0,884s Sys: 47,936s = 101,801s BENCHMARK%: VC: 44,1862% VO: 7,8568% A: 0,8688% Sys: 47,0882% = 100,% BENCHMARKn: disp: 2502 (24,58 fps) drop: 0 (0%) total: 2502 (24,58 fps) So Nokia 770, having slower CPU, slower memory and using less efficient output format (16bpp vs. 12bpp), still requires less time for video output than N800 (7,998s vs. 12,365s). Graphics bus performance is unrelated here as it is asynchronous operation and it is fast enough. Surely N800 also has some extra overhead because of interprocess communication with xserver, but looks like YV12 - YUV420 conversion is quite a bottleneck here too. It should be noted that while Nokia_N800.avi video has low resolution and N800 has no problems decoding and displaying it, our goal is higher resolution videos such as 640x480. Getting to higher resolutions will increase color format conversion overhead. As it can be seen from these benchmarks, video output on N800 takes quite a significant time when compared with time needed for decoding (29,826s for decoding, 12,365s for video output). I can make an assembly optimized code for YV12 - YUV420 conversion. Is there any chance that such optimization could be also integrated into xserver in one of the next firmware updates if it really provides a significant performance improvement? N800 is almost able to play VGA resolution videos properly, it only needs a bit more optimizations. Color format conversion performance for video output is one of the important things that can be improved. So for any performance optimizations experiments which result in immediate video performance improvement, either direct framebuffer access should be used again or it would be very nice if xserver could provide direct access to framebuffer (video planes) in yuy2 and that custom yuv420 format in one of the next firmware updates. The xserver itself should not do any excess memory copy operations as they degrade performance (and it does such copy for yuy2 at least). 'Direct framebuffer access'? As in, just hand you a pointer to a framebuffer somewhere and let you write straight to it? As this would require a firmware update anyway, I don't really see how
Re: Xterm display issue
Hi, ext maldar mateen wrote: Yesterday i installed osso-xterm . I installed it successfully.. when i try to lauch it from the Extras Menu. It says loading xterm and after a second the screen goes off (exits the xterm) with the following error at the console. maemo_af_desktop[4647]: We could not read lowmem page stats. execl: No such file or directory execl: No such file or directory $ man execl ... execl, execlp, execle, execv, execvp - execute a file ... Something (task navigator? D-BUS?) tries to execute something (xterm?), but it doesn't exist where specified or is not executable. this error is for the following reason i suppose error is triggered by the hildon code (hn-wm-memory.c) trying to open lowmem_allowed_pages and lowmem_used_pages in /proc/sys/vm, which are not there. This should not be not serious, AFAIK all allocs / app launching are allowed if these proc files are not found. i don't know wht exactly is missing in the xterm to launch it proerly.. if anyone has better solution or faced the same kind of issue plz let me know. Check what the .desktop file states and check whether you can run the specified executable directly. Or if there's a dbus service specified instead, whether it exists in the D-BUS services and can be executed. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Instructions cache flush on ARM
Hi, ext Siarhei Siamashka wrote: You are right. gcc has function void __clear_cache (char *BEG, char *END) which should be more portable. It should, but it still has the problem of emitting an OABI syscall due to our old gcc. You could use syscall(2) and __ARM_NR_cacheflush instead. Yes, but __clear_cache(char *BEG, char *END) works fine with the current combination of gcc and kernel in maemo. So I guess it's the best option if portability is desired. If you decide to drop support for old ABI from kernel without upgrading gcc, that would be a bug in maemo platform :-) By the way, do you have any plans for upgrading toolchain? Either I'm extremely unlucky, or current toolchain is really very buggy. You can see the known issues from the GCC bugzilla. There are a few bugs in C++ support which have been fixed in gcc 3.4.6 (Maemo toolchain is 3.4.4) or 4.x. It does not support -pg option properly (for profiling with gprof), Hm. The toolchain might not be built with -pg support. As to using gprof, that produces fairly unreliable results. I'd recommend building Oprofile kernel and latest oprofile user-space tools. also I encountered at least one internal compiler error and a couple of invalid code generation bugs already. C++ code generation? Or C? (GCC bugzilla mentions only C++ code generation issues) ICE you can get around by trying another optimization level (sometimes -Os or -O3 works where -O2 doesn't). One more question is about the kernel, ARM11 seems to support unaligned memory access in hardware, but this feature is not enabled on N800. What the seems, to support and feature enabled mean in the above clause? Seems how? And what is result? Enabled what? ARM CPU is able to trap them? Kernel could SIGBUS the co. processes? (as unaligned access has AFAIK undefined results on ARM, is often coding error and fixing those accesses on kernel side has definitive performance penalty) Is it done for consistency with Nokia 770? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: How to Run the Cosole based Application in Maemo
following the thread...would be cool to implement a dbus service for the osso-xterm to emulate the '-e' flag of the rest of the xterms (or just implement -e). --pancake chetan nanda wrote: I am new to this platform and i have done some thread programming and socket programming and now i want to run that on maemo. so how can i run it ... Install xterm-osso and some kind of ssh, e.g. dropbear. Then you can scp your application to the device (you don't need a .deb file) and execute it inside a xterm. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Tue, Apr 24, 2007 at 09:46:52AM +0300, ext Siarhei Siamashka wrote: On Friday 20 April 2007 10:39, you wrote: There's one optimisation that could be done for the YUV420 conversion (the custom planar format that Hailstorm takes), which removes a branch, ensures 32-bit writes always (instead of one 32-bit and one 16-bit per pixel), and unrolls a loop by half. Might be interesting to see what effect this has, but I think it'll still be rather small. My main performance concern is exactly about this 'omapCopyPlanarDataYUV420' function. My experience from Nokia 770 video output code optimization shows that optimization effect can be really huge (it was 1.5x improvement on Nokia 770 for unscaled YV12 - YUY2 conversion going from a simple loop in C to optimized assembly code, I provided a link to the relevant code in my previous post). But N800 code can be probably improved more because now it contains unnecessary branch in the inner loop and branches are expensive on long pipeline CPUs. Such color format conversion performance should be comparable to that of memcpy if done right (it is about half memcpy speed on Nokia 770 for unscaled YV12 - YUY2 conversion). Right, the branch is a problem, and as I said, the branch can be avoided and the writes optimised to be three 32-bit writes for two macroblocks, instead of two 32-bit writes and two 16-bit writes. However, I don't think the lessons from the 770 are necessarily _directly_ applicable to the N800: on the 770, our bottleneck is decoding speed. The bottleneck on the N800 is exactly the opposite: video output. But only benchmarks can be a real proof, any premature speculations are useless and even harmful. Do you remember the times when nobody from Nokia believed that ARM core could be good for video decoding on 770? ;-) Actually, I don't, since I've always mainly worked on the N800. ;) But still, if there's dedicated hardware we can use to remove load from the ARM and let it get on with tasks, and it can perform to an adequate level, there's no reason to avoid it. So Nokia 770, having slower CPU, slower memory and using less efficient output format (16bpp vs. 12bpp), still requires less time for video output than N800 (7,998s vs. 12,365s). Graphics bus performance is unrelated here as it is asynchronous operation and it is fast enough. Surely N800 also has some extra overhead because of interprocess communication with xserver, but looks like YV12 - YUV420 conversion is quite a bottleneck here too. Bear in mind that, unless you explicitly disable it (the Xv attribute is something like XV_OMAP_VSYNC), the X server _will_ flush all pending writes before the next frame is put through. Else you get tearing, because you can be halfway through an update, and writing the next frame to the framebuffer, so which frame is being picked up, changes halfway through. Try forcing XV_OMAP_VSYNC (or whatever it is) to 0, and comparing the results. I can make an assembly optimized code for YV12 - YUV420 conversion. Is there any chance that such optimization could be also integrated into xserver in one of the next firmware updates if it really provides a significant performance improvement? Yeah, if there's measurable benefit, I'll include it. N800 is almost able to play VGA resolution videos properly, it only needs a bit more optimizations. Color format conversion performance for video output is one of the important things that can be improved. I don't believe it's on the critical path. The optimisation I mentioned before will bring us up to the point where any improvement that we can make in that conversion will be eclipsed by the time taken to send it over the bus, I believe. But I can't prove that. Which Epson docs? The one mentioned by Frantisek. Well, it was just a comment for 'omapCopyPlanarDataYUV420' function wrong and misleading, nevermind :-) Now everything is clear. Hmm, is it? Because, unless I was _really_ tired at the time I wrote it (which is entirely possible), that's what the code does, and it works, so ... Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
how to make install package for applications written in python
Hi, Could tell me how to make debian package for python applications? I developed my application using python and not in scratchbox environment. directly edit file and test it in real device. Following the tutorial from maemo.org, I found command dh_make isn't there in device. Thanks in adv. Xi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: how to make install package for applications written in python
Hello, From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Xi Chen Sent: 24 April, 2007 13:11 To: maemo-developers@maemo.org Subject: how to make install package for applications written in python Hi, Could tell me how to make debian package for python applications? I developed my application using python and not in scratchbox environment... directly edit file and test it in real device. Following the tutorial from maemo.org, I found command dh_make isn't there in device... Are you editing the file directly on the device then? I think you can create the package on your Linux machine as it does not include executable binary files, to my understanding it does not require scratchbox, so I think you can run the dh_make on your PC without scratchbox. From current sources, you could take some configuration package (which does not include executable binary files) as an example and do the same thing in your package. Best Wishes, Karoliina http://www.karoliinasalminen.com/blog Thanks in adv. Xi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Need a help --- osso-xterm running problem in scratchbox
Hi, This is chetan.I am new to the maemo and i have developed one console based programs of simple threads its works fine in linux and now i want to run same program in maemo. So i have installed osso-xterm package in scratchbox and got the X terminal option in maemo's Extras menu. Now whenever i click that x terminal option . its lauches the x terminal and within a fraction it disappears. and the foolowing error shows on the screen. maemo_af_desktop[4647]: We could not read lowmem page stats. execl: No such file or directory execl: No such file or directory I searched everywhere and try all possible solution but still i am not able to sort out this problem. so can anyone help me to sort out this problem chetan - Check out what you're missing if you're not on Yahoo! Messenger ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
problems with wxWidgets installation
Hello! I'm trying to build an application, which uses wxWidgets. I have certain problems with proper installation of wxWidgets (N800): http://maemo.org/maemowiki/LibraryCatalog#head-a it says they must be in /usr/lib however the wx-config is the symlink to /usr/local/lib/.. If I install everything into /usr/local/ wxrc fails with code 1. Thanks, Daniil. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: problems with wxWidgets installation
Hello, And if everything is in /usr/lib and /usr/bin with manually corrected symlink, a configure script is unable to find headers for XRC. wxrc still fails with code 1. Thanks, Daniil. On 24/04/07, Daniil Ivanov [EMAIL PROTECTED] wrote: Hello! I'm trying to build an application, which uses wxWidgets. I have certain problems with proper installation of wxWidgets (N800): http://maemo.org/maemowiki/LibraryCatalog#head-a it says they must be in /usr/lib however the wx-config is the symlink to /usr/local/lib/.. If I install everything into /usr/local/ wxrc fails with code 1. Thanks, Daniil. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Instructions cache flush on ARM (was: N800 Video playback)
On Mon, 2007-04-23 at 21:09:26 +0300, ext Siarhei Siamashka wrote: On Monday 23 April 2007 16:49, Guillem Jover wrote: You are right. gcc has function void __clear_cache (char *BEG, char *END) which should be more portable. It should, but it still has the problem of emitting an OABI syscall due to our old gcc. You could use syscall(2) and __ARM_NR_cacheflush instead. Yes, but __clear_cache(char *BEG, char *END) works fine with the current combination of gcc and kernel in maemo. So I guess it's the best option if portability is desired. That it works fine now does not mean it's the correct solution. Also I disagree on the premise that it's more portable, both solutions are quite non-portable, either you'll have to check if that function is present in autoconf or similar, or you'll have to check for the presence of the syscall NR on arm. If you decide to drop support for old ABI from kernel without upgrading gcc, that would be a bug in maemo platform :-) No, because as this is coming from gcc it gets embedded in the actual object, so it would need a recompilation, I wouldn't say that's a bug in maemo, you have hardcoded OABI calls in your object files. Also that makes it more difficult for people to flash their own new kernel. regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: how to make install package for applications written in python
Ola, Could tell me how to make debian package for python applications? I developed my application using python and not in scratchbox environment. directly edit file and test it in real device. Following the tutorial from maemo.org, I found command dh_make isn't there in device. did you mean this? : http://maemo.org/platform/docs/pymaemo/python_maemo_howto.html You need to write a Makefile to act as an interface between the Debian package system and your setup.py []'s Ian -- .''`. : :' : `. `'` `- Orgulhoso ser MetaRecicleiro http://ianlawrence.info http://manaus.metareciclagem.org/ Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: libcairo 1.4.4 and poppler 0.5.4 available
On 4/23/07, Eduardo Lima [EMAIL PROTECTED] wrote: Hi all, The packages for libcairo[1] and poppler[2] are available in the extras repository for both OS2007 (bora) and and OS2006 (gregale). If you find any bugs, please mail me. More to come soon. :) This is great news! It's nice to see cairo become a first-class citizen of Maemo. This will definitely open up some new possibilities for application developers. A cairo-based hildon theme would be fun, too. Best regards, Etrunko. [1] http://cairro.freedesktop.org [2] http://poppler.freedesktop.org That's http://cairo.freedesktop.org, not 'cairro', obviously. http://cairographics.org works too. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: libcairo 1.4.4 and poppler 0.5.4 available
On 4/24/07, Daniel Amelang [EMAIL PROTECTED] wrote: [1] http://cairro.freedesktop.org [2] http://poppler.freedesktop.org That's http://cairo.freedesktop.org, not 'cairro', obviously. http://cairographics.org works too. Dan Indeed. Thanks for the correct link. :) -- Eduardo de Barros Lima INdT - Instituto Nokia de Tecnologia [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
