Re: N800 Video playback
On Monday 19 March 2007 22:34, you wrote: snip Again, if there are any particular questions I can answer, don't be subtle: ask me straight up. If I can answer them (some things I can't necessarily say, some things I don't necessarily know), I will. Thanks, here we go and sorry for a long delay with this answer. First thanks for Xv update which makes it really usable now, MPlayer now uses Xv video output on N800 by default. But there are still some problems. Using unmodified upstream MPlayer code for Xv (N800 with 3.2007.10-7 firmware at the moment) does not work good. It has two at least problems: 1. Lockups which look like cycling two sequential frames, very similar or the same problem as https://maemo.org/bugzilla/show_bug.cgi?id=991 Also keypresses are not very responsive. A fix (or workaround) required changing XFlush to XSync in screen update code, now it looks a lot better. 2. Switching windowed/fullscreen mode generally makes mplayer terminate with the following error messages: X11 error: BadValue (integer parameter out of range for operation) Xlib: unexpected async reply (sequence 0x5db)! A workaround to make this problem less frequent was a code addition which prevents screen updates until we get Expose even notification. All these Xv patches for MPlayer code can be viewed here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayerdiff_format=hview=revrev=166 I really don't know much about X11 programming and only started to learning it, so your help with some advice may be very useful. Looks like MPlayer code X11/Xv output code is a big mess with many tricks and workarounds added to work on different systems over time. Maybe it contains some bugs which get triggered on N800 only, but apparently this code is used for other systems without any problems. Can you try experimenting a bit with MPlayer (upstream release) yourself to check how it works with N800 xserver? Maybe it can reveal some xserver bugs which need to be fixed? Also if MPlayer has some apparently bad X11 code, preparing a clean patch and submitting it upstream maybe a good idea. One more strange thing with Xv on N800 can be reproduced by trying to watch standard N800 demo video in MPlayer. It has an old familiar tearing line in the bottom part of the screen and the performance is very poor. The same file plays fine in the standard video player. The only difference is that mplayer respects video aspect ratio (this video is not precisely 15:9 but slightly off) and shows some small black bands above and below picture and default video player scales it to fit the whole screen. Disabling aspect ratio in mplayer with -noaspect option also 'fixes' this problem. Using benchmark option we get the following numbers: # mplayer -benchmark -quiet Nokia_N800.avi [...] BENCHMARKs: VC: 33,271s VO: 66,768s A: 0,490s Sys: 5,703s = 106,232s BENCHMARK%: VC: 31,3189% VO: 62,8517% A: 0,4614% Sys: 5,3681% = 100,% BENCHMARKn: disp: 1732 (16,30 fps) drop: 778 (30%) total: 2510 (23,63 fps) # mplayer -benchmark -quiet -noaspect Nokia_N800.avi [...] BENCHMARKs: VC: 32,226s VO: 14,350s A: 0,456s Sys: 55,699s = 102,731s BENCHMARK%: VC: 31,3694% VO: 13,9687% A: 0,4439% Sys: 54,2180% = 100,% BENCHMARKn: disp: 2501 (24,35 fps) drop: 0 (0%) total: 2501 (24,35 fps) So when showing video with proper aspect ratio, we get tearing back and more than 4x slowdown in video output code (66,768s vs. 14,350s). This all results in 30% of frames dropped. These were the 'usability' problems with Xv. Now we get to performance related issues. As YV12 is not natively supported by hardware, some color format conversion and bytes shuffling in video output code is unavoidable. It is a good idea to optimize this code if we need a good performance for high resolution video playback. Color format conversion can be optimized using assembly, for example maemo port of mplayer has a patch for assembly optimized yv12- yuy2 (yuv420p - yuyv422) nonscaled conversion which provides a very noticeable ~50% improvement on Nokia 770: https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayerrev=129view=rev Also here is a JIT accelerated scaler for yv12- yuy2 (yuv420p - yuyv422) conversion, it is very fast and supports pixels interpolation (good for image quality) : https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/libswscale_nokia770/?root=mplayer I have seen your code in xserver which does the same job for downscaling, but in nonoptimized C and with much higher impact on quality. Using JIT scaler there can improve both image quality and performance a lot. The only my concern is about instruction cache coherency. As ARM requires explicit instructions cache flush for self modyfying or dynamically generated code, I wonder if using just mmap is safe (does it flush cache for allocated region of memory?). Maybe maemo kernel hackers/developers can help with this information? It should be noted, that all this assembly
Re: [maemo-developers] How to extend Hildon Input Methods
Hi, I've forwarded your message (again) to the Bora team. Hope they can fix this ASAP. Sorry for the inconvinience. For the mean time, I guess you could use the same header packages which available in Bora 3.0. Pada hari Rabu, tanggal 18/04/2007 pukul 17:30 +0200, ext Guard][an menulis: Hello Mohammad, Since your reply to my questions, the wiki page http://www.maemo.org/platform/docs/howtos/howto_him_bora.html has not been updated :( More over, http://repository.maemo.org/stable/3.1/content_comparison.html indicates that packages libhildon-input-method-framework-header-sdk-dev and libhildon-input-method-ui-header-sdk-dev have been removed. As a consequence, it is not possible anymore to compile the sample input method plugin at http://www.maemo.org//downloads/him-plugin-examples/him-plugins-sdk-example-0.0.2.tar.gz As a workaround, I will revert to bora 3.0. However, what's the solution for bora 3.1 ? Regards, G. Mohammad Anwari wrote: Pada hari Senin, tanggal 15/01/2007 pukul 13:45 +0100, ext Guard][an menulis: The tutorial mentions libhildon-input-method-header-sdk-dev and libhildon-input-method-framework-header-sdk-dev packages but the real name of the first package seems to be libhildon-input-method-ui-header-sdk-dev. You are correct. I'm cc:-ing bora-feedback hoping they can fix this. Also, it would be nice to have more detailed documentation on key types and attributes usage. For instance, the key alpha=ALPHA size=2q/key markup seems rather obscure to me, particularly the alpha=ALPHA part. Also, how do you define a modifier key ? Unfortunately, there is no modifier key :( And how do you specify tabs like the abc ABC 1!+ tabs on the thumb keyboard. In fact, having Put label attribute in the sublayout tag. ... keyboard layout=THUMB sublayout type=LOWERCASE label=abc variance_index=1 ... the xml versions of the .vkb files deployed on the device would really help understanding how to achieve the abc/ABC click on the same tab changes the case behavior. Use variance index for that, so we would have: ... keyboard layout=THUMB sublayout type=LOWERCASE label=abc variance_index=1 ... sublayout type=UPPERCASE label=ABC variance_index=0 ... ... Is there any plan to make these .xml files available ? Sorry, no plan for that. Regards. G. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
Hi, On Fri, Apr 20, 2007 at 09:41:45AM +0300, ext Siarhei Siamashka wrote: 1. Lockups which look like cycling two sequential frames, very similar or the same problem as https://maemo.org/bugzilla/show_bug.cgi?id=991 Also keypresses are not very responsive. A fix (or workaround) required changing XFlush to XSync in screen update code, now it looks a lot better. I assume this is basically just a race condition, and it doesn't trigger on other systems, because they're a lot quicker. 2. Switching windowed/fullscreen mode generally makes mplayer terminate with the following error messages: X11 error: BadValue (integer parameter out of range for operation) Xlib: unexpected async reply (sequence 0x5db)! A workaround to make this problem less frequent was a code addition which prevents screen updates until we get Expose even notification. Ditto. I really don't know much about X11 programming and only started to learning it, so your help with some advice may be very useful. I mainly lurk on the server side, however. Looks like MPlayer code X11/Xv output code is a big mess with many tricks and workarounds added to work on different systems over time. Maybe it contains some bugs which get triggered on N800 only, but apparently this code is used for other systems without any problems. Can you try experimenting a bit with MPlayer (upstream release) yourself to check how it works with N800 xserver? Maybe it can reveal some xserver bugs which need to be fixed? Also if MPlayer has some apparently bad X11 code, preparing a clean patch and submitting it upstream maybe a good idea. Unfortunately, I don't have the time to do this. Sorry. One more strange thing with Xv on N800 can be reproduced by trying to watch standard N800 demo video in MPlayer. It has an old familiar tearing line in the bottom part of the screen and the performance is very poor. The same file plays fine in the standard video player. The only difference is that mplayer respects video aspect ratio (this video is not precisely 15:9 but slightly off) and shows some small black bands above and below picture and default video player scales it to fit the whole screen. Disabling aspect ratio in mplayer with -noaspect option also 'fixes' this problem. Using benchmark option we get the following numbers: # mplayer -benchmark -quiet Nokia_N800.avi [...] BENCHMARKs: VC: 33,271s VO: 66,768s A: 0,490s Sys: 5,703s = 106,232s BENCHMARK%: VC: 31,3189% VO: 62,8517% A: 0,4614% Sys: 5,3681% = 100,% BENCHMARKn: disp: 1732 (16,30 fps) drop: 778 (30%) total: 2510 (23,63 fps) # mplayer -benchmark -quiet -noaspect Nokia_N800.avi [...] BENCHMARKs: VC: 32,226s VO: 14,350s A: 0,456s Sys: 55,699s = 102,731s BENCHMARK%: VC: 31,3694% VO: 13,9687% A: 0,4439% Sys: 54,2180% = 100,% BENCHMARKn: disp: 2501 (24,35 fps) drop: 0 (0%) total: 2501 (24,35 fps) So when showing video with proper aspect ratio, we get tearing back and more than 4x slowdown in video output code (66,768s vs. 14,350s). This all results in 30% of frames dropped. Okay, I'll take a look at this. My guess is that the scaling we're seeing prevents us from using the LCD controller's overlay, possibly because it's done in software. These were the 'usability' problems with Xv. Now we get to performance related issues. As YV12 is not natively supported by hardware, some color format conversion and bytes shuffling in video output code is unavoidable. It is a good idea to optimize this code if we need a good performance for high resolution video playback. Color format conversion can be optimized using assembly, for example maemo port of mplayer has a patch for assembly optimized yv12- yuy2 (yuv420p - yuyv422) nonscaled conversion which provides a very noticeable ~50% improvement on Nokia 770: https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayerrev=129view=rev Also here is a JIT accelerated scaler for yv12- yuy2 (yuv420p - yuyv422) conversion, it is very fast and supports pixels interpolation (good for image quality) : https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/libswscale_nokia770/?root=mplayer The primary conversion we do isn't planar - packed (this is a fallback for when the video is obscured), but from planar to another custom planar format. It would be good to get ARM assembly for the fallback path, but most of the problem when using packed lies in having to transfer the much larger amount of data over the bus. There's one optimisation that could be done for the YUV420 conversion (the custom planar format that Hailstorm takes), which removes a branch, ensures 32-bit writes always (instead of one 32-bit and one 16-bit per pixel), and unrolls a loop by half. Might be interesting to see what effect this has, but I think it'll still be rather small. I have seen your code in xserver which does the same job for downscaling, but in nonoptimized C and with much higher impact on quality.
setting up Maemo appliance vmware
Hi maemo developers, i just finish download the maemo appliance vmware using torrent, but there are so many downloaded files, and i dont know how to make up an virtual machine from those files. does anyone having experience in using Maeme appliance vmware, let me know how to set up the virtual machine after download the files. thanks - Ahhh...imagining that irresistible new car smell? Check outnew cars at Yahoo! Autos.___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
trouble to disconnect from WiFi AP
Hi, In my apllication I'm trying to ensure connection to specific Wifi network Access Point AP. I'm using osso_iap_connect() call to connect using previously configured profile and it works well when no wifi connection is currently selected. When N800 is already connected to another WiFi AP, calling osso_iap_connect() blocks application until WiFi connection is dropped using Connection manager UI. calling osso_iap_disconnect(...) with OSSO_IAP_ANY or with realIAP profile name as parameter returns no error but doesn't disconnect current WiFi connection. I have also tried to disconnect through D-BUS using disconnect_iap_async() in following code, but it didn't work either. Any hint will be really appreciated. --- begin of sample code -- void send_message_no_reply(DBusMessage *msg); int disconnect_iap_async(const char *iap); DBusConnection *get_connection(); DBusConnection *get_connection() { static DBusConnection *connection = NULL; if (connection == NULL) { connection = dbus_connection_open( DBUS_SYSTEM_BUS_DEFAULT_ADDRESS, NULL); if (!connection) return NULL; if (!dbus_bus_register(connection, NULL)) { dbus_connection_disconnect(connection); dbus_connection_unref(connection); connection = NULL; return NULL; } } return connection; } void send_message_no_reply(DBusMessage *msg) { DBusConnection *conn; conn = get_connection(); dbus_message_set_no_reply(msg, TRUE); dbus_connection_send(conn, msg, NULL); } int disconnect_iap_async(const char *iap) { DBusMessage *msg; msg = dbus_message_new_method_call( ICD_DBUS_SERVICE, ICD_DBUS_PATH, ICD_DBUS_INTERFACE, ICD_DISCONNECT_REQ); if (msg == NULL) return -1; if (!dbus_message_append_args(msg, DBUS_TYPE_STRING, iap, DBUS_TYPE_INVALID)) { dbus_message_unref(msg); return -1; } send_message_no_reply(msg); dbus_message_unref(msg); return 0; } --- end of sample code -- Jan Vachun Spintec s.r.l. C.so Torino 89/A Ferriera di Buttigliera Alta (TO), 10090 tel: +39 011 9348228 fax: +39 011 9348861 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
Daniel Stone wrote: Which Epson docs? fanoush.wz.cz/maemo/S1D13745A01SpecRev1.0.gm.zip Got it from Epson Electronics like the one mentioned here http://maemo.org/pipermail/maemo-developers/2006-December/006638.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Boot bora as root
ext Chris Taylor [EMAIL PROTECTED] writes: at any rate any ideas what might be causing the socket to fail? Chris, did you get my private mail? I explained a bit there. (I didn't see this thread until now, sorry.) In a nutshell, the frontend starts the backend via sudo, and that might fail when the frontend doesn't run as user. When sudo fails, the frontend goes catatonic (which is a known bug that has been fixed in Sardine). ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: Maemo SDK and Debian 64 bits
Hi David, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext David Hautbois Sent: Thursday, April 19, 2007 21:46 To: Maemo developers mailing-list Subject: Maemo SDK and Debian 64 bits Hi Does the maemo SDK work fine with a 64 bits linux distribution ? On the maemo web site, we can read : * Intel compatible x86 processor, 500 MHz or faster * 256 MB RAM or more * 2 GB free hard disk space * Linux OS (Debian http://www.debian.org/ or Ubuntu http://www.ubuntu.com/ are recommended, but other fairly recent distributions should also work) Does it include X86_64 ? At least, I am running the SDK on my Ubuntu/Feisty AMD64 system without any problems. I created a chroot environment to install the SDK in the 32-bit environment. Best wishes, Dirk. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches available
Hi, do you or somebody else here know if the 770 also has this host detection via the ID pin feature? And why does the USB chip of the N800 don't need this 5V from external? I thougt it also need it, because there is only 3V and no 3 to 5V converter inside the device. Regards, Andi Tony Lindgren schrieb: Hi all, I've been meaning to do this for a while, but only now got into it after sorting out one more issue with the N800 USB DMA. I've posted some experimental N800 host mode patches to [1] for people to play with. Although the N800 is not built to support host or OTG mode and does not have a mini-B connector, you can still use it via some software hacks. The patches are from the linux-omap git tree at [2] with some extra patches to force N800 into host mode. The driver is still very much experimental and can cause file system corruption on USB drives, so YMMV :) Anyways, let me know of issues and fixes. Regards, Tony [1] http://muru.com/linux/n800-usb-host/ [2] http://master.kernel.org/git/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
Siarhei Siamashka 写道: I have seen your code in xserver which does the same job for downscaling, but in nonoptimized C and with much higher impact on quality. Using JIT scaler there can improve both image quality and performance a lot. The only my concern is about instruction cache coherency. As ARM requires explicit instructions cache flush for self modyfying or dynamically generated code, I wonder if using just mmap is safe (does it flush cache for allocated region of memory?). Maybe maemo kernel hackers/developers can help with this information? arm linux support flush icache by syscall cacheflush, qemu have this function: static inline void flush_icache_range(unsigned long start, unsigned long stop) { register unsigned long _beg __asm (a1) = start; register unsigned long _end __asm (a2) = stop; register unsigned long _flg __asm (a3) = 0; __asm __volatile__ (swi 0x9f0002 : : r (_beg), r (_end), r (_flg)); } you can reference kernel source arch/arm/kernel/traps.c and include/asm-arm/unistd.h ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Continuous reboot problem with the N770 hacker edition
Hello, I used the N770 with the hacker edition of OS2007 heavily last week and it broke: The device is rebooting constantly, even putting it into RD mode did not help getting rid of this. The sequence is 1. blue boot progress bar 2. Nokia hands and sound 3. almost immidiately after the sound, a white stripe appears on the left of the display. Looks like this is the Maemo menue bar. Then the screen becomes white 4. after approx. 19 seconds the device reboots and continues with 1. I interrupt the reboot cycles by removing the battery. I am not aware that I did something uncommon before that happend, except accessing via USB to the MMC card (which I do very rarely). Removing the cable again apparently broke the MMC and I had to run e2fsck. Before I flash the device, I though I ask here if somebody is interested in some more debug data (and knows how I get them). Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Application Manager not loaded on simulator
Hi maemo's developer, finally im able to set up an maemo development using maemo appliance vmware :). But when i start af-sb-init.sh start, on the simulator nothing installed.Only control panel and maemo-pad sample. How can i make Application Manager show up on simulator regards gusti-andika - Ahhh...imagining that irresistible new car smell? Check outnew cars at Yahoo! Autos.___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Continuous reboot problem with the N770 hacker edition
At Fri, 20 Apr 2007 18:26:42 +0200, Rainer Dorsch [EMAIL PROTECTED] wrote: I used the N770 with the hacker edition of OS2007 heavily last week and it broke: The device is rebooting constantly, even putting it into RD mode did not help getting rid of this. The sequence is 1. blue boot progress bar 2. Nokia hands and sound 3. almost immidiately after the sound, a white stripe appears on the left of the display. Looks like this is the Maemo menue bar. Then the screen becomes white 4. after approx. 19 seconds the device reboots and continues with 1. I interrupt the reboot cycles by removing the battery. I'm using Gergale and this happens to me about once every week or two. I had enough time after the device boots to run xterm and top. The problem was jffs2_gcd_mtd4 was taking 100% of the CPU and a fair amount of memory. This led me to suspect that the OOM killer was killing an essential task and thereby causing the watchdog timer to reset the device. To prevent this, I simply disabled the watchdog time. Now when this happens, jffs2_gcd_mtd4 burns CPU (and thus is unusable) but it is a few hours between resets. After about day or two, the device is happy again. Neal ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches available
On 4/20/07, Andreas Hubel [EMAIL PROTECTED] wrote: Hi, do you or somebody else here know if the 770 also has this host detection via the ID pin feature? And why does the USB chip of the N800 don't need this 5V from external? I thougt it also need it, because there is only 3V and no 3 to 5V converter inside the device. Actually there is 5V 100 mA charge pump included in the chipset. It includes native OTG support and it's just a matter of turning on host (OTG) mode and the 5V source on. This will of course affect battery life, but your average USB key, keyboard, or mouse shouldn't draw too much. Larry Regards, Andi Tony Lindgren schrieb: Hi all, I've been meaning to do this for a while, but only now got into it after sorting out one more issue with the N800 USB DMA. I've posted some experimental N800 host mode patches to [1] for people to play with. Although the N800 is not built to support host or OTG mode and does not have a mini-B connector, you can still use it via some software hacks. The patches are from the linux-omap git tree at [2] with some extra patches to force N800 into host mode. The driver is still very much experimental and can cause file system corruption on USB drives, so YMMV :) Anyways, let me know of issues and fixes. Regards, Tony [1] http://muru.com/linux/n800-usb-host/ [2] http://master.kernel.org/git/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches available
Larry Battraw wrote: This will of course affect battery life, but your average USB key, keyboard, or mouse shouldn't draw too much. Not sure how you can get it in linux but at least in XP you can check usb hub properties in device manager and see power requirements reported by connected devices. My usb key reports 100mA, sd/mmc card reader 250mA. Don't have usb keyboard around to check. The values should be maximal, i.e. device may in fact consume less. I hope it should not consume more. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 experimental host mode patches available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frantisek Dufka wrote: Larry Battraw wrote: This will of course affect battery life, but your average USB key, keyboard, or mouse shouldn't draw too much. Not sure how you can get it in linux but at least in XP you can check usb hub properties in device manager and see power requirements reported by connected devices. My usb key reports 100mA, sd/mmc card reader 250mA. Don't have usb keyboard around to check. The values should be maximal, i.e. device may in fact consume less. I hope it should not consume more. This information is available from /proc/bus/usb/devices in Linux. - -- Andrew J. Barr Thunderbird/1.5.0.10 (compatible; Icedove 1.5; X11; en-US; Linux 2.6.21-rc7 ppc) (Debian/1.5.0.10dfsg.1) Why must I fail at every attempt at masonry? -- Homer Simpson, Mom and Pop Art [AABF15] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKRgahuM+Z62a52oRAjguAJ9PXsg/tSgux941fyQ5gDgCvgNaiACguAgr BlwJi8BPn3K0QSq70EB9am0= =LP9h -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers