Re: replacement for wl1251-cal
Hi, On 08/03/2012 11:03 PM, ext Jonathan Wilson wrote: 6.My tool may leak resources (e.g. not closing handles properly) where the Nokia tool does not (or in some cases the Nokia tool may leak resources that my tool does not) AFAIK there are no known leaks with these Nokia tools. To measure and graph resource usage changes in the whole system, you can use sp-endurance: http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance-postproc The docs for the newer Harmattan version are here: http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Performance_testing_tools_Using_sp-endurance.html http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Performance_testing_tools_Using_sp-endurance-postproc.html To analyze the leakage... If it's about memory, Valgrind Memcheck and Massif tools might help you if pointers are lost or leak is large: http://wiki.maemo.org/Documentation/devtools/maemo5/valgrind For smaller and non-memory leaks sp-rtrace functracer are most likely best alternatives: http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Debugging_tools_Using_functracer.html http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Debugging_tools_Using_sp-rtrace.html http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Developer_tools_Debugging_tools_Using_sp-rtrace-visualize.html Sources for the sp-* tools are here: https://maemo.gitorious.org/maemo-tools (Debian/Maemo packaging is typically in the maemo-packaging branch.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N950 SEGFAULT - help?
Hi, On 11/06/2011 01:03 AM, ext Nicolai Hess wrote: 2011/11/5 Felipe Crochikfel...@crochik.com Unfortunately It didn't do the trick I can't tell any difference ...still crashes with the QPainter::save() Please let me know if any of you have any more ideas... I will play a little more tomorrow. Note that in general GL context should be dropped in applications when they aren't visible. Main exception for this rule are plain GL games because they cannot do this easily and user isn't typically running many such games at the same time, like could be the case with normal apps. This is because GL contexts are severely limited resource and after system runs out of them, any new processes just abort/crash on startup because GL init fails. Dropping GL context on background should happen automatically for most MeegoTouch and QML applications. If you're directly using GL operations in such applications without taking this account, and e.g. trying to do GL drawing in the background, funny things may happen. - Eero Felipe 2011/11/5 Kristóf Timurti...@sch.bme.hu That’s not how it’s done. 1. In your .pro file, add: QT += opengl 2. at the top of your cpp, add: #includeQGLWidget 3. when you initialize your QDeclarativeView: QGLWidget glWidget; QDeclarativeView view; view.setViewport(glWidget); Cheers, Timur *From:* Felipe Crochikfel...@crochik.com *Sent:* Saturday, November 05, 2011 11:26 PM *To:* nicolaih...@web.de *Cc:* maemo-developersmaemo-developers@maemo.org *Subject:* Re: N950 SEGFAULT - help? Nicolai, I tried the application using (I assume that is what you meant): QApplication::setGraphicsSystem(opengl); and haven't been able to crash the application but it gets really slow and unresponsive. Also I get these error messages on my log: Valid eglHandle received but not running with meego compatible graphicssystem. Any ideas? Thanks, Felipe 2011/10/7 Nicolai Hessnicolaih...@web.de Have you tried to use a QGLWidget for the qmlviewer ? This works for the QML Camera element which has the same behavior, segfaults when application moved to background. 2011/10/7 Felipe Crochikfel...@crochik.com That is the next problem. They are not available - maybe I need to add some extra repository? sorry if I missed some obvious development required step It is hard to start over! 2011/10/7 Daniil Ivanovdaniil.iva...@gmail.com apt-get install libqtwebkit4-dbg or apt-get install libqt4-webkit-dbg. 2011/10/7 Ивайло Димитровfreemangor...@abv.bg: Why not install Qt debug symbols on the device and run/attach to your program there under gdb? Оригинално писмо От: Felipe Crochik Относно: N950 SEGFAULT - help? До: maemo-developers@maemo.org Изпратено на: Петък, 2011, Октомври 7 05:20:55 EEST I hit a wall with my application so I am looking for someone to help everywhere I can. The short version: how can I get qt creator to debug my application on the device. Right now I get CRC mismatch warnings for all libraries and I assume this is what prevents me to see any trace information That is what I get when I start to debug: ... the debug information found in c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvrPVR2D_DRI2WSEGL_r125.so does not match c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvrPVR2D_DRI2WSEGL.so (CRC mismatch). the debug information found in c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvr2d_r125.so does not match c:/qtsdk/madde/sysroots/harmattan-nokia-meego-arm-sysroot-1134-slim/usr/lib/libpvr2d.so (CRC mismatch). ... I assume I need to install debug symbols/versions for the qt libraries on the device somehow. Am I right? How can I accomplish this? The long version: My applications uses qml\webview and everything works fine until I swipe out of my application and then later come back to it. With one click or two I get a segfault. This is all the information that I managed to get running gdb on the device: (gdb) backtrace #0 0x42068924 in QPainter::save() () from /usr/lib/libQtGui.so.4 #1 0x48ec294c in ?? () from /usr/lib/libQtWebKit.so.4 #2 0x48ec294c in ?? () from /usr/lib/libQtWebKit.so.4 Program received signal SIGSEGV, Segmentation fault. Any suggestions? Thanks in advance, Felipe ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers Can you give a link to your source. nicolai
Re: Aegis - Upstart script not working in Harmattan
Hi, On 08/05/2011 09:17 AM, ext Sudheer K. wrote: Thanks a lot Tumi. The upstart script is finally working. I ran /etc/init/xsession/app-precheck.sh and it gave errors on script, if, fi and end stanzas. I removed all of them and just called another shell script using exec. Here [1] is the final upstart script that worked. Thanks again for your help. Just a note for others creating custom upstart scripts, the upstart script in /etc/init/apps folder is started almost 1 minute (or more) after device is booted and applications become ready for use. There are quite a few apps that are pre-started[1], additional things are run after the standard pre-started apps have been started, otherwise those additional things could slow down their startup. [1] See: ps|grep prestart|grep -v invoker (Several of these are started before desktop is up, but most are started after that.) - Eero This made me think lot of times that the syntax in upstart script is incorrect (even though it is perfectly fine). ~Sudheer [1] - http://pastebin.com/sYrq4ss6 On Wed, Aug 3, 2011 at 12:15 AM, Tuomo Tanskanent...@tumi.fi wrote: Hi, Like I said, there is restrictions. In week 22 build, any violation causes outright reject. IIRC (cannot verify right now) there is script called /etc/init/xsession/app-precheck.sh that checks the job validity. Run that and it'll let you know whars wrong. (that script is gone in later builds, btw and no job is rejected but just sanitized.) Most likely your error is in using script stanza, which in week 22 was restricted (no longer in later). Workaround would be avoiding script in job, but using exec stanza and doing scripty things in separate scripts (like exec /usr/bin/start-daemon.sh and pre-start exec /usr/bin/prestart-daemon.sh etc) Its clumsy, but luckily fixed already. Initctl commands identify jobs by path, excluding leading /etc/init/ and trailing . conf so in 3rd party app case start and stop commands look like: start apps/jobname Hope this helps. Writing long answers on mobile+vkb isn't that handy :-) Cheers, Tumi On 3.8.2011, at 7.54, Sudheer K.scifi1...@gmail.com wrote: On Tue, Aug 2, 2011 at 2:29 AM, Tuomo Tanskanen t...@tumi.fi t...@tumi.fi wrote: (Posting from mobile, excuse top post) Hi, Harmatran has Upstart 1.2 and since 0.5 the init job directory has been /etc/init/ . /etc/event.d/ is not used. This is the main reason for your failure. Secondly, in SDK docs (dunno URL) it is suggested that 3rd party apps are installed to /etc/init/apps/ which is dedicated for this purpose and which imposes couple limitatations to jobs in it. There has been changes in those since n950 sw version and latest internal builds. I think Aegis might prevent your job to be run from /etc/init/ so you should install to /etc/init/apps/. Most notably, jobs launched from there cannot have start on stanza, but they're executed at end of boot sequence. Hope this helps. Cheers, Tumi Hi Tumi, Thanks for your response. I changed my upstart file and deployed the file to /etc/init/apps. This time there are no errors while deploying or in the syslog, but the job is not started. I am using build 1.2011.22-6_PR_RM680. Is there a way to troubleshoot or solve this? I tried to start the job manually by using start shake2skip-daemon command but it fails with error Unknown job. Here is the job configuration [1]. Any thoughts? ~Sudheer [1] -http://pastebin.com/zbfBtt5fhttp://pastebin.com/zbfBtt5f ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt application crashes after 2 minutes if started from app grid
Hi, On 05/09/2011 08:44 PM, ext Timur Kristóf wrote: On 05/09/2011 04:43 PM, Kimmo Hämäläinen wrote: If you don't use D-Bus at all, you need to implement this single-instance and window raising yourself. This can be easily done with the QtSingleApplication class. If that works by starting a new instance of the application which them notices that it's already running and exits, that makes window topping a really heavy operation... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Hi, (I resurrected this old thread because there was on meego-dev mailing list a comment about possibility for RunFast float mode being enabled by default on MeeGo...) ext Alberto Mardegan wrote: Eero Tamminen wrote: Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Wed, 2010-03-10 at 12:57 +0100, ext Alberto Mardegan wrote: Not the libosso osso_fpu_set_mode() function? I can't find this in libosso.h. :-( It's defined in osso-fpu.h (since summer 2009): http://maemo.gitorious.org/fremantle-hildon-desktop/libosso/blobs/master/src/osso-fpu.h If somebody's using a lot of floats (RunFast mode affects only floats) and they're a bottleneck, it would be interesting to know how much this (setting the RunFast mode at program start) helps. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Crash reporting
Hi, ext david.hag...@gmail.com wrote: There's been a Crash reporter available for several years Maemo releases, it's even open sourced: http://wiki.maemo.org/Documentation/devtools/maemo5/crash-reporter http://repository.maemo.org/pool/maemo5.0/free/c/crash-reporter/ I have never been able to get this to work: Every time I have a crash report and try to submit it, I get a Nitro: Failed to connect error. I've tried having the network up, but looking at the tcpdump's it looks like all I am getting it errors from the server. Please file a bug. Note that one can also have a private crash uploading server. Just provide a suitable (trivial) settings package for crash reporter which tells where to upload the cores and preferably also sets crash reporter include/exclude files in /etc so that only your program's core dumps get uploaded to that server. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Crash reporting (was: Package promoting)
Hi, ext Naresh Mehta wrote: Good comments on both the sides. Some of the points made by developers are very valid. But a query though. Why can't Maemo make a crash reporting system like the one Android has? There's been a Crash reporter available for several years Maemo releases, it's even open sourced: http://wiki.maemo.org/Documentation/devtools/maemo5/crash-reporter http://repository.maemo.org/pool/maemo5.0/free/c/crash-reporter/ However, the collected crash information isn't publicly available because crash data (coredumps[1], logs etc) can contain private information (passwords, URLs etc). Because of this, the program will show a prominent warning about this when it's installed and asks confirmation before uploading each core dump. The crash information wouldn't usually be that useful for the 3rd party developers because their packages create rarely debug package needed for getting backtraces (Maemo infra doesn't create those automatically as it's Debian derived. RedHat and Ubuntu package building infra create those automatically though if developer has built his sources with debug symbols). In short, a crash reporting system like Android Do you have a link to what kind of information their crash reporting system provides for 3rd party developers and users? - Eero [1] On Maemo5 and earlier ARM versions use of minimal crash information wasn't possible like on Desktop Linux systems because getting backtraces out of ARM binaries core dumps needed debug symbols (which aren't installed on the devices). Harmattan Meego toolchains can will automatically generate unwind tables for all binaries. With those it's possible to get working backtraces on the device even without debug symbols (debug symbols are then needed only to resolve the backtrace addresses to correct function/method names, but this can be done outside the device). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libesd -- sound in Fremantle
Hi, (replying to this old mail) ext Graham Cobb wrote: On Wednesday 02 September 2009 11:50:17 Graham Cobb wrote: However, there is no libesd for Maemo 5. esound is the debian package which builds libesd. Anyone feel like volunteering to build a libesd from esound? If not, I will have a go later once I have got the rest of GPE running on Fremantle. OK. I have sent a cut-down esound package to the autobuilder and libesd0 and libesd0-dev are now in Fremantle extras-devel. Of course, I have no way of knowing whether it works without a device -- someone can try it when gpe-calendar is available. Pulseaudio should be used for sound output on Fremantle. Note: using Alsa directly isn't good as it skips the speaker protection algorithms in pulseaudio. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
Hi, ext Attila Csipa wrote: On Monday 20 September 2010 17:35:34 you wrote: There are some potential downsides for just suspending processes completely. Most of the processes have subscribed to several different D-BUS messages, X events etc. For example D-BUS will infinitely buffer messages that are sent to a connected client but not read by it. If these messages can be very frequent (say device orientation network condition messages), this will soon bloat D-BUS memory usage quite a bit. After D-BUS Hmm... the external launcher that suspends is meant for apps that cannot really handle/listen to dbus in the first place - if they can, they should react to the lose-focus / screen off messages directly, not through intermediary daemons, right ? All UI apps (including SDL games) get focus events and can react to them. If e.g. game continues although it's not focused i.e. user cannot interact with it, that's pretty bad usability. But games ported from Desktop might still be showing e.g. some pause animations when they aren't focused. If they aren't on D-BUS, suspending might be an OK hack for them. IMHO it's better to fix the program properly though, but that takes more time... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
Hi, ext Andrew Flegg wrote: On Sun, Sep 19, 2010 at 17:58, Robin Burchell virot...@viroteck.net wrote: Anyway: this was pretty much in keeping with my idea: move it into the task switcher (hildon-desktop/other) so that applications which are moved to background are stopped (unless they signal for whatever reason that they need to be kept running, but I'm not even sure that is necessary: if you really need to do background processing constantly, why do it in a GUI application?) I suggested something similar three years ago (wow, Maemo's old ;-)) and the reaction was less favourable: http://www.gossamer-threads.com/lists/maemo/users/26337 For example, Igor Stoppa wrote: You are proposing a shortcut that is encouraging crappy code to be written, since the system will always take care of saying: psst, pretend to be a properly written piece of code. If an application has nothing to do, it _must_ be blocked waiting for something, such as an event, a timer, whatever it cares about, nothing else. Personally, I think it'd still be useful; without going to the (almost) co-operative multi-tasking of iOS. There are some potential downsides for just suspending processes completely. Most of the processes have subscribed to several different D-BUS messages, X events etc. For example D-BUS will infinitely buffer messages that are sent to a connected client but not read by it. If these messages can be very frequent (say device orientation network condition messages), this will soon bloat D-BUS memory usage quite a bit. After D-BUS starts to swap, it won't perform very well. These kind of services cannot be restarted without restarting the whole device (as all connected clients would exit), so there's no easy fix for that effect either, like there's for example for a leaky in-process 3rd party Home applet (restarting Home). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: X server / RECORD extension problem (Xnee)
Hi, Vollmer Marius (Nokia-MS/Helsinki) wrote: Tamminen Eero (Nokia-MS/Helsinki) eero.tammi...@nokia.com writes: When I do: dpkg -x xnee_3.02-2maemo2_all.deb . all I see is some docs It's a virtual package depending on the actual binary implementation package. Virtual packages don't exist as archives, they are only mentioned in Provides. (Sometimes there is a virtual package with the same name as a real package, but that is best avoided.) Sorry, I forgot virtual package has a specific meaning in Debian. Anyway, xnee is a package that doesn't provide the functionality itself, but through its dependencies. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: X server / RECORD extension problem (Xnee)
Hi, ext h...@mail.sandklef.com wrote: Can't install it:( dpkg --install xnee_3.02-2maemo2_all.deb Selecting previously deselected package xnee. (Reading database ... 52579 files and directories currently installed.) Unpacking xnee (from xnee_3.02-2maemo2_all.deb) ... dpkg: dependency problems prevent configuration of xnee: xnee depends on cnee | gnee; however: Package cnee is not installed. Package gnee is not installed. dpkg: error processing xnee (--install): dependency problems - leaving unconfigured Errors were encountered while processing: xnee If you use dpkg you (of course) need to install also the package dependencies. Apt pulls the deps too. When I do: dpkg -x xnee_3.02-2maemo2_all.deb . all I see is some docs It's a virtual package depending on the actual binary implementation package. /hesa Hi, ext Henrik Sandklef wrote: just compiled and tested GNU Xnee* on Maemo. Replaying key/mouse events (Key Press/Release, Motion, Button Press/Release) worked fine. When it comes to recording I don't get any data although RECORD extension is there in the X server. Does anyone know if there's anything strange with RECORD extension in Maemo's X server? There have been known issues also with upstream X server in this respect. See the freedesktop.org bugzilla. I don't remember in which versions of X they were fixed (and there were some workarounds for Xnee too I think). /hesa SW info: - Xnee: 3.06 (tweaked for Maemo) X: Nokia / 10699001 N900: 10.2010.19-1 Is there some problem with the current xnee/cnee packages already in Maemo: http://maemo.org/packages/view/xnee/ http://wiki.maemo.org/Documentation/devtools/maemo5/xnee ? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to get crash stack trace in Maemo 2.2 (Nokia 770)
Hi, ext Alexandre Fayolle wrote: Oh, I was not clear about this : I'm a linux coder, and I have not yet started coding on maemo but intend to do so soon (hence my subscribing to this list). Sorry for throwing you on a path harder than it seamed. OTOH, compiling strace should not be a problem as it is a very classic Unix tool, available in all the distributions for all the platforms. Maybe you can even grab a precompiled Debian package and install it. Debian version is probably ABI incompatible and lacking some ARM support (depending from which Debian version you take it). Strace binary source packages are already in the Maemo SDK tools repository. If not for 770, take the source package from later Maemo version build that. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to get crash stack trace in Maemo 2.2 (Nokia 770)
Hi, ext Han wrote: On Tue, Aug 31, 2010 at 8:37 AM, Eero Tamminen eero.tammi...@nokia.com wrote: I tried Valgrind, and it did report memory leaks. However, most are from gtk/gdk libs and not obvious to me if something is wrong in my program. For example: ==19494== 2,356 (256 direct, 2,100 indirect) bytes in 1 blocks are definitely lost in loss record 5,620 of 5,662 ==19494==at 0x4024D12: realloc (vg_replace_malloc.c:476) ==19494==by 0x4747951: ??? (in /usr/lib/libfontconfig.so.1.3.0) ==19494==by 0x47483C7: ??? (in /usr/lib/libfontconfig.so.1.3.0) ==19494==by 0x4748A0B: ??? (in /usr/lib/libfontconfig.so.1.3.0) ==19494==by 0x4748A4F: ??? (in /usr/lib/libfontconfig.so.1.3.0) ==19494==by 0x473CE25: FcDefaultSubstitute (in /usr/lib/libfontconfig.so.1.3.0) You can probably ignore all fontconfig leaks. Fontconfig does stupid pointer tricks (uses offsets instead of actual pointers) so that Valgrind cannot know whether fontconfig still retains a pointer to its allocations. Note that after you've fixed some leaks, Valgrinding again may reveal new leaks, Valgrind doesn't always see all leaks when there are lots of them. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to get crash stack trace in Maemo 2.2 (Nokia 770)
Hi, ext Alexandre Fayolle wrote: On Tuesday 31 August 2010 09:07:01 Han wrote: Hi, I am using Maemo 2.2 to develop some programs for Nokia 770. Things run pretty well except sometime my program would crash for unknown reason. Normally I start the program from x terminal, and it would crash with only message Killed. I am wondering if possible to get a stack trace when the program crashes? so that I can find out where the crash happened in the code. This looks like the executable was killed by the OS. This can happen on Linux because of memory exhaustion (Out Of Memory killer: see e.g. http://linux- mm.org/OOM_Killer for more information on that). I'd advise monitoring memory consumption of your program. And Valgrinding it on x86 to see what kind of memory leaks and other issues it has. You could also use strace to check what's happening in your program and what signal is received which causes termination. The OOM Killer uses SIGTERM, which your program can intercept if its memory consumption is not a bug. Kernel OOM killing doesn't use SIGTERM and isn't interceptable, for a good reason. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Horrible performance of GL rendering; why? (Qt, N900)
Hi, ext Robin Burchell wrote: Also note that pushing rotation updates every 10ms means you're trying to push 100fps (1000ms in a second, 1000/10 = 100), which is faster than the eye can percieve, and also faster than hardware can usually manage. 60fps is usually the upper bound, and anything over that is generally not going to be noticed except as additional burden on the system. Yes, LCD is refreshed at ~60fps so anything over that is just stupid. Trying to push more frames than the can actually go through the graphics pipeline can support, can noticeably slow down / stall things. If the app is non-fullscreen (= composited), the limit must be much lower (at least down to 30fps), otherwise compositor won't even get the boxed XDamage events for all the updates (X boxes them together). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to catch “lock screen event”?
Hi, ext Xin Zhang wrote: I'm developing a game for n900 using SDL. How do I catch system events (like lock screen switch turned on/off, screen gets locked automatically, or incoming call during game play)? Right now when the game is running, I could not catch the system events (like lock screen switch turned on/off, screen gets locked automatically, or incoming call during game play). Therefore, the game is still active running even screen is locked. I hope I can catch these system events and make the game paused. Could anyone give me some direction in fixing the problem? I've posted a thread in [http://talk.maemo.org/showthread.php?t=59238]. Many thanks! Your window loses focus and it isn't anymore the topmost window. When the screen is blanked, there's additionally also a D-BUS message. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to block the camera app from starting on lens cover open
Hi, ext Martin Storsjö wrote: On Sat, 24 Jul 2010, Yves-Alexis Perez wrote: On ven., 2010-07-23 at 19:20 +0300, Martin Storsjö wrote: Any hints on how to solve this in the best way? I don't want my app to fail in the next QA round with the reason camera app is launched and closes immediately if the lens cover is opened while your app is running. Did you check how fcamera is doing it? Thanks for the pointer! It seems that the FCam library kills camera-ui using dsmetool - which totally makes sense for an application that tries to grab the camera button for itself, too. And what happens in the application crashes without restoring camera-ui, user needs to reboot to get camera working again? - Eero (better may be a small wrapper / watchdog for the process that does the camera-ui removal before launching the program and restores it after the program terminates?) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras QA checklist
Hi, ext Thomas Perl wrote: 2010/7/22 Eero Tamminen eero.tammi...@nokia.com: [1] For example popular gPodder application is buggy because it apparently listens to orientation changes when it's not visible and does e.g. lots of operations when user tries to answer a call. If you reported a bug against said app, the developer would know about it ;) Sure, but such bugs should be done by somebody using gPodder, I've never tried it myself (sorry). I just bumped in bugs.maemo.org into an issue resulting from the bg activity by gPodder and some other apps. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 upgrades
Hi, (commenting on this old mail...) ext Martin Grimme wrote: the N810 supports over-the-air updates since Diablo OS. So there's no need for flashing for an update. Maemo5 does not run on the N810. Although 3D is given as one reason for this, I think Fremantle memory usage and N810 having only half the RAM in N900 would actually be bigger obstacle. Fremantle apps take about 2x more memory than Diablo ones, partly due to compositing used by the desktop, partly due to panning buffers etc. The closest you can get is the alternative Mer OS As to the community efforts, I think the Fremantle features that would be most beneficial for the N8x0 base system would be: - replacing JFFS2 with faster and less RAM using UBIFS[1]. This would require kernel upgrade and remaking/reflashing the rootfs image. - using swap partition from a memory card instead of a swap file on FAT file system. This would be much more robust. - replacing Busybox with a newer version in Fremantle (using the Diablo configuration though) to make it more compatible with Debian stuff. [1] For full file systems. Unlike JFFS2, UBIFS doesn't keep the whole file system in RAM so it uses less RAM, and it also mounts full file system _much_ faster than JFFS2. However, there are some gotchas when moving from JFFS2 to UBIFS (writeback/synching, space accounting), mentioned here: http://www.linux-mtd.infradead.org/doc/ubifs.html which tries to backport Maemo5 stuff onto a Ubuntu based OS running on the N810. With Ubuntu's base memory usage, that seemed a bit strange choice. (I've never tried Mer though, this was just idle speculation) It's still in an early stage, though. But now that Mer people have changed to base things on MeeGo, maybe the base system memory usage is less of a concern. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: X server / RECORD extension problem (Xnee)
Hi, ext Henrik Sandklef wrote: just compiled and tested GNU Xnee* on Maemo. Replaying key/mouse events (Key Press/Release, Motion, Button Press/Release) worked fine. When it comes to recording I don't get any data although RECORD extension is there in the X server. Does anyone know if there's anything strange with RECORD extension in Maemo's X server? /hesa SW info: - Xnee: 3.06 (tweaked for Maemo) X: Nokia / 10699001 N900: 10.2010.19-1 Is there some problem with the current xnee/cnee packages already in Maemo: http://maemo.org/packages/view/xnee/ http://wiki.maemo.org/Documentation/devtools/maemo5/xnee ? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sp-endurance and device memory usage
Hi, ext Dawid Lorenz wrote: PR1.2 fixes last known wakeup-on-background issue in microb engine (related to animated images, reported also to upstream mozilla). When I last tested Fennec few months ago on my N900, it was constantly waking up on the background, so I would suggest at least closing it when you don't use it. Is there a way to determine if application is waking up in the background constantly? Check whether the value in TIME+ column changes in the htop output. Attach to the process with strace -f -p PID[1] and see whether it does anything. [1] htop has s keyboard shortcut to trace processes, but it doesn't give the -f option so that all process' threads would be tracked. Upstream htop seems to have a bug about this: http://sourceforge.net/tracker/?func=detailaid=2987532group_id=108839atid=651635 (htop and strace are both available from the SDK tools repo.) I might be wrong, but I think I've seen that issue about Fennec somewhere and have a feeling it got addressed. Well, certainly many issues in Fennec were addressed, as the latest beta (and nightly builds) are actually usable and not that terribly slow as version 1.0 final and earlier. If you check this, please tell whether it's (fully) fixed now. :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sp-endurance and device memory usage (was: Why should I write apps for Maemo?)
Hi, (CCing to maemo-devel as this might contain useful info also for others.) ext Dawid Lorenz (maemobile) wrote: There's one thing missing from these graphs - Modest. I am pretty sure it could have major impact on memory usage/performance. Or maybe I'm wrong? sp-endurance in the public repositories lists only processes that are both present in multiple endurance snapshots and which memory usage changes. In your data, the Modest PID changed in every snapshot. To see a summary of the leaks, look at the summary sections at the end of the HTML files. The leakers differ after you had rebooted the device (e.g. systemui doesn't leak nearly as much). Hmm... could systemui be related with the way I lock my device, ie. using power key button doble-click? I sometimes do that, but not always. Apparently it leaked (very, very little) whenever it was topped or lock/unlock was used, both of these issue are fixed in PR1.2. Before that's released, systemui should be safely killable ( auto-restarted) as long as you don't do it too often in a row. You could try whether killing the leakers you see in the endurance report help with the device usability. Except for things like X and D-BUS, killing them should usually just re-start them (when needed), not cause device reboots. :-) I just killed addressbook-factory and that instantly released 8% of swap space! Killing off browser browserd release another 2%. I try killing off pulseaudio and mafw wrapper once I get home and stop listening to the music as I type this email on the train ;) (Note to others: addressbook-factory, browser ui and mafw-wrapper memory leakages are fixed in soon-to-come PR1.2. Pulseaudio memory usage is dependent on what it's clients do.) Btw, what exactly is browserd for and is there a way of completly turning it off There's a master browser daemon for quickly forking pre-initialized browser engine instances. Then there are separate pre-started browser engines for Browser and Messaging apps. Without pre-starting, the startup would take close to 10s. (if for example I decided to switch to Fennec completely)? PR1.2 fixes last known wakeup-on-background issue in microb engine (related to animated images, reported also to upstream mozilla). When I last tested Fennec few months ago on my N900, it was constantly waking up on the background, so I would suggest at least closing it when you don't use it. Note that worse than something using a lot of memory, is it being active and using it also on the background like Fennec does (I've also noticed Maep to do that, I've filed Garage bugs about that)... It's useful to check occasionally with top whether some application you left on background is active or not. If it is, without a good reason, please file a bug. Of the pre-installed apps, browser stops activity 1/2 min after going to background (this www-page JS timers disabling timeout is configurable from Browser options), and media player of course continues playing music on bg, but everything else should stop working once it's finished what user asked it to do. Could be. Maybe you could run mem-cpu-monitor from the sp-memusage package in XTerm and ask it to track pulseaudio to catch what causes it to grow? Wow, that mem-cpu-monitor is very nice tool. Like it. I need to get my head around all these tools at some point, however I might just stick to endless (?) wait for PR1.2 first, just to see whether leaking issues have been indeed ironed out in that release. :) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto grab all Maemo5 zoom key events in SDL/SDL_gles app?
Hi, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Sun, 2010-05-02 at 13:26 +0200, ext Till Harbaum / Lists wrote: i'd like to access the zoom keys in a SDL/SDL_gles app (the 3d globe i uploaded to extras-devel). The odd thing is that my solution only partly works. Some key presses actually reach my app as function key presses, but still most of them reach the volume control. So when repeatedly pressing the zoom buttons my app zooms but also the volume is changed. I am using the following code which is inspired by code from scummvm. I am calling this code once immediately after the SDL setup is done. Any idea why this still delivers some key events to the volume control? It could be that _NET_ACTIVE_WINDOW or MB_CURRENT_APP_WINDOW on the root window does not correspond to your window. The volume app is tracking one of these (I think _NET_ACTIVE_WINDOW) to determine the window whose ZOOM_KEY window property matters. Maemo SDL doesn't seem to set all required window properties for fullscreen windows for tracking of the topmost application to work properly. See this bug: https://bugs.maemo.org/show_bug.cgi?id=6175#c3 xprop -root produces this when there's a fullscreen SDL window: _NET_ACTIVE_WINDOW(WINDOW): window id # 0x3e2 _MB_CURRENT_APP_WINDOW(WINDOW): window id # 0x3e1 I.e. for SDL applications the value in these properties differ, unlike for normal applications. _MB_CURRENT_APP_WINDOW is the fullscreen SDL window and _NET_ACTIVE_WINDOW is the non-fullscreen SDL window. (I think SDL uses fullscreen window for output and non-fullscreen one for input.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why should I write apps for Maemo?
Hi, ext Dawid Lorenz wrote: On 7 May 2010 09:48, tero.k...@nokia.commailto:tero.k...@nokia.com wrote: Very good point, seriously. Yet I think Marcin had ever better: (Hm. Is Maemo showing its Debian roots?) Good attempt for joke but failed. Debian has 'testing' branch which users can use, test, report bugs against and got them fixed before release. Maemo does not give any of those. I'd really love if we would have something like that. (No idea how, I'm not related to how our releases are done.) There can always be some regression that's slipped through our (extensive) internal testing. Some kind of a monthly developer snapshot would help in catching those. Releasing test-and-strictly-developer-aka-geek-oriented images on regular basis would be simply great. Think of it like extras and extras-testing/devel - yet not for apps, but full-blown OS images. Normal users should strictly stay away from these, but whole bunch of geek folks who imho are the essence of Maemo/MeeGo platforms would jump high in joy and that would definitely keep guys on both sides of the fence relatively happy. Just my three cents. Btw, I am also uber-eager to see PR1.2 on my device, especially after seeing what Eero said about Browser and performance, as currently I simply need to reboot my N900 every 5-6 days to keep my sanity while using it... Several of the 3rd party things leak memory and especially if that happens with a 3rd party in-process home applet, the result is not pretty in long run... But you can get rid of the memory usage by restarting the process. If the issue is with Browser, just kill it and it will be restarted, just don't start it too many times in a row or you trigger SW watchdog. Browser can with long time usage also cause some swap fragmentation (= extra swap activity), you can get rid of that also by restarting it. If the issue is with hildon-home (plugin), you need to stop and start it with the dsmetool SW watchdog, plain killall hildon-home would cause Home to think that there was some stability issue with applets and disable 3rd party plugins (to prevent restart/reboot loop). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why should I write apps for Maemo?
Hi, ext Dawid Lorenz wrote: On 10 May 2010 14:09, Eero Tamminen eero.tammi...@nokia.commailto:eero.tammi...@nokia.com wrote: Actually, what I'd love to be able to do is simply flush swap space periodically. I've noticed that once swap space usage passes approx. 20%, device gradually becomes unbearable with regular day-to-day usage, hence reboot is essential. I think the problem you're getting that almost all of that 20% is fairly actively used. Rest of the swap is mainly useful for the cases when there's just a very temporary large memory need, or for applications that leak large amounts of memory they'll never again touch. Manually restarting /etc/init.d/tablet-browser-daemon doesn't help much, yet it seems that browsing web is quite sluggish regardless of restarting browserd. I'd simply like to know the way to release swap space somehow, instead of rebooting device. Something that could help slightly is disabling pre-starting for applications that you don't use. Comment out the pre-starting lines where appropriate: grep Prestarted /usr/share/applications/hildon/*.desktop Perhaps restarting some other services? sp-endurance is created for catching things that leak resources: http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance-postproc Probably the best way to use it in your case is to write a small script that takes a snapshot to some directory under MyDocs every night (untested): -- snapshot.sh --- #!/bin/sh # take endurance snapshot once a day while true; do save-incremental-endurance-stats /home/user/MyDocs/endurance sleep $((24*60*60)) done -- Then run it as root, so that it gets started first time some time at night (let's assume night is in 6 hours): # sleep $((6*60*60)); ./snapshot.sh The reason to take the snapshots at night is that usually the device is then in consistent state, apps aren't actively used etc. Best would be if you could always leave the device to same state for the night. After device starts to be slow (you said 5-6 days?), post-process the data: parse-endurance-measurements /home/user/MyDocs/endurance/1* And see what processes it reports to be growing in memory usage. If the process specific bar charts show something going to swap and coming back from there, it means that this amount of memory is actively used, not just dormant. The other option is tell specific core (like phone app) applications to be never swapped away, yet I don't know whether that's possible at all. This is already done to a reasonable level with memory locking and the policy daemon. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why should I write apps for Maemo?
Hi, (standard disclaimer: below are my personal opinions) ext Michael Cronenworth wrote: At most, the SDK should have been released two weeks ahead of the final release. Agree. With a little over a month now on the clock, people can only begin to speculate as to how poor Nokia's release management is working. Releases are not based on calendar, but on them being ready, based on testing results. (Hm. Is Maemo showing its Debian roots?) I, as a software developer, realize that unexpected issues can occur causing unexpected delays, I think it's mainly due to wanting something that doesn't have any known regressions in any area from the previous release while significantly[1] improving some areas. And this requiring somewhat unexpected amount of iterations. As one example, when we optified some of the rootfs content to make more space on it (for SSUs), we had to deal with the slowdowns coming from those packages being now on eMMC (which is slower than rootfs especially when the device is swapping). This required quite a lot of iteration on what to optify, SSU issues, policy memory locking finetuning, otherwise optimizing slow things etc. Another example, which some might think funny, is Browser related. Browser + Flash combination had some crashes which were fixed (because UI restarts engine automatically, user might not even have noticed these except as larger browsing slowdown). However, with the fixes single Browser engine instance could keep up so long that several days of Browsing increased its memory usage a lot. Which then caused performance issues... Finding that this was one cause for longer term usage slowdowns took quite a while, as did hunting down[2] and fixing these previously unnoticeable[2] memory leak(s). We also wanted to fix all the SGX related issues, but I think one is going to be left after PR1.2 as it's not reproducible. A lot of other SGX issues that were eventually to some extent reproducible by someone internally, either with specifically crafted test-case or some already existing SW, have been already fixed in internal PR1.2 releases. [1] While some things are obvious, improvements in some other areas aren't necessarily directly visible to (all) users, because many of the issues we've fixed (use-time, reliability etc), happen only in very specific conditions or use-cases. -Is PR1.2 still going to be released? Definitely. - Eero [2] In case somebody hasn't hunted down Mozilla memory leaks, maybe mentioning these gives some light on it: - Valgrind doesn't produce very useful results with it because of the JavaScript (and multiple Flashplayer) interpreters - Browser is an application doing both largest number and largest total amount of allocations of the applications in the device and those are completely controlled by content on the www-pages and this content changes[2] from one page refresh to another. [3] If testing would use just static browser content, it would miss new issues with latest real live web content. Non- changing test content can find just regressions. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is it possible to use SCHED_FIFO policy on N900?
Hi,
ext tarantism wrote:
On Mon, 2010-04-26 at 16:19 +0300, Eero Tamminen wrote:
ext tarantism wrote:
_POSIX_PRIORITY_SCHEDULING is defined but attempting to create a pthread
with SCHED_FIFO returns an error. Calling pthread_setschedparam with
policy of SCHED_FIFO doesn't complain but checking with
pthread_getschedparam shows a policy of SCHED_OTHER.
Is it possible to set a policy of SCHED_FIFO (or SCHED_RR) or am I
wasting my time?
Are you running as root?
Thanks for the reply.
Yes, I'm running as root.
Code that works fine on Ubuntu returns an error from pthread_create.
Can you confirm that SCHED_FIFO works on Fremantle? If it does, I'll
happily keep plugging away but it would be nice to know that what I'm
trying to do is possible!
There's a stress-test package that has a tool with options
for selecting the scheduler:
http://repository.maemo.org/pool/maemo5.0/free/s/sp-stress/
Changing the scheduler doesn't for some reason seem to work now:
-
# cpuload -s f 10
CPU load generator, build Sep 4 2009 15:09:38.
Copyright (C) 2006,2008 Nokia Corporation.
WARNING: setting scheduler failed failed: operating with default.
Reason: Operation not permitted
...
# strace cpuload -s f 10
...
sched_get_priority_max(SCHED_FIFO) = 99
sched_setscheduler(0, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not
permitted)
-
But it definitely worked last summer when this option was added to it.
I'm not sure what's happened in the meanwhile.
Maybe the issues is with the used realtime priority:
-
# cat /proc/self/limits |grep realtime
Max realtime priority 00
Max realtime timeout unlimitedunlimitedus
-
Does setting SCHED_FIFO with priority 0 work?
- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Hi,
ext Marcin Juszkiewicz wrote:
[sbox-FREMANTLE_ARMEL: ~]
CFLAGS=-Wall -g -O2 -mthumb ./configure --host=arm-linux-gnueabi --
build=arm-linux-gnueabi --prefix=/usr --sysconfdir=/etc --
mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
checking for a BSD-compatible install... /scratchbox/tools/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make: *** [configure-stamp] Error 1
Then you apt-get install maemo-sdk-symbols from extras-devel and you are
done.
mdbus2 package fails at configure step
What sets the CFLAGS and configure flags?
CFLAGS are broken as N900 OMAP3 revision doesn't reliably support thumb
(see ARM errata).
With Sbox you don't need to set --host or --build options.
- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is it possible to use SCHED_FIFO policy on N900?
Hi, ext tarantism wrote: _POSIX_PRIORITY_SCHEDULING is defined but attempting to create a pthread with SCHED_FIFO returns an error. Calling pthread_setschedparam with policy of SCHED_FIFO doesn't complain but checking with pthread_getschedparam shows a policy of SCHED_OTHER. Is it possible to set a policy of SCHED_FIFO (or SCHED_RR) or am I wasting my time? Are you running as root? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: phone case?
Hi, ext Christopher Intemann wrote: I'm looking for a nice case for the N900. It should not noticeable thicken the device, since the N900 is quite big already. Leather is ok, but anything else would be fine as well. And, I will absolutely not wear the phone on my belt, so, no need for clips or anything like that. Thanks for recommendations. Make sure that it doesn't have magnets, see: https://bugs.maemo.org/show_bug.cgi?id=8235 (That should be mentioned in documentation somewhere, but who reads them?) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 kernel module recompile
Hi, ext Nils Faerber wrote: Frantisek Dufka schrieb: Nils Faerber wrote: Then kernel config: cp arch/arm/configs/rx51_defconfig ./.config make oldconfig A make modules does cleanly compile the modules. Fine so far (except for that te modules are *huge* and a arm-none-linux-gnueabi-strip -R .not -R .comment --strip-unneeded seems reasonable). Looks like this strips module version symbols too. Tried similar approach with same result before. Just tried it - works like a charm ;) And the module shrinks from ~200k to ~20k. I think the kernel debian source package should be using dh_strip to automatically separate the debug symbols to a separate (kernel-debug?) package. Debug symbol package is handy for debugging if you get any issues - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Did Nokia alter kernel's OOM handling for the 770?
Hi, ext Clemens Eisserer wrote: I am using my Nokia-770 as allround-server running postgres+tor+routing+lighthttp. It works quite great (except the broken wlan-driver causing crashes all few days when running a tor-relay). However from time to time the OOM killer kicks in, although there's plenty RAM and swap available. Any idea whats causing the kernel to go mad? Was it altered intentionally (if so, what was changes so that I can revert it), or is it a bug somewhere? AFAIK only to be able to tell it to try to avoid couple of processes without needing to run them as root (OOM-killer heuristics try by default avoid root processes). The limit when to start doing OOM-killing is also set from user-space, but it might be related to the amount of free RAM, I'm not sure whether it on 770 takes into account swap. - Eero Thank you in advance, Clemens [17676.783874] oom-killer: gfp_mask=0x201d2, order=0 [17676.797241] [c0026890] (dump_stack+0x0/0x14) from [c0071850] (out_of_memory+0x40/0x1d8) [17676.797393] [c0071810] (out_of_memory+0x0/0x1d8) from [c0072d50] (__alloc_pages+0x240/0x2c4) [17676.797515] [c0072b10] (__alloc_pages+0x0/0x2c4) from [c0075648] (__do_page_cache_readahead+0x150/0x324) [17676.797637] [c00754f8] (__do_page_cache_readahead+0x0/0x324) from [c0075914] (do_page_cache_readahead+0x64/0x70) [17676.797760] [c00758b0] (do_page_cache_readahead+0x0/0x70) from [c006eba0] (filemap_nopage+0x190/0x3ec) [17676.797943] r7 = r6 = 00219560 r5 = r4 = C25E [17676.798004] [c006ea10] (filemap_nopage+0x0/0x3ec) from [c007cc04] (__handle_mm_fault+0x2fc/0x96c) [17676.798126] [c007c908] (__handle_mm_fault+0x0/0x96c) from [c0029364] (do_page_fault+0xe4/0x214) [17676.798248] [c0029280] (do_page_fault+0x0/0x214) from [c00295e0] (do_DataAbort+0x3c/0xa4) [17676.798339] [c00295a4] (do_DataAbort+0x0/0xa4) from [c0020da8] (ret_from_exception+0x0/0x10) [17676.798461] r8 = r7 = 40639540 r6 = 40639560 r5 = 0001 [17676.798553] r4 = [17676.798583] Mem-info: [17676.798614] DMA per-cpu: [17676.798675] cpu 0 hot: high 18, batch 3 used:2 [17676.798706] cpu 0 cold: high 6, batch 1 used:0 [17676.798767] DMA32 per-cpu: empty [17676.798797] Normal per-cpu: empty [17676.798828] HighMem per-cpu: empty [17676.798950] Free pages:1172kB (0kB HighMem) [17676.799011] Active:5576 inactive:6815 dirty:0 writeback:231 unstable:0 free:293 slab:1257 mapped:12129 pagetables:374 [17676.799133] DMA free:1172kB min:1024kB low:1280kB high:1536kB active:22304kB inactive:27260kB present:65536kB pages_scanned:91 all_unreclaimable? no [17676.799224] lowmem_reserve[]: 0 0 0 0 [17676.799285] DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no [17676.799377] lowmem_reserve[]: 0 0 0 0 [17676.799468] Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no [17676.799530] lowmem_reserve[]: 0 0 0 0 [17676.799621] HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no [17676.799682] lowmem_reserve[]: 0 0 0 0 [17676.799743] DMA: 33*4kB 4*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1172kB [17676.799896] DMA32: empty [17676.799926] Normal: empty [17676.799957] HighMem: empty [17676.800018] Swap cache: add 12847, delete 11756, find 42323/43010, race 0+0 [17676.800079] Free swap = 167716kB [17676.800109] Total swap = 198272kB [17676.800170] Free swap: 167716kB [17676.804534] 16384 pages of RAM [17676.804565] 638 free pages [17676.804595] 1096 reserved pages [17676.804626] 1257 slab pages [17676.804656] 19580 pages shared [17676.804718] 1091 pages swap cached [17676.805267] Out of Memory: Kill process 1535 (postgres) score 11478 and children. [17676.805358] Out of memory: Killed process 1537 (postgres). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Hi, ext Alberto Mardegan wrote: Right. Just to complete the picture, here's the same data with -O2: float (fast mode enabled): map_path_calculate_distances: 40 ms for 8250 points map_path_calculate_distances: 2 ms for 430 points double (fast mode enabled): Note that fast mode affects only floats. map_path_calculate_distances: 93 ms for 8250 points map_path_calculate_distances: 4 ms for 430 points (I'm not posting the same data with fast mode disabled, as it cannot be worse than the -O0 case, which is anyway not too far from these values) The relative preformance seems to be about the same. But then of course, it might not be because of the FPU, but of the data transfers. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900: Mapper, device deadlocks and clutter/GL errors
Hi, ext Alberto Mardegan wrote: Hi all, I've some issue with Maemo Mapper which I cannot solve by myself and are unfortunately quite severe: - Sometimes, a HWRecoveryResetSGX: SGX Hardware Recovery triggered line appears on the syslog. Most of the times, without any visible effects. It means that SGX HW got into state from which it cannot recover, so it reseted itself. When that happens, the current SGX HW state is lost. - Rarely, the device freezes for several seconds. It seems to me that this is solved by pressing the power key and waiting a few seconds -- but it might be just a coincidence. When that happens, it can (will) cause temporary slowdown on display updates. - Always: when I'm drawing on a texture (either loading a map tile, or using cairo on a texture) and a Hildon banner/notification appears (either from Mapper itself, or even an incoming chat notification), the texture is corrupted, and it will contain a small rectangle with pseudorandom pixels. And the graphics being drawn when the SGX HW reset happened can be corrupted (as the operation was interrupted and state before the reset isn't recoverable). I'm using clutter 1.0, from extras-devel. When running the application in Scratchbox i486 with valgrind, it is damn slow but I don't see any errors reported while rendering the tiles. Can you help me to debug this? I suspect it is all due to some bugs in clutter (or maybe in the SGX driver), but I have no idea where to start from. It's currently assumed to be a SGX driver issue[1]. As it's non- reproducible, it's hard to get it fixed _and_ to be verified to be fixed. The next release will have an updated SGX driver with changes which which should at least make the issue much rarer. Note that on most(?) devices it doesn't seem to happen at all, at least with the pre-installed software. But e.g. the 3rd party Maep application seems to make triggering of this issue (at least on some devices) easier, especially as/when it's doing window updates even when it's not visible (which is a clear use-time and resource usage bug in Maep). - Eero [1] See e.g. https://bugs.maemo.org/show_bug.cgi?id=9150 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Hi, ext Alberto Mardegan wrote: Kimmo Hämäläinen wrote: You can also put the CPU to a fast floats mode, see hd_fpu_set_mode() in http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/main.c N900 has support for NEON instructions also. This sounds interesting! Is there any performance penalty if this switch is done often? Why you would switch it off? Operations on fast floats aren't IEEE compatible, but as far as I've understood, they should differ only for numbers that are very close to zero, close enough that repeating your algorithm few more times would produce divide by zero even with IEEE semantics (i.e. if fast float causes you issues, it's indicating that there's most likely some issue in your algorithm). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Hi, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Wed, 2010-03-10 at 12:57 +0100, ext Alberto Mardegan wrote: Kimmo Hämäläinen wrote: You can also put the CPU to a fast floats mode, see hd_fpu_set_mode() in http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/main.c Not the libosso osso_fpu_set_mode() function? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
Hi, Voipio Riku (Nokia-D/Helsinki) wrote: I do not represent the general view of my employer or anyone else, just myself. But poor quality applications reflect badly on maemo.org community as well. Do you want to be part of a community which is known for its low quality standards? Notice that the current extras-testing QA requirements are quite low: 1. [ ] Bug database exist. Annoying, but not hard to add (particularly if you choose a tmo thread instead of bugzilla). 2. [ ] Licensing ok. 3. [ ] No illegal/dubious content. Yep, no piracy is acceptable. 4. [ ] Working provided features. Yep. crashing apps are bad. 5. [ ] No missing announced features. If something doesn't work (yet), don't advertize it. Don't dissapoint users. 6. [ ] Optification ok. Should we start accepting packages that break SSUs ? 7. [ ] No performance problems. 8. [ ] No power management issues. This could be clarified to belong only to always-running apps If application does things on the background without user requesting it (like e.g. Maep), that's bad for the performance of the application on top (the one user is trying to interact with) and for the device battery life. App should do only things as response to what user requested. In the Maep case, it should do things on the background only if it's requested to track a route, and even then, skip its window updates to minimize its CPU usage. Tester can see CPU usage from SSH console with top and screen updates with: xresponse -w 0 -a '*' If there were some easy way for the user to see that bg app is slowing down things eating battery, I think letting them to do that would be more acceptable. Then it's user's choice to use the badly behaving (but potentially otherwise very useful) application. She knows to close the application when not needing it or low on battery. (such as hildon-desktop plugins). But for applets in home or statusbar, using CPU when home isn't visible or leaking memory etc is inexcusable. 9. [ ] No known security risks. This is a bit sketchy, but certainly allowing things like default password ssh server would be very very bad for endusers. Here's the quality awareness pages for Diablo and earlier: https://garage.maemo.org/plugins/wiki/index.php?id=253type=g http://maemo.org/maemo_release_documentation/maemo4.1.x/node16.html Didn't find it for Fremantle though. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fw: Proposal: MeeGo User Experience Framework working group
Hi, ext Randall Arnold wrote: Thanks Attila! I just uploaded a more recent update to the PDF (http://maemo-daemons.org/MeeGo_User_Experience_Framework.pdf) based on helpful feedback so far. Some comments on the bug reporting thing. We already have Crash reporter which collects crashes. Creating automated bug reports from crashes isn't useful because: * Users don't write detailed enough use-case descriptions to the crash uploads. It's slightly too inconvenient to do that with the device. * Bugs are related to use-cases, not crashes. Without a reproducible use-case, bugs are usually worthless as you cannot even verify potential fixes to them i.e. tell when the issue is fixed. Telling for which _already existing_ bug crash is related to is useful though and Crash reporter already supports that for (internal) bugs. Due to screen size constraints bug number is given as a keyword in note field instead of there being a separate field for it though. There are going to be some updates to Crash reporter soon so that user can select which bugs to upload (so that unrelated core dumps can be uploaded separately or ignored). Crash reporting isn't currently targeted for normal users for few reasons: * Crash dumps are large and can contain private information (like passwords). Hopefully in Harmattan we can can use minidumps that contain only enough information for backtraces, not all the process data. * Installing syslog means that user's rootfs can run out of space if the log file grows too large (syslog is run as root). Syslog can also contain private information (user names etc). * Crash dumps in heavily loaded device will make the situation worse (whole crashing process needs to be swapped in for core dump etc). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Hi, ext Carlos Morgado wrote: What platforms will it run on ? Read the MeeGo site (like I just did). Based on it, different product categories are going to have different UIs, but the toolkit below them used by the application developers will be the same (Qt). Does Nokia have arm kernel people ? Don't think so, but I dunno intel has loads of x86 kernel people. You really don't know? Linux kernel development is open, you can just subscribe to arm/omap kernel mailing list and see yourself. Linux Weekly News (http://lwn.net/) even publishes regularly statistics on which companies develop Linux kernel (based on the commit logs). The whole Qt run everywhere pipe dream is just laughable. Could you detail which GUI toolkits you think to do this better than Qt and how/why? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 and hw accelerated X.Org?
Hi, ext Kuba Irzabek wrote: Is xserver in Maemo 5 (Nokia N900 OMAP 3) using hardware acceleration (SGX)? Yes, to some extent, but SGX is 3D accelerator, you cannot really expect it to make much difference for most 2D operations. For simple 2D operations like blitting, SGX is actually slower. In those kind of operations both CPU and SGX are memory bandwidth bound, but SGX is run at slower speed than CPU and has command setup cost. Memory ownership change between CPU and SGX has also a performance cost because this requires cache flush. I cannot find confirmation on that anywhere. I found inforamtion that accelerated user interface on omap 3 can be done using qt embedded or clutter and not xserver. Where can I find more on that topic? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Browser Switchboard, MicroB, and application prestart in Fremantle
Hi, ext Steven Luo wrote: I'm the maintainer of Browser Switchboard [1], which is a program that's supposed to make it possible for the user to choose the default browser on his/her Maemo device. Packages are available in extras for Diablo and extras-devel for Fremantle. In order to control the default browser, Browser Switchboard takes over handling of the com.nokia.osso_browser D-Bus methods. Since launching MicroB from the menus invokes com.nokia.osso_browser.top_application, it has to be able to launch MicroB. For Diablo, we do this by exec() of /usr/bin/browser(*), but this doesn't seem to bring up a browser window in Fremantle (see the discussion on talk.maemo.org [2]). Also, at least in testing with my half-broken SDK, the Fremantle browser process remains in memory even after the last browser window closes. This poses a problem for Browser Switchboard, which releases com.nokia.osso_browser before starting MicroB (so that MicroB handles the methods while it's open, giving users an easy way to temporarily open links in MicroB no matter what their default browser is set to), and needs to be able to reclaim the name when the last browser window closes. I can only assume this behavior is related to the prestarting of the browser process in Fremantle, but I'm unclear on how Browser Switchboard interacts with prestarting in the first place (is a browser process prestarted on boot when Browser Switchboard is installed?), and I don't have a Fremantle device to test any of this on. That leaves me with the following questions: * How does one open a new browser window from an application, preferably without using the D-Bus interface? (If there is no other way to bring up a new window except D-Bus, I assume I'd have to try something like launching the browser process, waiting for it to acquire the com.nokia.osso_browser name, then making the method call, which wouldn't be pretty, and also precludes the possibility of working with a prestarted browser process). * Is there a way to ensure the browser process quits when the last browser window closes? If not, is there a way to receive a signal when the last browser window closes? (It's probably possible to poll for the existence of a browser window, but I can't think of a way of doing it that doesn't impact battery life and doesn't introduce a potential race condition.) Browser has normally several processes in the device: - The UI, which is prestarted - The master browser daemon which provides it's clients with app specific browser daemon instances - Browser daemon instance for the browser UI - Browser daemon instance for the messaging UI The UI pre-starting is controlled from the browser .desktop file. Comment out the prestart line there and kill browser UI to get rid of it. Application specific browser daemon instances are started by a request from the app to the master daemon. To get rid all of those daemons, make sure those apps are not prestarted and kill the apps. Browser master daemon is started during the X session startup and restarted by the dsme SW watchdog when it exits. To make it go away, use: dsmetool -k /usr/sbin/browserd -d If master browser daemon isn't running, I don't think normal Browser UI or messaging UI to work (they open, but their windows lack useful content...) though. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo extras repository package uploader/maintainer verification?
Hi, I was recently notified that in extras repository some package for which I've been marked as maintainer, was causing an SSU (testing) issue. However, I hadn't uploaded that package. The package was from SDK tools repository were I was the correct contact person for that package. The package in Extras had the same version, but not the same size i.e. it was modified (or at least different). What checks there are in place to verify that the package uploader and the package maintainer field (shown to people who install the packages) match? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
Hi, ext Jeremiah Foster wrote: On Jan 22, 2010, at 11:49 AM, Eero Tamminen wrote: I was recently notified that in extras repository some package for which I've been marked as maintainer, was causing an SSU (testing) issue. However, I hadn't uploaded that package. The package was from SDK tools repository were I was the correct contact person for that package. The package in Extras had the same version, but not the same size i.e. it was modified (or at least different). What checks there are in place to verify that the package uploader and the package maintainer field (shown to people who install the packages) match? I think Niels has a check for that in the QA software he has written, in fact, I am certain of it. :) This check does not currently default to stopping the incorrect uploader / maintainer from uploading the package. It is possible to change this behavior and I think in the future this check will default to stopping package uploads that do not have the correct maintainer information. Unfortunately, people do not change the maintainer field of the packages they upload very often, this is a big problem. Sorry, I didn't understand this. If one is the principal maintainer (uploads the package often), why putting one's name to the maintainer field is a big problem? But stopping everyone without warning is not the solution. I think we will move towards stricter testing however in the near future, but final decisions should be discussed with Niels. There needs to be some way to contact people who have uploaded problematic packages to the repository. How that works now? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo extras repository package uploader/maintainer verification?
Hi, ext Marcin Juszkiewicz wrote: Dnia piątek, 22 stycznia 2010 o 14:03:18 Andrew Flegg napisał(a): On Fri, Jan 22, 2010 at 12:59, Simon Pickering s.g.picker...@bath.ac.uk wrote: I'd suggest that the autobuilder checks to see that the uploader's email address is included in one of the *Maintainer fields; but there is the slight problem of what happens when someone is uploading someone else's package (e.g. as a favour when they are away from a build machine)? There's also packages which are maintained by a team but uploaded by an individual. There must be somebody who is responsible for the uploaded package and some way to contact him. The uploader must have somehow verified that the package isn't e.g. malicious (even if it's just taken from a trusted source). If it's a team, they might even share the ssh-key. But I think it would be better to have some configuration thing where Maintainer can grant upload rights for his package to others he trusts. Let's take the hypothetical case of there being a malicious Garage developer and somebody finds that e.g. his funny fart app is actually a trojan. How we can identify and check what else that person has uploaded to Maemo repos? After there's notification about the issue to users, how they can check whether the specific version of a foobar applications they've downloaded from the extras isn't actually uploaded by this suspicious person? The maintainer field gives users some trust: Oh, this app is from the same maintainer / uploader as all these other nice apps, so I can trust it. If the maintainer field isn't validated in anyway, this trust is misplaced. Sure, but iirc Debian handles it by having Maintainer and Uploaders fields. Sounds a good idea. I think maintainer fields should still be checked as that's what's presented to users, not Uploader field. From my point of view Maemo packages should have Maintainer field changed even when there is no changes in Debian package (other then recompilation). Why? Simple - how original maintainer can maintain package on platform unknown to him? On system which is not Debian even... Agree 100%. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Hi, Stoppa Igor (Nokia-D/Helsinki) wrote: This really isn't hard! For the vast majority of applications there is no reason at all why they cannot be built against the first software release and install on all later releases, taking advantage of the bug fixes made since. I have been doing that for GPE since the first Maemo release. That is what the autobuilder should be doing by default -- no need to make life hard for users **by default**! Building is not so much my concern, but rather testing: what is going to be the accepted environment for approving and releasing a new version of your sw? Hopefully not the first sales release. Although SW would be built against the shared libraries from the initial release, they should of course be tested against the latest release. If the software doesn't work in the latest release because minor Maemo update broke binary _backwards_ compatibility in some library, only then it needs a separate build (also) for latest release SW libraries. One of the problems is that we don't have any automated thing that would report about ABI incompatibilities between shared library version. This would also tell developers who've integrated an application to first release, to build and check it against a latest one because it had a binary incompatible change for one of their direct dependencies. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Disable portrait support for dialog with Hildon
Hi, ext Cornelius Hald wrote: On Thu, 2009-10-29 at 17:31 +0100, Piñeiro wrote: From: Cornelius Hald h...@icandy.de the main window of my app supports portrait mode. Now I have a settings dialog which does not support portrait mode but it inherits those flags from the main window. So you'll have the main window in portrait mode, and there is a possibility that a dialog in non-portrait mode appear? No, the dialog is only accessible in landscape mode. But if the dialog is open, I want it to stay in landscape mode. I'm not a expert in usability, but this would be confusing for me, and it would force me to rotate 90 degrees the device in order to read properly the dialog. There isn't any possibility to support the portrait mode in the dialog? Of course there is, but the dialog does not make much sense in portrait mode because it also contains text fields. And of course it's additional work. Several other possible solutions. * Change to portrait mode support of the parent window before showing the dialog. * Change settings dialog to a settings window. * Remove settings option from the main window menu when it's in portrait mode. I think last would be nicest solution. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Michael Cronenworth wrote: Eero Tamminen on 12/30/2009 04:09 AM wrote: Incorrect. I guess there's some illegal black magic happening in-between compiz and apps regardless of UI toolkit libraries. Apps such as dasher that present rectangles and text at fast speeds do not present any tearing when I have the *compositor* set to vsync. Firefox with the SmoothWheel extension for liquid smooth scrolling is tear free until I turn vsync off on the *compositor*. If the related toolkit updates gets into same boxed XDamage event going to the compositor and compositor blocks X updates to the composite buffer while compositing it to screen, you don't get tearing. In practice this may be enough, especially on faster machines, but I think it's more due to fortunate co-incidences than something really being guaranteed by the (current Gtk) toolkit. My own apps are tear free until I turn off.. you get the point, I hope. Try for example pannable Gtk treeview with your own cell renderer and add some suitable wait into that renderer to make sure that your renderers' window update gets timewise separated from rest of the treeview update and see whether you get tearing. Of course, I could get into a technical acronym-fest with you, but that wouldn't be very helpful as real world examples would. If application updates to it's composite buffer aren't in sync with the compositor display updates, there's obviously a possibility for tearing. I don't think you understand how X works. :) Hm. Do you? :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Frantisek Dufka wrote: Recent hildon-desktop versions disable compositing automatically for fullscreen windows, unless you use HildonStackableWindow (which requires the sliding animation). I wonder what happens to translucent information messages (charger attached/removed, ...) in fullscreen SDL applications, are these not shown when compositing is off or are they done in different way and still shown? hildon-desktop automatically switches to composited mode when needed. (Making this transition without a temporary user visible visual glitch, has taken quite a bit of effort, AFAIK including fixes to upstream X server too.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Michael Cronenworth wrote: Eero Tamminen on 12/29/2009 09:17 AM wrote: because Gtk doesn't have any support for Vsync. Gtk doesn't need to support Vsync. Qt won't magically fix this problem either. Only the compositor needs to support Vsync. Once it does then *all* 2D operations will be tear-free. Gtk, Qt, terminal-based, etc. Incorrect. If application updates to it's composite buffer aren't in sync with the compositor display updates, there's obviously a possibility for tearing. In practice, if application callbacks paint their own parts fast enough after Gtk does window scroll, they get in to same boxed XDamage event and usually everything looks fine. If they don't, there's tearing. If Gtk happens to draw to its backbuffer while HW is compositing (as requested by compositor), there's also tearing (whether it's visible to user, depends on what's drawn). I think compositor does either input or server grab while compositing, so this might not be a problem. Former can be though. In summary, all of these three steps need to be synchronized for tearing to be completely eliminated: app - composite buffer - framebuffer - LCD Synchronization means waiting / extra buffers so it will slow down screen updates to some extent. Any extra copying done for this would have a large effect on performance because the device is memory bandwidth constrained (like all computers nowadays), buffer swapping is better in this respect. But extra buffers mean increased memory consumption (800x...@16-bit RGB surface is 750kB, at 32-bit RGBA it's 1.5MB). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Claudio Saavedra wrote: El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió: This is not really fixable due to how Gtk painting is arranged, parts of the window are painted in application callbacks. This is not totally correct. Application callbacks can only cause GTK+ to *invalidate* regions. In sane code, redrawing *never* happens in a user callback but only in expose event callbacks, which are triggered by GTK+ *only* when the time for redrawing comes. Application (expose event) callbacks implement painting for application's own widgets and treeview cell renderers. But where inside the application process they happen (app or Gtk code) is not so important. The issue is that Gtk (AFAIK) has no mechanism to synchronize this drawing with the compositor and doesn't offer applications any mechanism for it either. If painting/redrawing takes too long (there's some delay between the X draw commands due to what application does internally), it doesn't go the the same boxed XDamage event to the compositor. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: /usr/local
Hi, ext Thomas Tanner wrote: sorry for my ignorance - I've only recently started following the optification discussion. Is there any good reason why Maemo does not follow the standard UNIX layout with user applications in /usr/local ? /usr/local seems to be in all search paths and if /usr/local would be just a symlink to /home/local there would be no need for further symlink tricks. According to the filesystem hierarchy standard, /usr/local is for things that are NOT tracked by system package management: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY Whereas /opt is standardized place for 3rd party software: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES I haven't looked what maemo-optify exactly does, but I think the standard compliant way would be to install package contents to /opt/package/ (with ./configure --prefix). The .desktop file will tell to invoke the /opt binaries from a correct place. If autotools doesn't automatically put things like icons and .desktop files to correct place, those could have symlinks to rootfs. Problematic issues would be how to deal with shared libraries, for those symlinks would probably be still the best option. I mean, adding symlink to /opt/lib and having that in $LD_LIBRARY_PATH, not symlinking the libs to rootfs. Direct invocations of binaries from scripts could also be problematic. For those there could be a symlink to /opt/bin and that could be in $PATH. - Eero (And if somebody would want more space for applications than is available on /home partition, he could change the /opt symlink to point to a memory card with suitable file system and prepare for the issues resulting from having programs on removable media...) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Xavier Bestel wrote: But where inside the application process they happen (app or Gtk code) is not so important. The issue is that Gtk (AFAIK) has no mechanism to synchronize this drawing with the compositor and doesn't offer applications any mechanism for it either. If painting/redrawing takes too long (there's some delay between the X draw commands due to what application does internally), it doesn't go the the same boxed XDamage event to the compositor. AFAIK GTK+ redraws are double-buffered, so if it takes too long to redraw a frame it's simply delayed until the next one. That double buffering overhead is used to get rid of flickering resulting from successive clear+draw operations, (AFAIK) it's not whole window buffer (for obvious memory usage reasons), so it's not relevant for the tearing issue. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, ext Andrew Flegg wrote: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. It does not say that the _sum_ of all dependencies has to be below 500k. I agree, it looks ambiguous. The *intent* seems to be that installing an application shouldn't take up more than 500KB of the rootfs (your Python example on the package page is specious, BTW, as Python is now optified). If the dependencies are used by lots of apps, and have separate maintainers; I can understand your point. However, since: * you maintain both libgoocanvas3 and osm2go * neither are optified (according to the comments) * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA Where this 500kB figure for these packages come from? If it's uncompressed size, then it's bogus as the rootfs is compressed. The script attachment here: https://bugs.maemo.org/show_bug.cgi?id=5795 Tries to give a more realistic[1] estimate on how much space a package actually takes from the rootfs. - Eero [1] Note that the documentation is removed with an apt hook. If one installs package directly with dpkg to the device, this hook doesn't get called. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Mark Clarkson wrote: I have made a simple animation using a clutter timeline with clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the animation plays making the animation look terrible. I have tried none, dri and glx values for the CLUTTER_VBLANK environment variable but this seems to have no effect at all. Is there a way to fix this? Screen update isn't yet synched to LCD refresh. Please file a bug about it to bugs.maemo.org (it needs support from kernel display driver, X server, SGX driver, Clutter and hildon-desktop compositor, but I guess you could file it against Official platform - Core - X). After this I think things should look fine in Clutter when app does things right. E.g. panning in normal applications can still tear though because Gtk doesn't have any support for Vsync. This is not really fixable due to how Gtk painting is arranged, parts of the window are painted in application callbacks. If application callback is fast enough that it gets into same boxed damage event from X server (to compositor) as the internal Gtk pannable area scroll, there's no tearing, if it gets drawn later, then update for that part of the window goes to screen on next compositor screen update. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package Building HOWTO
Hi, ext Joseph Charpak wrote: On Tue, 2009-12-22 at 18:24 -0300, Jeff Moe wrote: I have written up a Package Building HOWTO. You can find it here: http://wiki.maemo.org/User:Jebba#Package_Building_HOWTO Looks good although I'd swap the order of compile for armel with compile for x86. First you compile for x86 and run the resulting app to see if it works in scratchbox. I'd add here also testing for: - install, remove re-install package (maybe also upgrade) - run lintian on the packages (outside of sbox) and fix relevant reported packaging issues: lintian *.deb - test the software when run under Valgrind to see whether that reports any memory handling issues: fakeroot apt-get install valgrind maemo-debug scripts run-with-memcheck app (relevant for C C++ code, not for interpreted stuff) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
Hi, ext Stephan Jaensch wrote: First of all, my viewpoint as a user: I want as many apps as possible. Choice is always good. I own an iPod Touch, and I can say with confidence that my criteria for selecting an app is always functionality, quality (hard to gauge since there is no try before you buy, so I'm judging by user ratings for that) and price. As a user, I don't care about source code availability. Without source code availability others cannot help in fixing the bugs in the application or start maintaining the package when the original package maintainer goes away (as they always eventually will). I.e. source code is some level of guarantee about the functionality and quality being there for the long term, even if the author gets other priorities. If the software is such that you need to invest time to learning it, then also long term matters. If it's e.g. a game that you'll play through once, then it's not so important. Source code availability matters then more for the possibility of being able to verify things that cannot be (easily) verified from the binary alone (e.g. security, actual changes between versions etc). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debhelper 7
Hi, ext Jussi Hakala wrote: ext Anderson Lizardo wrote: Now things might get complex if the packaging already uses some new features of level 7, like those CDBS-like helper rules. In such cases, looking at versions prior to the compatibility level upgrade might help doing the downgrade (and most Debian packages are kept in public SCMs like svn.debian.org). You can also try the debian-squeeze devkit available from scratchbox.org. Note that this is not (yet) supported by Fremantle SDK and you need to create your scratchbox targets by hand instead of the installation script, but should be enough to allow you to use debhelper 7. But I think using something like that would require that Maemo auto-builder supports it too... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Double checking free/nonfree packages
Hi, ext Christopher Allan Webber wrote: For now there seem to be two main pages on which the documentation of what is free/nonfree is: - http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Top_Level_Architecture - http://wiki.maemo.org/Why_the_closed_packages The first contains that rather informative graph, but I suspect that the intended purpose of that page would be made less useful if we put all of the documentation of free/nonfree components on there. The second one seems to be a good start, I think main issue is that it's not really updated for Fremantle, a lot of the stuff there would seem to be Diablo release specific... but I think the naming of that particular page helps defeat our purpose, as it seems to say here is why these are closed as just an explanation, and does not indicate this is a record of pieces that we are working to free. So, unless there are any objections, I think it would be better to start a page with a name such as Free_Maemo or something similar that indicates a kind of free and open source todo-list that I think everyone here seems to want. I'll work on incorporating the Why the closed packages page within that document, and if that proves to be satisfactory, we can probably have the Why_the_closed_packages page redirect to the new one. What about following page structure? Index page: * with explanation about: - Why it makes sense to open sources and what should be prioritized (the list below) - Why Nokia has some packages closed (top part of existing page) * Link to page listing closed packages in Diablo (bottom part of existing page) * Link to page listing closed packages in Fremantle * Link to TODO list(s) about opening or replacing above packages with free alternatives The criteria to prioritize components could be (improvising a bit, feel free to suggest improvements): 1. Fixing a bug. I mean a real objective bug: package is in non-free although it looks like it's actually an open piece of software. 2. Nurturing application development. There is a strong argument proving that opening a component will bring more and better apps for end users. 3. Spread of Maemo driven technologies to other platforms. A component fits well in a gap existing in other Linux/OSS based projects and there is a concrete interest on collaborating and contributing to a component if it's opened. 4. Community maintenance. A component is receiving low attention from the official maintainers even if it has high attention from the community and there are developers volunteering to contribute to it if the source code is available. 5. Better architecture. Probably covered by 2 or 3 but just in case. A closed component is sitting in the midle of open components making things more difficult that needed to developers interested in that area. Good list! - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras Testing to Extras, again...
Hi, ext Aniello Del Sorbo wrote: I am sure I missed something... but what actions were taken to address this issue? I do have Xournal pacakge 20 for more than 10 days with 6 thumbs up out of 10 (i.e. more than 50% of people voted OK). I want to promote it to Extras. And I don't want to depend on others. I REALLY would like to see a Promote to Extras earlier in the process. It's up to me to wait enough time so that people can test it. Again, what I think it's missing is something to vote after the packages has been promoted to Extras so that the bad ones can be pulled out. If the fear is for malicious applications, then there's no way we can prevent those from going to Extras no matter how many days it's been in Testing. (a timer comes to mind). I'm not really happy with this process either. There should be some kind of checklist which people go through, that has items like: [x] Tested with htop + T (to sort output according to Time column) to see that application doesn't wakeup on the background and when screen is blanked (if the application time column doesn't increase during 10 mins). CPU usage when application is visible, but not interacting with the user could also be checked. These require ssh connection to the device. [x] Checked normal application memory usage with mem-monitor (from sp-memusage) on a freshly booted device and that it was below X MB as required for this class of applications (i.e. diff from before app started and when it is running). [x] Used application for few hours with endurance snapshots (tool from sp-endurance package) being taken at regular intervals. The report generated from this data didn't show any (significant) resource leakage. Random comments about things working for people are not really useful if at least someone of them hasn't checked properly also things that aren't immediately visible to the user (effect on battery usage and general device stability over longer period of time etc). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Aniello Del Sorbo wrote: Is the purpose of OHMD ONLY to pause not whitelisted applications when rotating? As if it is so, I'd put a stop ohmd every time I run Xournal to make sure it rotates smoothly. It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Not something you may want to stop then. I'll wait for a fix. The policy configuration is in: /usr/share/policy/etc/current/syspart.conf As a temporary hack for your own device, you might try to modify that file as root and then do killall ohmd to restart it with the new policy. This way you get to decide what has the priority instead of it being dictated by Nokia. :-) In future there may be some way to install extra policies. NOTE: if this conf file has errors, ohmd isn't started and your device will most likely behave strangely as result (cannot play music etc). DISCLAIMER: if it breaks, you get to keep all the pieces. I.e. have an up to date backup of your data and be ready to reflash in the case that things really break. Modified policy is an untested configuration. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The issue of version strings / improving Application manager view
Hi, Kallioinen Juha (Nokia-D/Helsinki) wrote: The problem is imho the Application manager, not the version numbers. What's the point of even displaying the version number in the Application manager's default view? I personally don't care about the version at all and I certainly won't remember if an application's version has been updated by looking at the list view. Am I alone with this opinion? Why do you need to see the version there? The update manager will gladly tell me if I have an older version installed and if I don't, won't I just install whatever the Application manager offers me? The alpha/beta/stable status would be interesting. I.e. is this a bugfix release or one with new buggy features? The package version can anyways be found from the package details page, where there's more space available for it too. A link to package page that opens Browser would be best I think. A much more interesting bit of data instead of the package version to be shown by default might be the date when the package was uploaded. Also the Application manager could use a 'show new packages' view. But these of course require changes to the Application manager and maybe even to apt/dpkg database to be able to show the package's date and are more difficult to implement than just making nicer version numbers. Maybe a nice version number could really just be the date the package was created. That would fulfill my first wish, but we'd lose the upstream version trackability :) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Eugene Antimirov wrote: It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. Just to know. I see now this `ohmd` process in my 41-10. I did not get it, was this daemon improved or made worse in new firmware released lately? Better for known (pre-installed) applications, worse for unknown applications. The reason for this is that unknown applications have unknown resource usage so system policy treats them with more care. It's a bit of a chicken and egg problem. Changing the policy is slow iterative work requiring lots of testing that the policy change doesn't significantly worsen other use-cases in some situations (e.g. for things for which there are certain certification legal requirements). Developers can now experiment and report/discuss things which they would like policy to handle better (for certain classes of 3rd applications and their use-cases). I.e. in regards to 3rd party applications, the policies could be considered work-in-progress. Things that could potentially be done for 3rd party applications policy handling: - Default policy is improved in regards to unknown processes. It's yet unknown whether this can be done well enough without sacrificing the known functionality, that's why feedback is needed on the behavior of 3rd party application use-cases. - Applications themselves specify the required policy on install. This is extra work for apps, and requires extensive testing to guarantee that the policy they choose is good match for the application in all cases. (application doesn't leak or otherwise hog resources) - Some way for user to specify per-application policy. I'm sure power-users would like that... :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Aniello Del Sorbo wrote: why don't you guys simply allow only the foremost (i.e. the currently visible one) application to rotate and send the rotation event to the other apps AFTER the animation has completed. Background applications don't get the rotation / redraw messages at all. You can check this with xresponse and/or xev. (Fixing that in X and composite/window manager required a lot of work, but AFAIK applicable parts of this work are now in upstream.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Martin Grimme wrote: How about another XAtom (since we already have so many on Maemo ;) ) on the application window, saying I rotate well and quickly. ? The ohmd could take care of this atom and refrain from freezing the app during rotation, iff it is the currently visible one. Of course applications could lie about their rotation capabilities, but that's what we have the extras-testing QA for. The rotation case is a minor issue and I think it can be handled OK for unknown applications without this kind of kludges. Let's just hope we can get a fix for that included to the next release. The main issue with policy is handling of unknown processes in general and for that more feedback is needed. (A hint: MAFW is a known system service, so it's good to use that for music playback... Tracker use is a bit more problematic because it's resource usage can fluctuate pretty much according to content it processes and what kind of requests it gets. And policy daemon doesn't currently know whether foreground application needs tracker or not.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bug#6203, rotation and OHMD
Hi, ext Aniello Del Sorbo wrote: according to bug 6203 (https://bugs.maemo.org/show_bug.cgi?id=6203) Nokia introduced this ohmd daemon that pauses applications not whitelisted so that the rotation itself would proceed smoothly. In the meanwhile Collabora had fixed and improved a lot rotation itself, so that this pausing is not needed anymore. In fact, it make thinks worse. Is the purpose of OHMD ONLY to pause not whitelisted applications when rotating? As if it is so, I'd put a stop ohmd every time I run Xournal to make sure it rotates smoothly. It handles also audio policies and tries to make sure that you get your phone calls when the device is heavily loaded and some other minor things. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why should it be so hard and should I even bother with Extras for fremantle?
Hi, ext Andrew Flegg wrote: On Mon, Nov 2, 2009 at 10:47, Marius Vollmer marius.voll...@nokia.com wrote: ext Jeremiah Foster jerem...@jeremiahfoster.com writes: Then Application Manager has to change. It does not scale to have categories when there are thousands of apps. Yes, this is overdue. We also need a way to handle application specific add-ons, like language packs. Instead of debtags, the subsection approach of user/network/command-line (or user/network/advanced) could solve both problems in one. I don't understand why CLI tools need any specific section. That just makes porting (re-compiling) them from Debian more hassle. The value of being able to install them from AM GUI in addition to using apt-get install on command line seems also dubious (especially if one has installed Bash and package name completion). Current user/* category should be used for normal, end-user visible UI applications. If AM support for CLI utility installation is really needed, I would propose an option for AM like: [ ] List non-UI/command line utilities Then enabling that in AM would get one also categories which don't start with user/. I think AM should still skip showing library packages. They should get pulled in by the applications and utilities when needed, one usually doesn't need a library in itself... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Hi, ext Graham Cobb wrote: On Thursday 10 September 2009 12:16:59 Marius Vollmer wrote: By the way, I have been experimenting with maemo-optify. I think it is currently generating too many links for quite small files. All files, even symlinks, take some space. On UBIFS single file overhead is about 1/4 KB (inodes + filename). I think 20K would be a better default for the size and, if feasible, I would like to see the size settable as an option on the command line, to allow the developer to tune it for their particular package. As UBIFS compresses the file contents[1] with LZO, it's the lzop compressed file sizes which should be used for this kind of decision. Does maemo-optify compare the lzop'ed or non-compressed ones file sizes? - Eero [1] /opt is on ext3 which isn't compressed. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Call for testers with N900 for vncviewer
Hi, ext ds wrote: Am Dienstag, den 20.10.2009, 20:08 +0200 schrieb Cornelius Hald: On Tue, 2009-10-20 at 15:01 +0200, ds wrote: I have no feeling for N900 at the moment. But yes, I have some feature requests left on garage, and as there is not too much UI it should not be a big deal:-) But first I want to have it running an the N900. I got it working now :) Attached is a screenshot (in case the list allows that). Thanks, at least my copy allowed it! Getting the UI Fremantle conform should be straight forward, at least it looks like that to me. If you need help there, just tell me. I got a message from maemo admin: After disabling the toolbar and switching to fullscreen mode there seems to be no way get out of full screen or getting the toolbar back. Can you confirm this? Is no Hardwarebutton bringing up the menu or toggle full screen anymore? Correct. I would suggest supporting additional shortcut like Ctrl-f as proposed in another mail. - Eero PS. User can switch to other apps by using the Ctrl-backspace shortcut for the task switcher (or by launching Camera app with the camera button or closing the application from the power menu End task button). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder and build-dependencies from extras-devel
Hi, ext Ed Bartosh wrote: I haven't used the autobuilder. Is it possible to see how many/what packages are in the queue? (if there are lot and/or large/slow to build packages, one would know not to wait anything to happen very soon...) Unfortunately there is no such a possiblility. Autobuilder doesn't have any web interface at all. You can only see build results and logs after build is finished. However, considering the fact that we have only one builder machine even if users would know how many packages in the queue it wouldn't help them much. What would help is to know which packages are being built at the moment + amount of packages waiting in the queue. Thanks! I guess there's no way dput could tell that information? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto correctly place data on the memory card?
Hi, ext Till Harbaum / Lists wrote: Am Montag 22 Juni 2009 schrieb Kimmo Hämäläinen: Use MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT environment variables, available since Nokia 770 Internet Tablet. I'm not sure about Scratchbox, since it does not have memory card emulation. The scratchbox doesn't have this which is perfectly fine as i'll then just fall back to using $HOME. But i still have a major problem with this: It doesn't work in the debian/postinst script when running the application installer. I simply added a call to env to my postinst script to be able to see the environment bein used in the application installers log. See below the log i get on my n810. It seems that the worker thread of the app manager that deals with this has been started before the environment was complete. So there are no MMC related entries at all which makes this useless to install data on the memory card. So please let me re-phrase my question: How does a postinst script know where the memory card is? I guess the script could get (source) the information from /etc/osso-af-init/af-defines.sh file? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Hi, ext Rainer Dorsch wrote: I run into the power cycles problem again (w/o having added the text2screen output, but I will try that now). I observed two things: - I had to remove the battery to get out of the power cycles loop - after removing the battery and normal bootup (w/o power supply plugged) I found in the /var/lib/dsme/stats/ files Nokia-N800-23-14:/var/lib/dsme/stats# You don't have the latest release? for f in *; do echo $f:; cat $f; done 32wd_to: 4 lifeguard_restarts: /usr/bin/hildon-input-method : 5 /usr/sbin/ke-recv : 5 /usr/sbin/multimediad : 7 /usr/bin/esd : 8 /usr/bin/osso-media-server : 3 /usr/sbin/dsp_dld -p --disable-restart -c /lib/dsp/dsp_dld_avs.conf : 7 * /usr/bin/hildon-desktop : 3 /sbin/mce --force-syslog : 1 sw_rst: 4 Nokia-N800-23-14:/var/lib/dsme/stats# Does the * behind /usr/sbin/dsp_dld -p --disable-restart -c /lib/dsp/dsp_dld_avs.conf : 7 * mean, that caused the last reboot? Yes, I think so. What is /usr/sbin/dsp doing? AFAIK dsp_dld loads the DSP programs to DSP. That needs to be re-done after the DSP is reseted (which gets done when there's some issue with the DSP side). Does removing the battery change anything in this area? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder and build-dependencies from extras-devel
Hi, ext Ed Bartosh wrote: 2009/6/24 Henrik Hedberg henrik.hedb...@innologies.fi: 1. Upload your library into the extras assistant 2. Wait unspecified time (usually at least ten minutes) 3. See if the build succeeded. If not, go to 1. 4. Wait unspecified time (one hour perhaps) until the library is actually in the extras-devel. 5. Upload your application into the extras assistant. 6. Wait unspecified time (usually at least ten minutes) 7. See if the build succeeded. If not, go to 5. 8. Wait unspecified time (one hour perhaps) until the application is actually in the extras-devel. 9. Promote the library and the application to the extras. 10. Wait unspecified time (one hour perhaps) until the library and the application is actually in the extras. 11. Announce the new version of your application to users. How many hours is 1 - 10? Is there any possibility to make this time shorter? Sure! We just need to think about it and we'll found how to do this. I explained my ideas above. You can share yours. I haven't used the autobuilder. Is it possible to see how many/what packages are in the queue? (if there are lot and/or large/slow to build packages, one would know not to wait anything to happen very soon...) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optimal battery life considerations in apps
Hi, ext Henrik Hedberg wrote: There is a standard X event for that: XVisibilityEvent. The X server (and a window manager) can keep window contents cached (backing store) and decide not to send exposure events, but my interpretation is that if it is not sending visibility events it is broken (and it is currently as I showed in my earlier post). This is not the case with Compositing enabled (Maemo 5). Only compositing manager can know whether something is visible, X cannot. I think there's an extra API provided for that in Maemo 5. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Hi, ext Rainer Dorsch wrote: I modified that too if [ x$bootreason = xcharger ]; then echo Showing the 'charger connected' image /usr/bin/fb-chaimage -l /usr/share/images/qgn_indi_charger_connection_detected -b 0 -c -p 0 -s 15 else text2screen -t Bootreason: `cat /proc/bootreason` -H center -y 360 -s 6 -B 0x fi This way I have at least some information when I run in that problem next time. Is there any other debug information which would be useful to print? maybe statistics from /var/lib/dsme/stats/ files? Is there a way (by changing linuxrc further) to get a lot more information during boot instead of the nice but almost informationfree image? Using the text2screen utility above? I just noticed that I cannot write that file, the fs is mounted readonly: /dev/root on /mnt/initfs type jffs2 (ro) If I remount it rw mount -o remount,rw /mnt/initfs to do the change, would that break something? Initfs may be too full for changes. You need to remove things first (e.g. initfs factory test stuff you can find -name '*test*'). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Hi, ext Rainer Dorsch wrote: One thing I noticed and maybe I did not highlight that enough: - yesterday in the boot loops, the N800 started itself after I plugged the powersupply (no matter if I removed the battery before or not). - today plugging the power supply does not start the N800 anymore, just showing that it is charging the battery Under which circumstances is the N800 started automatically, when the power supply is plugged in? Always. It will then go to Charging mode. If you in that state: - unplug the charger - device powers down. - press power key - device comes fully up. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Hi, ext Rainer Dorsch wrote: my N800 crashed after running navit. During the reboot, the blue bar completed, then it paused sometime and it rebooted again. This now cycles so that the N800 is doing nothing else than power cycling. With which OS version this is? Is there a better way to fix that than reflashing the device? For normal users, no. Is there a way to find out what the root cause of the problem is? If the device eventually boots up and you had syslog installed and free disk space, then yes. Otherwise you'd need serial access. Can RD mode help to be more verbose during the boot process? Weired, after waiting a few hours and booting the N800 w/o a power cable, it booted again. In this case I assume the reason for the boot loop was that navit (what is that?) trashed your rootfs contents in a very fragmented way so that JFFS2 mounting[1] took too long (1/2min without kicking the watchdog) triggered the HW watchdog. [1] The reason why I asked about OS version is that in very old releases JFFS2 garbage collecting could also happen at mount time which could take a lot of time. In later releases it's postponed. Are there any logs which show what went wrong before? Can I do something to better protect myself against such boot loops? Avoid SW that can fill your rootfs, runs as root and doesn't have proper error handling for disk writes (remove data if disk fills up, have strict limits on log etc file sizes etc). If something *running as root* fills the rootfs, your device is in boot-loop and needs to be reflashed. Explanation: The device needs a small amount of free space at bootup (JFFS2 needs some space even to remove data), otherwise it doesn't boot. There should be enough allocated for root for this purpose (user cannot fill it, only root can). However if a bad process running as root is installed that fills disk, or *anything* you install (installation happens as root) has badly behaving package install scripts, you can get screwed. Because this kind of issue may happen e.g. only in an uncommon error situations, normal testing might not catch them. Everything pre-installed to the device should behave fine, but 3rd party packages can do funny things. I'd suggest taking backups at least before installing something that's not widely used. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, Gil Quim (Nokia-D/Helsinki) wrote: ext Till Harbaum / Lists wrote: i am really unsatisfied with bugs.maemo.org. The reason is simple: Just too many bugs are just closed with WONTFIX which basically means: We understand and acknowledge the problem, but we won't spend any time on it. bugs.maemo.org is only the messenger... This would be acceptible if maemo would be a really open plattform and anybody could just fix things. But that's not how maemo works and there's such a huge number of bugs that never get fixed and the same issues appear ever now and then again. I e.g. just filed bug 4630 and should have noticed myself that 1504 was the same one filed june 2007. It was never fixed but was just WONFIX'd. And we are not just talking about some weird feature. We are actually talking about something being documented in the maemo api docs. I think Andre and you can still try with bug 4630 if it relates to the Maemo 5 API. Bug 4630 1504 are about themeing a single Gtk widget aspect. There are many other Gtk widgets and icons which aren't (at least fully) themed although they otherwise work fine. This is because it would require (internally): * UI specifications about these widget features and their themeing * Themeing these things (gtkrc graphics) for all themes according to the specification * Writing test programs for these features (as they're not used by the product itself) * Regular testing that the widget features and themeing work (in all themes) according to the specification Which is quite a lot of extra work for things that aren't used at all in the product itself. So, it's not done. If the community wants the extra widgets / widget features and icons to be themed because they actually have some program(s) that use them, I think its better to handle that as a community project...? Why is there a bug reporting system if so many bugs end up with WONTFIX? This doesn't make much sense to me. Again, don't kill the messenger. Maemo 5 bug handling has been already a lot more efficient than in previous versions, thanks to people reproducing old bugs in the Fremantle pre-releases. We expect the good responsiveness to be kept once Maemo 5 is launched and we get new bugs from Maemo 5 users, getting the fixes out in new updates. What we have is a bag of bugs still open affecting mostly Diablo. Because of many reasons those bugs were not handled in time or there were no resources to fix them at the time. The main reason was that we didn't have regular pre-releases of the software before Fremantle. The situation of what happens after the official release, is similar as with the other Linux Distros, once e.g. Ubuntu releases a new version of its distribution, implementing feature bugs and minor bug fixes happen to the next release having new features (currently Fremantle on Maemo), the old release will get only bugfixes to security and other critical issues and eventually even those stop. Ubuntu does new releases at fixed 6 months schedule and the bugfixes to them stop for them pretty quickly except for the LTS releases. Our schedule differs (much) more. Also, we don't currently provide LTS releases (partly because Nokia business model is different, we sell products whereas most other Linux distros basically sell services). Unlike Ubuntu we have a few bugfix releases (like e.g. Debian has) because our releases happen at longer intervals. Because of the more radical HW platform differencies between the device targets of the Maemo SW releases, we cannot (at least currently) offer as good backwards HW compatibility support as can be done on x86. This is something that we need to work with the community (and is currently being done e.g. in context of Mer). Now we are cleaning those bugs week after week and yes, this brings lots of WONTFIX among those that are not an issue anymore in Fremantle. It's more a consequence of a past problem than a reflection of a current problem, though. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Multiple instances of Maemo
Hi, ext Graham Cobb wrote: On Thursday 04 June 2009 20:11:41 Qole wrote: I've asked a similar question before. It seems that maemo-launcher can only have one instance running at a time, so that effectively limits the number of Hildon desktops that can be running to one as well. The answer is to run each one in a separate virtual machine environment. This is also useful for keeping scratchbox instances separate for doing things like compilations against different SDK versions at the same time (scratchbox insists that only one target is running on a single machine at a time). This can be done using full virtualisation environments like VMware or Qemu. Or it can be done using user-mode-linux to run a separate linux instance. What I don't know is if it can be done just using chroot's to separate the environments -- if so, that would be much faster (although there are other disadvantages like having to run as root). Of course, setting up multiple virtual machines might be overkill for what you are trying to achieve. And it may be too slow. Scratchbox1 used by the current SDK shares the /tmp with the host so that apps run in it can e.g. access Xephyr display running on host. If process has a fixed socket location in /tmp, you cannot run multiple instances of it. SB2 doesn't have this limitation (it can redirect /tmp). SB2 is used by SDK+, maybe it helps: http://maemo-sdk.garage.maemo.org/index.html ? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, ext Till Harbaum / Lists wrote: sorry, but i don't get your point. You say that you'd need tests and things for the themeing and thus you don't do it at all? You mean it's acceptible to not theme them at all and have them look ugly but it's not acceptible to give them a quick/untested themeing? Why? To theme something, there needs to be something on which it can be tested. You cannot have a theme for something that doesn't exist on the device (from a graphics artist point of view). UI graphics design is something that starts much earlier than SW development and it moves to future releases much earlier than the SW develoment / bugfixing. By the time there's a public release and public bugs based on it, I don't think there's anymore anybody allocated to do graphics work for that particular release. You basically say either we do things perfectly or we do them in the worse possible way. UI designers aren't clairvoyant. They don't know what specific thing community will want to have been themed few years later. Bugs for previous releases could of course be used as input for this (still needs a test SW though!), but they don't always exist or be appropriate and I don't think that has really been done for graphics like it was done for SW and some UI issues. So, we should improve here. With Fremantle we've started providing regular pre-releases so that things like this can be tested by the community before the release, when there's still time to do also feature requests non-critical fixes for that release. (With the pre-releases you won't see final graphics, but at least it can be tested whether some widget is lacking themeing.) I'd say: If you don't support that feature, then remove it entirely from the libs That would be making them deliberately API ABI incompatible which would kind of make moot the point of using open source components. So, no. and from the api docs. But distributing a library containing stuff you just won't support is pretty odd. But I think it would be appropriate to note in API documents which widgets aren't supported by our UI guidelines / with themeing. Can you make a bug about that so that can be fixed for Fremantle (or Harmattan) API docs? You could avoid a lot of internal testing if you'd actually make use of the fact that bugs.maemo.org gives you a bunch of external testers. Actually that's what happening here: You provide a library containing functionality that is incomplete and untested. And the community did the testing for you and now tells you that what you deliver is incomplete. For graphics the testing needs to happen way before public release of the device. Unfortunately before Fremantle that wasn't possible. And what do you mean by wanting this to be a community project? Is there an easy way the community can replace nokia provided core libraries and theme files? Or do you suggest people should switch to mer if they are unsatisfied with some half-hearted nokia implementation? As the bug is wontfix for Diablo, obviously the only alternative for Diablo is something done by the community. Maybe a new theme based on the default themes on which the app requiring it depends on? Gil, does our theme license allows derivatives? For Fremantle and later releases, community can provide information and working test-cases (applications) for what additional widgets/features should be themed. You say you only fix those features that are actually a problem for your own product and you don't care for widgets that are only used by third party applications. Are you serious? Nokia really isn't interested in supporting third party apps? I was saying that UI designers and graphics artists can fix only problems that they know about, and only if they get to know about them when they still have time to do something about that. Which in case of theme graphics unfortunately is way before the product is released. Support is only provided if there's also a benefit for nokias own applications? Wow ... You can test whether something works, only if you have something that you can test it with. Should be obvious. :-) - Eero PS. It was really annoying/frustrating (not only for 3rd parties, but Nokia developers too) that in earlier products we didn't have regular pre-releases which mean that by the time people were able to test the software and file bugs about it, there wasn't anymore much that could be done about it e.g. feature-wise. Things are much better now with Fremantle. Till Am Freitag 05 Juni 2009 schrieb Eero Tamminen: Bug 4630 1504 are about themeing a single Gtk widget aspect. There are many other Gtk widgets and icons which aren't (at least fully) themed although they otherwise work fine. This is because it would require (internally): * UI specifications about these widget features and their themeing * Themeing these things (gtkrc graphics) for all themes according to the specification
Re: fremantle gettext version too old
Hi, ext Christian Persch wrote: I just installed the fremantle beta SDK to port an application of mine to maemo 5. I ran into a problem though, since the gettext version (0.14.1) that comes with it is too old. The app is a port of a Gnome app that uses msgctxt in its po files; building it in the scratchbox stops with an error like this: Making all in po ../../../po/de.po:1064: keyword msgctxt unknown [etc] Would it be possible to ship fremantle final with a gettext version that supports msgctxt, so that one can build this app without first locally installing a newer gettext in the scratchbox? gettext 0.15 is the first version that supports this, but of course using the latest (0.17) would be preferable. Could you file a bug to bugs.maemo.org (if there isn't yet a one)? Thanks! - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Hi, ext Cornelius Hald wrote: as I was asked to write a bit about the fremantle-ization of the Conboy UI, I first would like to ask some more UI specific questions. Then I can complete this process and write about it. * What happens with the AppMenu-Filters when in portrait mode? The HIG tells me that the 2x5 button layout of the AppMenu will change into a 1x10 button layout. But what happens with the single row of Filters? Will it still be a single row? This is important to know, because it would mean that we have to reduce the length of our labels by around 50%. * What happens to toolbars when in portrait mode? Is there some automatic behavior like showing the toolbar as two rows instead of a single row? Is it scaled? Is the space between the buttons reduced? Or do we have to care about this by ourself, for example listen to some signal and then hiding some buttons or rearranging them? * What happens to any other widget when in portrait mode? * Is there a signal which signals that the screen orientation changed? Application needs to specifically request portrait mode with a window property (I guess there's some API for that), otherwise window manager uses landscape mode for the application window. App can listen to standard XRandr messages for this transition if it wants to, but it's not necessary. * Is there a function to change the screen orientation and can we somehow use this with the beta SDK? It's just a question whether your distro's Xephyr version has XRandR enabled. It should. Then just use xrandr -o left/right/normal for Xephyr's display. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy updates (was: Problems with the fremantle autobuilder...)
Hi, ext Jeremiah Foster wrote: If they are illegal this needs to be clearly communicated in the Packaging Policy document so that packagers know what to name their packages. Currently the version naming is rather unclear and version strings like the one mentioned above is confusing at best. Can we encourage Nokia to work with Maemo to clarify and complete the Maemo Packaging Policy. If there are updates you would want to get to the Maemo policy, please put them to the updates wiki page: http://wiki.maemo.org/Task:Packaging_policy_proposed_changes Before or after discussion on this list. There was earlier (when policy was originally released) also some discussion about minor updates people would want to the policy. If somebody could go through the mailing list (all mails on policy have policy in their subject) and add the suggestions to the proposed changes page, this could speed up getting the policy updated for Fremantle(/Mer/...). Btw. We hope to get the next policy update out as a Debian package which source package will contain the LyX sources for the policy PDF file. - Eero Ps. I added the policy keyword to the subject line of this mail too. :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
Hi, ext Graham Cobb wrote: 3. In extras-testing the betatesters put the software into stress, equipped with Nitro (crash reporter installed in their devices) plus whatever tools they can use voluntarily. Not sure about the requirement to have Nitro installed. The name of this is Crash reporter. (nitro was internal name that's not used anywhere anymore) In particular, what happens to the (potentially large number) of people using maemo-testing who do not have Nitro installed? What happens if none of the people who want to beta test this package have Nitro installed. Using Crash reporter should be voluntary. Depending on application, core dumps may contain information that is private (even passwords). Btw. Crash reporter upload URL can be configured and there can be another configuration file where one can set which apps cores are generated (by default all). This can be used by community projects to collect their own core dumps (but they should take the privacy issue into account). If somebody wants to look into this (based on Fremantle crash-reporter), I can provide more information (names of config files etc). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: microb consumes too much memory?
Hi, ext Zhihai Wang wrote: I use N800 for web surfing www.taobao.comhttp://www.taobao.com, after opening 5 or 6 pages, the whole system becomes very very slow. This always happens! It sometimes even takes 5-6 seconds to bring LCD from dark state to normal state. All the icons in the navigation bar disappeared. But this doesn't happen every time. ps show that browserd and hildon-desktop run into DW state. I.e. disk wait... [...] 5673 user 211944 DW /usr/sbin/browserd -s 5673 5703 root 5728 SW sshd: r...@pts/0 5705 root 1960 SW -sh 5722 user 26072 DW /usr/bin/modest 5727 user 26072 DW /usr/bin/modest Then the system auto rebooted when I was writting this email. Have you swap enabled? It may cause issues: https://bugs.maemo.org/show_bug.cgi?id=2615 - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: B.3 Parallel option needs updating
Hi, ext Faheem Pervez wrote: Hmm, the example given there didn't work for me on the autobuilder. ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS))) PARALLEL += -j$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) endif ^ works for me. On Sat, Mar 28, 2009 at 9:20 AM, Faheem Pervez tripp...@gmail.commailto:tripp...@gmail.com wrote: Hi, In the maemo-policy, the B.3 Parallel option currently says: TODO: When this option has been added to the Debian policy, add link here to an appropriate section. For now, see the discussion in the following Debian policy bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209008; The debian bug linked to has been marked as done as comment #252 says debian-policy_3.8.0.0 has a parallel section. http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options has a section explaining the parallel DEB_BUILD_OPTION and an example that can be used. Thanks! Could you add a note about this also to: http://wiki.maemo.org/Task:Packaging_policy_proposed_changes ? We'll update the policy eventually. (At least the essentials section needs updating for Fremantle.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: xresponse / cnee question re: mimic of multi-key event
Hi, ext Burke, James wrote: Is there a way to use xresponse (or cnee) to mimic a multi-key event such as Alt+F10 ? I haven't tried cnee, but I think it should be able to record Alt+F10 (and then replay it). With Xresponse it would go something like this: xresponse -k ISO_Level3_Shift,2000 xresponse -w 2 -k F10 - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for Fremantle now available
Hi, ext Till Harbaum / Lists wrote: hmm, something seems still to be broken. Looks like opengles-sgx-img-common tries to load a kernel module from its init script but can't due to missing modutils. See https://garage.maemo.org/builder/fremantle/clutter-gtk_0.8.2-maemo0/armel.root.log.FAILED.txt Setting up opengles-sgx-img-common (0.20081031.1-18) ... /scratchbox/devkits/debian-etch/bin/invoke-rc.d: line 1: /sbin/runlevel: No such file or directory I think you're using wrong devkit. What the SDK docs say? Starting SGX services: /etc/init.d/opengles-sgx-img-common: line 46: modprobe: command not found On Debian (Stable/Lenny): - modprobe comes from module-init-tools - runlevel comes from sysvinit package - invoke-rc.d comes from sysv-rc sysvinit is an essential, others aren't, so on Debian sysvinit should be already present and opengles-sgx-img-common should depend from module-init-tools. However, on Maemo / Fremantle (device): - module-init-tools package is like on Debian - upstart is essential package and provides sysvinit package, BUT doesn't provide runlevel tool - runlevel and invoke-rc.d come from mini-rc package which is NOT essential So... Clearly opengles-sgx-img-common has the bug that it doesn't depend on module-init-tools although it should. Could you make a bug about this? I'm not sure about runlevel though. Should runlevel be in upstart package, or should packages have dependency to mini-rc, or should mini-rc be essential? SDK should contain everything that is essential, because essentials are by definition needed for installing additional packages. If SDK (or its minimal rootstrap) doesn't contain them, it's an SDK bug. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for Fremantle now available
Hi, ext Till Harbaum wrote: sorry, i don't understand your reply. Why do you think _i_ am using the wrong version of something? This is the output of the autobuilder. These are all programs/tools/devkits running on the nokia/maemo.org side. I just uploaded a source tarball via scp. Oh, sorry. - bug in in opengles-sgx-img-common dependencies and autobuilder minimal target setup. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: qemu 0.10
Hi, ext Cornelius Hald wrote: Relying to myself :) It seems like I found the problem. If I try to run the new qemu from inside scratchbox I get this: [sbox-DIABLO_ARMEL: ~] /scratchbox/devkits/cputransp/bin/qemu-arm-0.10 /scratchbox/devkits/cputransp/bin/qemu-arm-0.10: /scratchbox/host_shared/lib/libc.so.6: version `GLIBC_2.4' not found (required by /scratchbox/devkits/cputransp/bin/qemu-arm-0.10) /scratchbox/devkits/cputransp/bin/qemu-arm-0.10: /scratchbox/host_shared/lib/libc.so.6: version `GLIBC_2.8' not found (required by /scratchbox/devkits/cputransp/bin/qemu-arm-0.10) /scratchbox/devkits/cputransp/bin/qemu-arm-0.10: /scratchbox/host_shared/lib/libc.so.6: version `GLIBC_2.3.4' not found (required by /scratchbox/devkits/cputransp/bin/qemu-arm-0.10) So it seems that the problem is the compilation of qemu on the host. Because of this qemu has dependencies to different versions of libc6. Versions that are not available from inside scratchbox. I'll try to fix that... Scratchbox is a chroot. If the libraries you compiled something against aren't inside the chroot, the binary won't work. You need to use the scratchbox host toolchain to compile the tools. (SDK installation should include a target for this) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frets on Fire on Fremantle
Hi, ext Jayesh Salvi wrote: I'm not sure why the Fremantle SDK ships with the desktop OpenGL libraries in the first place, though. To be able to run and debug stuff using Clutter (which can use OpenGL or GLES as backend) on x86. The proprietary SGX drivers work only on the device (SGX HW / ARM). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: multiple SDKs on the same sbox
Hi, Gil Quim (Nokia-D/Helsinki) wrote: On Sun, Feb 15, 2009 at 05:17:12PM -0800, Daniel Monteiro wrote: Hello folks, long time since my last email here. I've been silently developing my games for Maemo,but now here I am with a new question regarding Freemantle: Can I have Freemantle and Gregalle in the same sbox? This used to work with older SDK versions, see http://inz.fi/blog/2007/10/22/multi-target-development-for-maemo/ You might want to have a look at the beta release of the Maemo SDK+ based in Scratchbox2: http://maemo-sdk.garage.maemo.org/ SB2 is necessary only if one wants to develop for two different targets *at the same time*. Fremantle SDK supports just fine doing development both for Fremantle and Diablo, just not at the same time[1]. [1] in SB1, one can have only one target selected at the time in the whole system (changed by sb-conf select targetname). target = set of specific rootstrap (root file system), toolchain, qemu and scratchbox devkits versions enabled. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Upstart vs. sysvinit (roadmap)
Hi, ext Tor wrote: Sorry if this has been discussed, but a search revealed nothing. On the Maemo roadmap (http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle) I noticed this: Device startup handled by Upstart instead of sysvinit. Location and format of init scripts differ. This makes me a bit concerned. It sounds like moving away from what's standard (sysvinit), i.e. porting packages will need more work. Daemons I've ported in the past has been mostly just to drop in the Debian package, and a quick check of the init.d script for anything more complex than the slightly limited (but otherwise compatible) feature set available on Maemo. Very very little work. Is there a very compelling reason to move away from something as standard as sysvinit? I haven't even heard about Upstart. Ubuntu has had Upstart since 2006: https://wiki.ubuntu.com/ReplacementInit And started using it in Feisty (i.e. two years ago): http://packages.ubuntu.com/feisty/upstart In Debian it's only in experimental: http://packages.debian.org/source/experimental/upstart (Although Ubuntu is Debian based, it has pretty major differences; uses Upstart instead of sysvinit, uses Dash as /bin/sh instead of Bash[1], has Python as essential package...) - Eero [1] Using interactive shell like Bash as /bin/sh slows down bootup quite considerably. I think Debian's going to do similar switch at some point. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Upstart vs. sysvinit (roadmap)
Hi, ext Mika Yrjölä wrote: Is there a very compelling reason to move away from something as standard as sysvinit? I haven't even heard about Upstart. Ubuntu has had Upstart since 2006: https://wiki.ubuntu.com/ReplacementInit And started using it in Feisty (i.e. two years ago): http://packages.ubuntu.com/feisty/upstart In Debian it's only in experimental: http://packages.debian.org/source/experimental/upstart Of the other major distributions, I'm under the impression that at least Fedora is also using Upstart these days, So it seems: https://admin.fedoraproject.org/pkgdb/packages/name/upstart - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Samba support dropped (was Re: N810 WE)
Hi, ext Andreas Schneider wrote: libsmbclient is the way. And to make use of it you need something like a vfs (gio, kio) in the filemanager or you have to write your own. Fremantle has a Glib version with GIO and kernel has FUSE module... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hellox disappeared from the desktop after it is minimized
Hi, ext Kimmo Hämäläinen wrote: On Thu, 2009-01-15 at 15:58 +0800, ext Alex T. W. LEUNG wrote: Hi maemo developers, I am working to port a legacy xlib based GUI program to maemo, sort of like porting the below hellox.c: http://www.paulgriffiths.net/program/c/srcs/helloxsrc.html The program can be readily compiled in scratchbox and run in N810. However, as soon as I clicked its minimized button, it will disappear from the taskbar, and I will no longer be able to maximize it. You should install .desktop file to /usr/share/applications/hildon direactory Yes. and put X-Osso-Service=hellox No. Unless the program provides corresponding D-BUS service, otherwise D-BUS daemon just kills it. (and service names should use full path) Exec=/usr/bin/hellox, and put hellox as your WM_CLASS. (WM_CLASS is window property, it's set to binary name automatically by Gtk, for plain X programs the program needs to do that manually. Hildon Task Navigator uses it to match the window to the corresponding .desktop file that contains more information about the application.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Some conceptual doubts
Hi, ext Chandra wrote: Can anybody clear the below doubts: 1) What is the use of scratchbox-devkit-apt-https-1.0.3-i386.tar.gz package? 2) What is the use of scratchbox-devkit-doctools-1.0.7-i386.tar.gz package?. It is a document generation tool. We can use this package to generate which type of documents? It provides some documentation generation tools that are needed in building the source packages included into the SDK. Other open source software may also require these (common) documentation tools for their built to succeed. But in most cases you can disable document building if you want to though. Building docs can take a long time (I think it's about half of Gtk package build time). 3) What is the use of scratchbox-devkit-cputransp-1.0.7-i386.tar.gz package? CPU Transparency refers what? Being able to run ARM binaries on your x86 Desktop Maemo development environment. By default GNU autotools (used to configure build most of open source) configures the software for the environment where the code is built. Configuring tests the build environment by building and running small test binaries. When you're cross-compiling in the ARM Scratchbox target on your x86 host, the produced binaries can run only on (real or emulated) ARM CPU. Qemu CPU transparency method allows these ARM binaries to be run (transparently) on the qemu user-space emulator and sbrsh method[1] would run them on a separate ARM machine. transparently meaning that the program or script running the ARM binary doesn't notice that it was for another CPU architecture, it behaves like a native one. [1] Sbrsh is much harder to setup as you need real ARM machine on your network and NFS export between it and your desktop, but it's sometimes useful. It's not technically possible for Qemu user-space emulation to emulate everything. In practice this problem should be very rare and concern only certain threaded programs used in building documentation (which can be resolved by disabling documentation building[2]). [2] IMHO software should always have a separate build target for documentation, it's shouldn't be built by default. You need new docs only when your API changes and you do a new release, so re-generating it usually just wastes developer time. 4) What is the use of Nokia EUSA licensed binary packages package? It contains binaries (I think mainly applications) from the device which Nokia hasn't open sourced (at least yet) and which developers might want to have present when testing their own software in the SDK. 5) In the above query, EUSA refers what? To the license. It has many additional limitations compared to Open Source licenses. 6) What is the use of maemo-sdk-rootstrap_4.1.2_i386.tgz package? 7) In the above query, what is meant by rootstrap? Rootstrap is a root file system corresponding to a set of software that you have on the device. It's used to bootstrap your development environment for given Maemo operating system version and CPU architecture. You cannot install a distribution from scratch, it needs to be bootstrapped with things needed for installing additional packages to the distribution (same as on Debian Ubuntu). Minimal rootstrap include only essential things like package management, sdk-rootstrap includes also pre-installed development packages. 8) In Xephyr command: -ac, -extension, Composite options refers what? X server XComposite extension provides window content update redirection (to a pixmap that can be used e.g. as a texture in OpenGL operations) feature. This is used by so called composite manager (often part of window manager) which redirects the top level application window content to window backbuffers and then composites these window content (textures) to the screen using different OpenGL transformations. To know more, read documentation at freedesktop.org and your Linux distribution Composite manager (KDE v4 kwin, Gnome metacity, Beryl, Compiz...) source code. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtkmozembed: why kill itself in destructor?
Hi,
ext Zhihai Wang wrote:
Deal all,
In EmbedPrivate.cpp,
EmbedPrivate::~EmbedPrivate()
{
sWindowList-RemoveElement(this);
sWidgetCount--;
mNeedFav = PR_FALSE;
if (mProgress)
mProgress-Shutdown();
if (mEventListener)
mEventListener-Shutdown();
mOwningWidget = nsnull;
if (sWidgetCount) return;
gboolean bval = FALSE;
if (gtk_moz_embed_common_get_pref
(G_TYPE_BOOLEAN,gtkmozembed.no_destroy_on_last_window, bval) bval)
return;
int pid = getpid();
EmbedCommon::DeleteInstance();
EmbedGlobalHistory::DeleteInstance();
kill (pid, SIGUSR1);
kill (pid, SIGKILL);
}
Why shall we kill pid in the end? Can't the program exit normally?
AFAIK it can be quite a bit faster.
Normal process exit goes through a lot of destructor code,
freeing things that are anyway freed by the operating system
when process terminates. Browser is threaded, so maybe that
the destructors use locking too...
- Eero
on average free usually takes more time than allocation.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtkmozembed: why kill itself in destructor?
Hi, ext Marius Gedminas wrote: kill (pid, SIGUSR1); kill (pid, SIGKILL); } Why shall we kill pid in the end? Can't the program exit normally? AFAIK it can be quite a bit faster. Normal process exit goes through a lot of destructor code, freeing things that are anyway freed by the operating system when process terminates. Browser is threaded, so maybe that the destructors use locking too... That's what the _exit() function from unistd.h is for, isn't it? I guess it could be used instead. Maybe somebody wants to file a bug? (I think that unlike SIGKILL, debugger can catch _exit()) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: No key events for virtual keyboard?
Hi, ext Till Harbaum / Lists wrote: i have just ported tetrinet for linux to maemo. You can get this from the extras repository. While this works well on the n810's physical keyboard it doesn't work with the virtual keyboard (neither on my n800 running chinock nor an the n810 running diablo). The problem is that all keyboard handling is being done by the original tetrinet for linux code and my maemo gui just forwards all key presses there and updates the gui on the returning function calls from the original code. Thus i have installed a key_press_event handler which then feeds all key presses into the tetrinet engine. Unfortunately the virtual keyboard doesn't generate events. Or to be precise: It does, but for some reason only for the Enter key. How comes? Can i somehow get access to all key presses from the virtual keyboard? VKBD sends the events as X messages to the Gtk editing widget (i.e. something having Gtk IM context) that has the focus. Apparently it still synthetizes couple of keys (apparently Enter and maybe Backspace) as normal X key events, but that doesn't work for all keys (X key events cannot represent all unicode characters). If you ever tried mtetrinet on the n800 or on the n810 with the virtual keyboard you'll find that you can in fact enter things into the entry fields. But these don't enter my keyboard routine but instead magically appear directly in the entry field. This means that the tetrinet engine underneath never saw these key presses and thus ignores them even though they show up in the entry. Thus you e.g. can't type anything in the partyline which limits the functionality pretty much. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
