Wiki page of the Day: Video encoding
Hi all, This is the last time I'll be cross-posting WPotD announcements - from now on I'll use the new [EMAIL PROTECTED] list for WPotD updates, and I invite any of you interested in community processes, the wiki or the development of the website to join that list. Thank you very much for the help on USB networking - it's now been cleaned up put to bed, as has booting from a flash card and partitioning a flash card (thanks in large part to General Antilles's monster contribution). A special thank you also to the anonymous contributor who updated playing ogg files and allowed me to remove the in progress tags this morning. The wiki is coming along nicely! The WPotD for today is Video encoding http://wiki.maemo.org/Video_encoding - an article which, it seems to me, is in dire need of reduction. From my own experience, the page should be an instruction manual on installing tablet-encode and its dependencies, and that's it. Thank you again (and especially General Antilles, the tireless warrior) for your help, and let's keep the momentum through this week. If you only have 5 minutes to contribute, then picking one paragraph, and tidying up the text or deleting it (if needed) is a great contribution. Re-reading other people's edits to spot corrections is also a great help. Cheers, Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Wiki page of the Day: Video encoding
On Mon, 2008-07-07 at 12:05 +0200, Dave Neary wrote: Hi all, This is the last time I'll be cross-posting WPotD announcements - from now on I'll use the new [EMAIL PROTECTED] list for WPotD updates, and I invite any of you interested in community processes, the wiki or the development of the website to join that list. Thank you very much for the help on USB networking - it's now been cleaned up put to bed, as has booting from a flash card and partitioning a flash card (thanks in large part to General Antilles's monster contribution). A special thank you also to the anonymous contributor who updated playing ogg files and allowed me to remove the in progress tags this morning. The wiki is coming along nicely! The WPotD for today is Video encoding http://wiki.maemo.org/Video_encoding - an article which, it seems to me, is in dire need of reduction. From my own experience, the page should be an instruction manual on installing tablet-encode and its dependencies, and that's it. Have to vehemently disagree with this, I've referred to this page for the manual conversion instructions plenty of times, as it tells me how to use tools that I already have on my system and are useful for non-tablet cases too... Maybe it should be split into simple/advanced sections perhaps, but a lot of that information is useful. --Chris ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Robert Bodo is out of the office.
I will be out of the office starting 2008.07.07 and will not return until 2008.07.21. I will respond to your message when I return. In urgent case you can call me on this phone number: +36304274572 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
DSP SBC encoder update
Hi all, I'm happy to say I've got the DSP task working for more than 4s now, in fact it even runs all the way to the end of the song, as expected ;). You can download version 1.0.0 from here: https://garage.maemo.org/projects/dsp-sbc/. This is for Diablo only. This consists of a tarball containing the DSP task and command file, a tweaked Bluez-utils which can use said DSP task for SBC encoding (so it will just work with mplayer and the like) and an installation script which writes some config data about the new task to the DSP dynamic loader conf file and then extracts the tarball, installs the deb and tells you to reboot. [Note to would-be DSP hackers: rather than rebooting, you can just run dsp_dld in the terminal to restart the loader daemon, but make sure you've made a symlink from /lib/dsp/dsp_dld_avs.conf - /lib/dsp/dsp_dld.conf as this is where it expects to find the conf file.] If you want to go back to software encoding, rename the sbcenc.o file (in /lib/dsp/modules) and it will automatically fall back to the original software method (it falls back whenever the DSP fails, and renaming the task will cause it to fail). I've not checked to see if the fallback method is as quick as the original code, I'd be interested to know though if anyone is bored. I should add some logic using an env var or similar to switch method - anyone have some example code I could use? You still need to enable a2dp with either johnx's a2dp deb which can be found here: http://www.internettablettalk.com/forums/showthread.php?t=13468 or manually (use the deb, far easier). I should add that running DSP tasks will move the CPU frequency to 330MHz, so this is probably not the answer to everyone's prayers with regard to freeing the CPU to do Xvid decoding or the like. There is a kernel patch to not force the CPU to 330MHz (the DSP runs slower) and I'll do some testing to see if the DSP task can run in real-time at the lower DSP clock speed. Then it will be significantly more useful. In the meantime, it may or may not use less power this way, please let me know if you do any testing. Next bit is for those interested in the gory details: This is pretty much the same code I had running a week ago or thereabouts, and it was only encoding ~4s of audio in real-time (using bulk transfers ioctls for sync). I tested the SW encoder and it would encode a test file more slowly than the DSP method but would output more seconds worth of audio when testing with mplayer, which made me wonder if the DSP was just cursed (or perhaps something to do with the CPU speed being set to 330MHz when the DSP is running...). The released code is from my mk2 branch: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk2/?root=dsp-sbc The change which has allowed it to encode an entire song rather than just a few seconds was to move the input and output buffers from SDRAM (OMAP main memory) to SRAM (DSP fast single access memory). There are probably other things which would benefit from being moved, the sbc-priv data (or parts thereof) for one. This structure is pretty big so I allocated it in SDRAM, but at least parts of it might be better off in faster local memory. This is something to look at. I tested the speed of the bulk transfers (29s au file, took ~20s to encode with the DSP and ~9s to just transfer the data), which are pretty slow as you can see. I then decided to convert the task to use shared memory and some polling and sleeping to synchronise (mk4 branch: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk4/?root=dsp-sbc). The mk4 code takes absolutely forever to run though, the same test file which takes ~20s with the bulk transfer method (mk2) takes ~45s using shared memory. Unfortunately there appear to be no clocks available in the DSP kernel (which makes benchmarking code quite tricky) and also means you can't sleep() between polling memory. So the DSP task sits in a tight polling loop (bad!) and the ARM sleeps for 1us and then polls the shared memory. Anyway, there's something not right and I'm not sure what it might be (the DSP manages ~650 loops before the ARM presents it with input data), the DSP then processes and the ARM sleeps for 1 loop (1us) before the DSP gives it back the encoded data, and so on. This is not a good method for the task to use, but I am interested to know why it's so slow, so may do some more work on it eventually. Talking about a lack of clocks, the mk3 branch was my attempt to rewrite the sbc conversion fns using DSP intrinsics, dual MACs, and the like. It doesn't produce the correct output data (probably some issue with my Q15 arithmetic, this was only the first hack at the code) but also didn't improve the speed of the code (and with no clock fns it's hard to tell where the bottleneck is) so I'm leaving it alone for the time being. Last but not least, even when running at 165MHz (or whatever the conservative governor produces) the sw fall back code doesn't produce any error messages (when
Re: Wiki page of the Day: Video encoding
On Mon, Jul 7, 2008 at 11:38 AM, Chris Lord [EMAIL PROTECTED] wrote: On Mon, 2008-07-07 at 12:05 +0200, Dave Neary wrote: The WPotD for today is Video encoding http://wiki.maemo.org/Video_encoding - an article which, it seems to me, is in dire need of reduction. From my own experience, the page should be an instruction manual on installing tablet-encode and its dependencies, and that's it. Have to vehemently disagree with this, I've referred to this page for the manual conversion instructions plenty of times, as it tells me how to use tools that I already have on my system and are useful for non-tablet cases too... Should wiki.maemo.org /really/ be a handy reference guide to other pieces of software for non-tablet use cases? Admittedly, I'm probably biased as Dave name-checked my software. IMNSHO, I'd say detail on the tablet-specific encoders: tablet-encode, Nokia's ITVC, Media Converter and the other one (n800vc?) and links to non-tablet specific encoders which either output tablet-compatible out-of-the-box or have profiles for them. Maybe it should be split into simple/advanced sections perhaps, but a lot of that information is useful. How to use ffmpeg/transcode/vlc/mencoder in general is best elsewhere, IMHO. However, a detailed page describing the key issues and requirements of tablet video is a good idea. Just not on this page. Such a page should probably have a section per OS version saying how the limitations moved forward with each one. Anyway, this should be held on the talk page, rather than on the -dev mailing list. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder update
Hi, Glad you got it working, will grab a copy when I go home :) Just some notes: I found that patch I mentioned: http://pastebin.com/m34ed3cd3 It's supposidly adds sysfs interface for modding the dsp speed. If that fails, a modification to n800-dvfs.c will work :) (I think I've got a kernel stashed away with DSP/CPU at 133/400.) Using this snippet of code in the installer sh will automatically relaunch the script as root if you are not root: http://www.internettablettalk.com/forums/showpost.php?p=122754postcount=5 Cheers, Faheem On Mon, Jul 7, 2008 at 11:43 AM, Simon Pickering [EMAIL PROTECTED] wrote: Hi all, I'm happy to say I've got the DSP task working for more than 4s now, in fact it even runs all the way to the end of the song, as expected ;). You can download version 1.0.0 from here: https://garage.maemo.org/projects/dsp-sbc/. This is for Diablo only. This consists of a tarball containing the DSP task and command file, a tweaked Bluez-utils which can use said DSP task for SBC encoding (so it will just work with mplayer and the like) and an installation script which writes some config data about the new task to the DSP dynamic loader conf file and then extracts the tarball, installs the deb and tells you to reboot. [Note to would-be DSP hackers: rather than rebooting, you can just run dsp_dld in the terminal to restart the loader daemon, but make sure you've made a symlink from /lib/dsp/dsp_dld_avs.conf - /lib/dsp/dsp_dld.conf as this is where it expects to find the conf file.] If you want to go back to software encoding, rename the sbcenc.o file (in /lib/dsp/modules) and it will automatically fall back to the original software method (it falls back whenever the DSP fails, and renaming the task will cause it to fail). I've not checked to see if the fallback method is as quick as the original code, I'd be interested to know though if anyone is bored. I should add some logic using an env var or similar to switch method - anyone have some example code I could use? You still need to enable a2dp with either johnx's a2dp deb which can be found here: http://www.internettablettalk.com/forums/showthread.php?t=13468 or manually (use the deb, far easier). I should add that running DSP tasks will move the CPU frequency to 330MHz, so this is probably not the answer to everyone's prayers with regard to freeing the CPU to do Xvid decoding or the like. There is a kernel patch to not force the CPU to 330MHz (the DSP runs slower) and I'll do some testing to see if the DSP task can run in real-time at the lower DSP clock speed. Then it will be significantly more useful. In the meantime, it may or may not use less power this way, please let me know if you do any testing. Next bit is for those interested in the gory details: This is pretty much the same code I had running a week ago or thereabouts, and it was only encoding ~4s of audio in real-time (using bulk transfers ioctls for sync). I tested the SW encoder and it would encode a test file more slowly than the DSP method but would output more seconds worth of audio when testing with mplayer, which made me wonder if the DSP was just cursed (or perhaps something to do with the CPU speed being set to 330MHz when the DSP is running...). The released code is from my mk2 branch: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk2/?root=dsp-sbc The change which has allowed it to encode an entire song rather than just a few seconds was to move the input and output buffers from SDRAM (OMAP main memory) to SRAM (DSP fast single access memory). There are probably other things which would benefit from being moved, the sbc-priv data (or parts thereof) for one. This structure is pretty big so I allocated it in SDRAM, but at least parts of it might be better off in faster local memory. This is something to look at. I tested the speed of the bulk transfers (29s au file, took ~20s to encode with the DSP and ~9s to just transfer the data), which are pretty slow as you can see. I then decided to convert the task to use shared memory and some polling and sleeping to synchronise (mk4 branch: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk4/?root=dsp-sbc). The mk4 code takes absolutely forever to run though, the same test file which takes ~20s with the bulk transfer method (mk2) takes ~45s using shared memory. Unfortunately there appear to be no clocks available in the DSP kernel (which makes benchmarking code quite tricky) and also means you can't sleep() between polling memory. So the DSP task sits in a tight polling loop (bad!) and the ARM sleeps for 1us and then polls the shared memory. Anyway, there's something not right and I'm not sure what it might be (the DSP manages ~650 loops before the ARM presents it with input data), the DSP then processes and the ARM sleeps for 1 loop (1us) before the DSP gives it back the encoded data, and so on. This is not a good method for the
maemo.org/downloads automatic updates from Extras
The maemo.org downloads section[1] now automatically picks up updated versions from the Maemo Extras repository. The 'Fresh' list will show the applications that were recently uploaded or promoted to Extras. Developers used to need to update their application entry themselves. By doing the updating automatically, users should not see outdated information about your application. For the automatic update to work your application needs to be: 1. Available in Maemo Extras 2. Available in the maemo.org downloads section where the 'Project ID' equals the name of your debian package. Package updates are fetched from the most recent repository for each OS we support. Diablo for OS2008, Bora for OS2007 and gregale for OS2006. One enhancement I would like to add is automatically update the 'Changes in latest version' field for the entry in downloads. I would like comments from the community on how developers should supply this information. One option would be to fetch it from the changelog. Problems here are that there aren't many packages using a changelog at the moment and we would need to filter out the real changes from the packaging revision updates. Another option would be to let the developer enter this data while promoting the package to extras. We could add this step to the promotion interface. Comments are appreciated. -- Niels Breet maemo.org webmaster [1] http://maemo.org/downloads/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Wiki page of the Day: Video encoding
Hi, Chris Lord wrote: On Mon, 2008-07-07 at 12:05 +0200, Dave Neary wrote: The WPotD for today is Video encoding http://wiki.maemo.org/Video_encoding - an article which, it seems to me, is in dire need of reduction. From my own experience, the page should be an instruction manual on installing tablet-encode and its dependencies, and that's it. Have to vehemently disagree with this, I've referred to this page for the manual conversion instructions plenty of times, as it tells me how to use tools that I already have on my system and are useful for non-tablet cases too... I'm not opposed to keeping advanced useful information around. In this case, though, it's not educational data. It's a set of magic incantations for mencoder. I'd much prefer to be able to refer someone to usable, well written mencoder documentation, or explain what the various arguments mean and what they're for. I'd prefer even more for mencoder to take the path of tablet-encode and provide a set of intelligent presets so that I don't even have to learn. Maybe it should be split into simple/advanced sections perhaps, but a lot of that information is useful. OK for a split. Care to help streamline things, and label the behind the scenes stuff as advanced/extra material? Cheers, Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to disconnect current connection using libconic (or directly dbus)?
Hi! I have been trying to disconnect my current connection using libconic's con_ic_connection_disconnect() method but it seems to me that it doesn't do anything. I can't see any errors and still nothing seems to happen. I also tried to disconnect directly using dbus-send but didn't get it working. I would also like to know if there is a way to disable the Internet Connectivity Daemon (ICd)? I would really appreciate help with this problem. I have tried almost eveything to get this working.. BR, Timo Heinonen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Shell API to call maemo-mapper commands, functions, options ?
Hi, what I really need is shell script to emulate GUI actions in maemo-mapper. Any chance to have shell script to interact with maemo-mapper basic functions/commands ? Frankly speaking I would like to add few more options, have more selection choices, nothing special. User friendly shell API is what I need. If you are aware how to run maemo-mapper from a command line with options, please tell me how. Ok. I can run maemo-mapper from a command line. Any chance to have fifo pipe and send parameters from command line to maemo-mapper already running. What I like is exactly what I did in shell with mplayer. To decrease volume level I press 9 -4% down pressing 0 get 2% volume up rise. Sorry for such basic questions but I would greatly appreciate your advice. Darius Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
The new profile page
Does someone else has hit this bug #3412: https://bugs.maemo.org/show_bug.cgi?id=3412 in their profile view ? I.e. when clicking on a product's link, it will try to open the page for OS2007 instead of OS2008 (or the latest available). -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: implementation of 2-dimensional array in bash - kind request
Thanks. You are right as always. I am trying to master dialog and for my tiny application bash + 2D arrays + dialog should suffice. Darius --- On Sun, 6/7/08, Kees Jongenburger [EMAIL PROTECTED] wrote: From: Kees Jongenburger [EMAIL PROTECTED] Subject: Re: implementation of 2-dimensional array in bash - kind request To: [EMAIL PROTECTED] Cc: Maemo developers mailing-list maemo-developers@maemo.org Date: Sunday, 6 July, 2008, 11:37 AM Hello Darius, On Sat, Jul 5, 2008 at 7:54 PM, Darius Jack [EMAIL PROTECTED] wrote: and have 2D array inmterpreted as one row. so calculating array2D ( ) i-th j-th element as i + (j-1) x row length I agree with Igor what using bash or even better a POSIX shell would be a little insane. Still Dave Taylor have a serries on linuxjounral about shell programming (creating a card game/arrat manipulation) see http://www.linuxjournal.com/article/8704 I think you might find it useful. greetings, P.S. can you stop sending the Send instant messages to your online friends http://uk.messenger.yahoo.com; in every and each mail? Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The new profile page
On Mon, Jul 7, 2008 at 3:56 PM, Aniello Del Sorbo [EMAIL PROTECTED] wrote: Does someone else has hit this bug #3412: https://bugs.maemo.org/show_bug.cgi?id=3412 in their profile view ? I.e. when clicking on a product's link, it will try to open the page for OS2007 instead of OS2008 (or the latest available). Confirmed. Also doesn't work when you've got PC category software. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Shell API to call maemo-mapper commands, functions, options ?
Hi, ext Darius Jack wrote: what I really need is shell script to emulate GUI actions in maemo-mapper. Any chance to have shell script to interact with maemo-mapper basic functions/commands ? Frankly speaking I would like to add few more options, have more selection choices, nothing special. User friendly shell API is what I need. If you are aware how to run maemo-mapper from a command line with options, please tell me how. Ok. I can run maemo-mapper from a command line. Any chance to have fifo pipe and send parameters from command line to maemo-mapper already running. What I like is exactly what I did in shell with mplayer. To decrease volume level I press 9 -4% down pressing 0 get 2% volume up rise. Sorry for such basic questions but I would greatly appreciate your advice. If the program doesn't have e.g. D-BUS API, you can always record the required user input events with Xnee and play them back. This requires that the application is in known state though[1]. If you need only single (stylus or key) event, then you could use also xresponse. Both of these can be gotten from the maemo tools repo: http://maemo.org/development/tools/ - Eero [1] If this isn't known, Gtk UIs can be introspected through its accessibility APIs, but that's starting to be *a lot* of effort (Atk bridge requires Bonobo/Corba on the device). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Shell API to call maemo-mapper commands, functions, options ?
Thanks Eero, xnee MS Windows like macro record play facility is ok. Tried to install from repositories, none for OS2007HE. Frankly speaking what I need as macro on-the-fly composer to generate macro commands and have them played in xnee for maemo-mapper, from time to time. So I need to know if there is a way to have some standard m-m macros prerecorded/saved and modify them and make them playable in xnee to get D-BUS API para-functionality. I would like to have track saving enabled/disabled from time to time by macro sceript and the like to make maemo-mapper more user friendly. The same problem exist with other GPS car navigation devices. To many, to much clicks to make a right option selection. This is all about Interfaces and Interfacing , HID. To let the main application to be run as it runs and give adaptative modified interfaces to a user. So to move GUI HID to D-BUS like in mplayer run from command line. Nowadays, GUI applications are more click-and-click applications than intelligent HID ones. Maemo-mapper is my only way to build HID interface. Have you tried to run maemo-mapper from XNEE macro generated on-the-fly by events ? Darius --- On Mon, 7/7/08, Eero Tamminen [EMAIL PROTECTED] wrote: From: Eero Tamminen [EMAIL PROTECTED] Subject: Re: Shell API to call maemo-mapper commands, functions, options ? To: [EMAIL PROTECTED] Cc: Maemo developers mailing-list maemo-developers@maemo.org Date: Monday, 7 July, 2008, 6:05 PM Hi, ext Darius Jack wrote: what I really need is shell script to emulate GUI actions in maemo-mapper. Any chance to have shell script to interact with maemo-mapper basic functions/commands ? Frankly speaking I would like to add few more options, have more selection choices, nothing special. User friendly shell API is what I need. If you are aware how to run maemo-mapper from a command line with options, please tell me how. Ok. I can run maemo-mapper from a command line. Any chance to have fifo pipe and send parameters from command line to maemo-mapper already running. What I like is exactly what I did in shell with mplayer. To decrease volume level I press 9 -4% down pressing 0 get 2% volume up rise. Sorry for such basic questions but I would greatly appreciate your advice. If the program doesn't have e.g. D-BUS API, you can always record the required user input events with Xnee and play them back. This requires that the application is in known state though[1]. If you need only single (stylus or key) event, then you could use also xresponse. Both of these can be gotten from the maemo tools repo: http://maemo.org/development/tools/ - Eero [1] If this isn't known, Gtk UIs can be introspected through its accessibility APIs, but that's starting to be *a lot* of effort (Atk bridge requires Bonobo/Corba on the device). Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Shell API to call maemo-mapper commands, functions, options ?
Darius, Have you considered paying for the upgrade to the mapper application itself? It might already have the features you require and be commercially supported. One thing which puzzles me about what you are attempting to achieve however is how you can use the console whilst driving? Gary (lcuk on #maemo) On Mon, Jul 7, 2008 at 6:23 PM, Darius Jack [EMAIL PROTECTED] wrote: Thanks Eero, xnee MS Windows like macro record play facility is ok. Tried to install from repositories, none for OS2007HE. Frankly speaking what I need as macro on-the-fly composer to generate macro commands and have them played in xnee for maemo-mapper, from time to time. So I need to know if there is a way to have some standard m-m macros prerecorded/saved and modify them and make them playable in xnee to get D-BUS API para-functionality. I would like to have track saving enabled/disabled from time to time by macro sceript and the like to make maemo-mapper more user friendly. The same problem exist with other GPS car navigation devices. To many, to much clicks to make a right option selection. This is all about Interfaces and Interfacing , HID. To let the main application to be run as it runs and give adaptative modified interfaces to a user. So to move GUI HID to D-BUS like in mplayer run from command line. Nowadays, GUI applications are more click-and-click applications than intelligent HID ones. Maemo-mapper is my only way to build HID interface. Have you tried to run maemo-mapper from XNEE macro generated on-the-fly by events ? Darius --- On Mon, 7/7/08, Eero Tamminen [EMAIL PROTECTED] wrote: From: Eero Tamminen [EMAIL PROTECTED] Subject: Re: Shell API to call maemo-mapper commands, functions, options ? To: [EMAIL PROTECTED] Cc: Maemo developers mailing-list maemo-developers@maemo.org Date: Monday, 7 July, 2008, 6:05 PM Hi, ext Darius Jack wrote: what I really need is shell script to emulate GUI actions in maemo-mapper. Any chance to have shell script to interact with maemo-mapper basic functions/commands ? Frankly speaking I would like to add few more options, have more selection choices, nothing special. User friendly shell API is what I need. If you are aware how to run maemo-mapper from a command line with options, please tell me how. Ok. I can run maemo-mapper from a command line. Any chance to have fifo pipe and send parameters from command line to maemo-mapper already running. What I like is exactly what I did in shell with mplayer. To decrease volume level I press 9 -4% down pressing 0 get 2% volume up rise. Sorry for such basic questions but I would greatly appreciate your advice. If the program doesn't have e.g. D-BUS API, you can always record the required user input events with Xnee and play them back. This requires that the application is in known state though[1]. If you need only single (stylus or key) event, then you could use also xresponse. Both of these can be gotten from the maemo tools repo: http://maemo.org/development/tools/ - Eero [1] If this isn't known, Gtk UIs can be introspected through its accessibility APIs, but that's starting to be *a lot* of effort (Atk bridge requires Bonobo/Corba on the device). Send instant messages to your online friends http://uk.messenger.yahoo.com ___ 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: The new profile page
On Mon, Jul 7, 2008 at 3:56 PM, Aniello Del Sorbo [EMAIL PROTECTED] wrote: Does someone else has hit this bug #3412: https://bugs.maemo.org/show_bug.cgi?id=3412 in their profile view ? I.e. when clicking on a product's link, it will try to open the page for OS2007 instead of OS2008 (or the latest available). Confirmed. Also doesn't work when you've got PC category software. There was a bug in permalink handler for downloads. I have applied a fix, should work a lot better now. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Urgent N800 with GPS
hi all, Does some one has integrated GPS with N800 and have code or info of proper APIs pls let me know i urgently need to do it? How GPS can be detected from the host computer using maemo development enviornment? Regards, Nisha ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The new profile page
On Mon, Jul 7, 2008 at 9:51 PM, Niels Breet [EMAIL PROTECTED] wrote: On Mon, Jul 7, 2008 at 3:56 PM, Aniello Del Sorbo [EMAIL PROTECTED] wrote: There was a bug in permalink handler for downloads. I have applied a fix, should work a lot better now. Indeed, it works. Thanks for the very fast fix. -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org/downloads automatic updates from Extras
Hallo! One enhancement I would like to add is automatically update the 'Changes in latest version' field for the entry in downloads. I would like comments That would be nice :-) from the community on how developers should supply this information. One option would be to fetch it from the changelog. Problems here are that there aren't many packages using a changelog at the moment and we would need to filter out the real changes from the packaging revision updates. The debian package changelog describes changed to the package made by the package maintainer. If maintainer and developer are different a changelog entry for a major relase could just contain New upstream version - which would not be that helpful :-/ Also normally new package revisions would generate an entry in the changelog, however the package would have no visible change - it would just fix bugs in the packaging or in the software (which however could be relevant for some users!): Another option would be to use the ChangeLog of the original source package - this would contain upstream documentation to changes in the original software. You would expect to find new features there. However upstream information might contain information of varying detail. I have seen packages that list a huge number of even internal changes - mor elike a developer blog. So this source may also not be of best quality, too. Another problem is that the ChangeLog is owned by upstream, the maintainer can/should not change it. It amy also not be scanable because of varying syntax. In the ideal world however I would always show the contains of ChangeLog for the current upstream release and I would show changelog of the package for package revisions 1. So we can try it with these files and either put preasure on upstream or let the package maintainer fix/create these files or we can define a special maemo-specific file Maemo.ChangeLog that contains both information in a simple to parse, extendable file format (XML?). And to make everybody happy we try a fallback for ChangeLog and changelog if Maemo.Changelog does not exist - with improving magic over time. Simple XML file could look like: maemo-release-changelog revision release-date=2008-07-07 23:05:00 revision=package revision description Packages new upstream version. /description /revision release release-date=2008-07-01 11:55:00 version=source package version description Now plays funny sound on start. /description /release /maemo-release-changelog However many other formats with same or similar content are possible... Another option would be to let the developer enter this data while promoting the package to extras. We could add this step to the promotion interface. IMHO a bad idea. I personally want to have the process as automatic as possible (OK testing is still manual :-/). This way I can choose time and place and tool and process and I'm not forced to use the web page (must switch to dput soon :-)). -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org/downloads automatic updates from Extras
On Mon, Jul 7, 2008 at 10:09 PM, Tim Teulings [EMAIL PROTECTED] wrote: One enhancement I would like to add is automatically update the 'Changes in latest version' field for the entry in downloads. I would like comments That would be nice :-) Agreed. The debian package changelog describes changed to the package made by the package maintainer. If maintainer and developer are different a changelog entry for a major relase could just contain New upstream version - which would not be that helpful :-/ Agreed. So we can try it with these files and either put preasure on upstream or let the package maintainer fix/create these files or we can define a special maemo-specific file Maemo.ChangeLog that contains both information in a simple to parse, extendable file format (XML?). And to make everybody happy we try a fallback for ChangeLog and changelog if Maemo.Changelog does not exist - with improving magic over time. Personally, I'd rather downloads.maemo.org used one fixed system and it was up to tools like mud to pull out heuristically derived data from upstream and coalesce it into the simple format. Simple XML file could look like: maemo-release-changelog revision release-date=2008-07-07 23:05:00 revision=package revision description Packages new upstream version. /description /revision release release-date=2008-07-01 11:55:00 version=source package version description Now plays funny sound on start. /description /release /maemo-release-changelog However many other formats with same or similar content are possible... Indeed. TBH, I wonder whether another header would be sufficient in debian/control? We've already got XB-Maemo-Icon, adding XBS-Version-Changes or something could be sufficient. Is there any need for anything other than the last modification? Certainly for downloads.maemo.org; for more detail the debian/changelog is available and /should/ be the definitive location so we don't diverge too much from other Debian-based systems. (Your points about a potential ownership mismatch between an upstream debian/changelog and the Maemo package's are, of course, entirely valid and correct). Another option would be to let the developer enter this data while promoting the package to extras. We could add this step to the promotion interface. IMHO a bad idea. I personally want to have the process as automatic as possible (OK testing is still manual :-/). This way I can choose time and place and tool and process and I'm not forced to use the web page (must switch to dput soon :-)). Agreed. dput (or, well, scp) *must* be a supported option (well, I want to streamline it's use through mud[1] so not having it would mean screen scraping/web robots, which is fairly distasteful ;-)) Perhaps, however, if the package doesn't contain XBS-Version-Changes, the web form could prompt for it. Cheers, Andrew [1] http://wiki.maemo.org/User:Jaffa/mud_design -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
